Canonical: https://botbento.com/blog/mcp-tool-permissions/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 5 MIN READ # MCP tool permissions: what to check before connecting a bot Connecting an MCP server makes tools available. It does not, by itself, answer which account a bot can access or which actions it should perform. Check the connection, the scope and the action separately. By BotBento Editorial · Published 2026-09-07 · Updated 2026-09-07 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [Start by naming the parts](#name-the-parts) - [Separate connection, authorization and action](#separate-the-decisions) - [Write an action you can inspect](#make-a-specific-request) - [A short review before the first useful task](#a-connection-review) - [Test the boundary as well as the happy path](#test-a-denial) - [What a connected status cannot prove](#what-a-connection-cannot-prove)[Read as Markdown ](/text/blog/mcp-tool-permissions/index.md) ## Key takeaways - Identify the host application, MCP server and downstream service before authorizing a connection. - A provider authorization grant and permission for a particular bot action are different decisions. - Test a harmless read, a denied action and revocation before relying on a new integration. ## Start by naming the parts Model Context Protocol, or MCP, describes a way for an AI application to connect to servers that expose capabilities such as tools and resources. The host application manages the user-facing experience; an MCP client handles its connection to a server. A server may then interact with another service. These are separate components even when an installation screen presents them as one integration. For an illustrative calendar connection, name three things before continuing: the application in which you talk to the bot, the server that provides calendar tools, and the calendar account those tools will use. If you cannot identify one of them, a successful connection message is not enough information to decide what access you are granting. Sources: [MCP architecture overview](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture). ## Separate connection, authorization and action The July 2026 MCP authorization specification defines an authorization flow for HTTP-based transports. It describes MCP servers acting as protected resources and clients obtaining tokens to access them. It also distinguishes HTTP authorization from standard-input/output connections, where credentials are typically supplied through the environment. The transport matters when you assess how a particular server gets its access. The same specification recommends requesting scopes needed for the intended operation and describes resource-bound token requests. In plain terms, ask what the granted permission covers and which server the credential is intended for. A broad provider grant can permit more than the single task you currently want. The grant should not silently become an instruction for the bot to exercise every available capability. For the calendar example, connecting the server answers whether the application can communicate with it. Selecting the account answers whose calendar is involved. Authorizing a scope determines what the connected software can technically request. Asking the bot to summarize tomorrow’s meetings is a narrower instruction. None of those steps should be treated as a substitute for the others. Sources: [MCP authorization specification, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization). ## Write an action you can inspect Compare “sort out my calendar” with this illustrative instruction: “Read tomorrow’s events in my work calendar, identify overlaps, and draft a suggestion. Do not create, edit, cancel or message anyone.” The second request produces a reviewable result and identifies the actions outside its scope. It still needs a correctly selected account and a service implementation that respects the access boundary. If a later request involves moving a meeting, describe the exact event, intended time and attendees before committing the change. A useful confirmation screen should show those details in a form the person can check. “Allow calendar access” may describe a technical grant; it does not tell someone whether a particular meeting is about to be rescheduled. The MCP tools specification recommends that applications keep people able to deny tool calls, display available tools and indicate their use. It also says tool annotations should be treated as untrusted unless they come from trusted servers. Our practical implication is to check the actual tool behavior and account permissions instead of relying only on a friendly name or a reassuring label. Sources: [MCP tools specification, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/server/tools). ## A short review before the first useful task The following is an illustrative review process for a new integration. It is deliberately specific enough to produce observations you can write down. The right controls depend on your host, server, service account and data. It is not a certification of any server or a claim that a protocol removes the need for implementation review. - Identify the operator: record the server URL or local package source, its publisher and the downstream service it uses. An unexpected operator is a reason to investigate before entering credentials. - Check the selected account: read the visible account name in the provider flow and compare it with the account needed for the task. Do not infer the selected account from the browser profile alone. - Read the access request: separate reading records from creating, changing, deleting or sharing them. If the requested access is broader than your task, find out whether a narrower integration or account is available. - Inspect the first result: use a harmless, recognizable record that you are authorized to access. Check that the result comes from the intended account and that the tool did not change anything. - Find the off switch: locate connection removal and provider revocation before you depend on the integration. Disconnecting a visible bot entry and revoking an underlying grant may be separate operations. ## Test the boundary as well as the happy path A successful read only proves that one request worked. For the calendar example, use a disposable test calendar and try a request that should be denied by the configuration, such as a write when the integration is configured for reading. Check the calendar afterwards. A refusal message is helpful, but the actual absence of an unauthorized change is the more meaningful result. Next, revoke the test connection using the documented provider route. Confirm that a fresh operation cannot continue through the revoked grant. Account for cached results when interpreting the screen: seeing an old meeting summary is different from successfully fetching new calendar data. If a new operation still works, stop using the test connection until you understand which credential or session remains active. Keep these checks small and reversible. Do not test destructive operations against a real customer account. Record the host version, server version when available, granted access and observed result. That gives you a useful comparison when the integration updates. A test performed before an update is historical evidence, not proof that a later version behaves identically. ## What a connected status cannot prove A connected badge does not establish that the right account is selected, every tool is safe, all provider permissions are narrow, or the bot will interpret every request correctly. It is one status inside a larger system. Treat it as a starting point for a specific task with a specific acceptance check. For everyday use, keep a simple record of what the integration is for, what it can access and how to remove that access. Revisit the record when you add a tool or change the account. That modest habit makes an expanding collection of bot connections easier to reason about. BotBento is being developed around conversations, routines and plugins; these general notes should not be read as a claim that a particular MCP integration is already available in the product. ## Primary sources Sources checked 2026-09-07. Standards and product documentation can change; follow the linked version when implementing. - [MCP architecture overview](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) — Model Context Protocol - [MCP authorization specification, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) — Model Context Protocol - [MCP tools specification, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) — Model Context Protocol BotBento is in development. [Suggest a correction](/contact/). ## Keep reading - [AI agents vs workflows: choose who decides the next step](/blog/ai-agents-vs-workflows/)