A common pattern
An MCP connector can be narrowly scoped, but that depends on its implementation and account grant. If it holds account-wide access, a single scheduling request inherits more authority than it needs.
Kraton / AI tool access / source-backed demo
An AI assistant can be useful without receiving the keys to your whole machine. In the demo’s local-calendar path, typed tools meet a host-controlled boundary before a calendar action proceeds.
The trade-off
A common pattern
An MCP connector can be narrowly scoped, but that depends on its implementation and account grant. If it holds account-wide access, a single scheduling request inherits more authority than it needs.
This Kraton demo
In the demo’s local-calendar path, the host permits read/write access only to the work calendar and only within a 30-day window. Other calendars and out-of-window requests are rejected.
Where the authority lives
MCP is a way to call a tool. By itself, it does not decide what the tool may read or change.
A direct account connection
If a connector is authorized for an entire account, a request to “find a time” can travel with that wider authority. A careful connector can request less; the protocol alone does not guarantee it.
Assistant → connector → account grant
The local-calendar demo path
Here, the assistant calls a typed tool. The host checks its calendar grant before the operation proceeds: only work, only a 30-day window. Other calendars and out-of-range requests are rejected.
Assistant → typed tool → Engine policy → work calendar
What is actually bounded
The example is useful because it makes the allowed inputs and actions explicit—not because it claims to solve every version of this task.
Where this example stops
This is an engineering demo, not a general-purpose AI agent or a hosted calendar product. Separate mock cloud-calendar and Beacon paths exist; the work-calendar grant described here applies to the local-calendar path. The model provider’s own data handling remains separate.
One scenario at a time