Scopes
MCP scopes and how they map to Vacation Tracker permissions.
MCP has its own scopes, separate from the Zapier ones. AI clients usually request all three on the consent screen so every tool is available, but you can grant a subset if you only need one capability.
Available scopes
| Scope | Grants |
|---|---|
mcp:workspace:read | View departments, locations, leave types, and public holidays. Anything shared across the workspace. Required by get_workspace_info and get_holidays. |
mcp:users:read | Look up users by name, email, department, or location. Required by find_users. |
mcp:leaves:read | Query approved, pending, and denied leave requests. Required by get_leaves. |
How scopes interact with Vacation Tracker roles
Scopes decide which tool families are available on the token. They do not override your Vacation Tracker role. A non-admin user who grants mcp:users:read only sees the users they can see in the web app; the same ACL applies. The scope enables the tool, and your role caps the data it can return.
Default scope
If the MCP client omits the scope parameter, the authorization server rejects the request. Mainstream MCP clients always request at least one mcp:* scope, so in practice you won't hit this.
Requesting scopes
MCP clients discover and request scopes through the standard OAuth flow. Nothing to configure on the client side. Multiple scopes are space-delimited when URL-encoded:
scope=mcp:workspace:read%20mcp:users:read%20mcp:leaves:readRevoking scopes
Scopes are granted per authorization. To change what a connected client is allowed to do, revoke it and reconnect, which prompts a fresh consent screen. See Setup → Revoking access for how to revoke today. A self-service page is on the roadmap.