---
title: "What it can reach"
description: "The honest boundary."
url: "https://openemail.uk/docs/mcp/scope"
area: "MCP server"
category: "MCP server"
---

# What it can reach

The honest boundary.

## Your role decides which tools exist

The server acts as you, against the connection you have made active. There is no separate service account and no wider access than your own. Since roles shipped, there is no wider access than your ROLE either. The tool list a client is given is built from the permissions you hold in the active workspace, so a viewer’s client does not list `sendEmail`, `createRule` or `sendWithTemplate` at all.

That is a stronger thing than refusing the call. A tool that is absent from the list is not a tool the model reasons about, does not eat context, and cannot be attempted on somebody’s behalf and then apologised for. It also means an empty-looking client is usually a permission you do not hold rather than a feature this server is missing, which is exactly what `whoAmI` exists to tell you.

Registration and invocation are two gates, and only the second one holds. The list is built once, when the session opens, and `setActiveConnection` can move that session into a mailbox where you may do less, so the list is stale by construction and the protocol has no way to withdraw a tool mid-session. Every gated tool therefore re-resolves your role against the CURRENT connection before it runs. Registration is the courtesy; invocation is the boundary.

> A refusal names both halves, as in `Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”`, so an agent can explain it to the person it is working for and stop trying, rather than retrying an opaque error until somebody gives up. A role changed by an admin while a session is open lands the same way, on the very next call.

Addresses are the other axis and are not affected by any of this. A role says what you may do; the addresses you have been granted say which mailboxes you may do it to, and both have to agree before a message goes out.

## The token itself is still unscoped

What has NOT changed is the grant. The token an app receives reaches everything your role allows rather than a subset you chose while approving it, so approving a client is approving it to everything you can do in that workspace. You are shown what is asking before anything is granted, and Account → Connected apps removes it afterwards, deleting every token it holds and the approval behind it, but choosing “read only, for this app” is not built.

> So the ceiling on an MCP client is the ceiling on YOU. Narrowing what an app can do means narrowing the role of the person who connected it, which narrows what they can do in the app as well. That is the honest shape of it today, and the reason a per-grant scope is still worth building.

The vocabulary is already shared: a role’s permissions and an API key’s scopes are drawn from one alphabet, which is what makes a key’s authority computable as the intersection of the two. A per-grant MCP scope will be expressed in the same words when it lands.

- [API scopes](https://openemail.uk/docs/api/scopes.md): The vocabulary, and how a role caps a key.
- [Roles & permissions levels](https://openemail.uk/docs/knowledge/team/roles.md): The two axes, in plain English.