A product team wants its support assistant to answer the question "Where is my order?" The model does not know your orders. It cannot query your order management system on its own either. All it can do is ask: "call the tracking tool with order number 48213." Your application then decides whether to run that request. Everything that follows comes from this split of roles.
A tool is a request your application runs
A tool has three parts: a name, a plain-language description and a schema that fixes its parameters, like a structured output. For example: track_order, "returns the status of an order from its number," with a required order_number parameter. The model receives these definitions along with the question. If it decides a tool fits the need, it does not write an answer. It returns a call request: the tool's name and the filled-in parameters.
Your application receives that request. It checks the parameters and runs the call. It then sends the result back to the model, which writes its answer. In October 2026, Anthropic and OpenAI describe the same exchange in their documentation: the model produces the call, the application runs it. Anthropic adds that some of its own tools run on its side, not yours. This is also called function calling.
This split has a practical consequence. The model does not decide what it is allowed to do. The application runs the call, so the application can refuse, check the user's permissions or ask for confirmation. A tool that is too broad, like "run any command on the database," hands all control to the model. A narrow tool, like "read an order's status," keeps it in your code.
A user asks “Where is my order?” The model doesn't know your orders and can't query your order management system on its own.
The description matters as much as the code. According to Anthropic's documentation, in October 2026, the model calls a tool when the request matches what the tool says it can do. With a vague description, the tool gets called at the wrong moment, or never.
Key concept
A tool is a function your application makes available to the model: a name, a description and a parameter schema. The model only requests the call; your application runs it. Permissions, checks and confirmations therefore live in the application. MCP (Model Context Protocol) standardizes how these tools are connected. It does not decide what they are allowed to do.
MCP: a common plug for connectors
With MCP, each system exposes one common plug, with its tools, resources and prompt templates. But a padlock stays open: MCP standardizes the plug, not the trust.
Without a standard, every assistant needs its own integration for every piece of software. The CRM gets wired up for one assistant, then again for the next. MCP solves this. In October 2026, its website presents it as an open-source standard for connecting AI applications to external systems, and compares it to a USB-C port.
The protocol has two sides. On one side, an MCP server exposes what a piece of software can do: tools (create a ticket), resources, meaning data to read (a customer record), and prompt templates. On the other, the AI application, which the specification calls the host, connects to it. A server written once works with several assistants. On the user's side, this connection is often called a connector: access to your other software. The latest version of the specification is dated July 28, 2026.
On December 9, 2025, Anthropic handed MCP over to the Agentic AI Foundation, set up within the Linux Foundation, according to the Linux Foundation's announcement. Amazon Web Services, Anthropic, Google, Microsoft and OpenAI are among its Platinum members. According to the project's governance page, its technical maintainers serve as individuals. No seat is reserved for a company.
In October 2026, according to their documentation, Claude, ChatGPT, Microsoft Copilot Studio, Gemini Enterprise, Visual Studio Code and Cursor accept MCP servers. Terms vary. In Claude, custom connectors are available on every plan, but a free account gets only one. In Gemini Enterprise, an administrator connects the custom MCP server.
That is why the question now comes up in purchasing. A vendor that publishes an MCP server plugs into the assistants you already use, with no integration project. An AI tool that accepts MCP reaches your systems without waiting for its vendor to build each integration. The open question is who in your company can add a connector, and what that connector can do.
What MCP does not solve
MCP standardizes the plug, not the trust. The specification says so: the protocol cannot enforce its own security principles. Applications that use it have to apply them. These principles cover user consent, data privacy and caution with tools. Calling a tool amounts to running arbitrary code. So the host must get the user's explicit consent before calling one.
Connecting an MCP server is therefore granting access, the way you would create an account for a contractor. Three questions determine the risk: which tools are open, on which data, and on whose behalf.
One connector, the fewest rights possible
Least privilege applies connector by connector. OWASP, a foundation widely used as a reference for software security, calls this risk "excessive agency" in its 2025 list of risks for applications built on LLMs (large language models). It names three causes: too many functions, too many permissions, too much autonomy. The settings follow the same split.
- Functions. Open only the tools the task needs. A support assistant reads an order's status; it does not need the tool that cancels the order. In October 2026, the MCP connector in Anthropic's API lets you allowlist or denylist a server's tools, and OpenAI's API lets you restrict an MCP server's tools.
- Permissions. The connector acts with the user's permissions, not those of a service account that sees everything. When you connect, decline broad permissions the task does not need. MCP's security best practices recommend starting with a small set of read permissions, then widening them when an action requires it.
- Autonomy. Any action that changes or sends something waits for human approval. In October 2026, OpenAI recommends keeping approval on tools that modify data. It warns that a write can still happen even if the server labels the tool as read-only.
All three are narrowed: any action that changes or sends something waits for human approval before it runs.
Who owns a connector
A connector opens a system. Its owner is therefore the team that answers for that system, not the team deploying the AI: finance for the accounting system, support for the ticketing tool. That team approves the open tools and the rights granted. It reviews the descriptions, monitors the logs and removes access when it is no longer used.
Several vendors restrict adding connectors to administrators. In October 2026, on Claude's Team plan, only Owners can add a custom connector. On the Enterprise plan, you need to be an Owner or have a role that allows it. For Copilot Studio, Microsoft states that the customer is responsible for the tools and resources it uses on an MCP server.
Keep a simple inventory. For each connector: its owner, its open tools, read or write, the account it uses and the date of the last review. This is the list an auditor, an enterprise customer or your security team will ask you for.
Four risks specific to connectors
- An untrusted server. An MCP server installed on a computer is a program running on that computer, with the same rights as the assistant. A remote server receives the data the assistant sends it. In October 2026, Anthropic recommends connecting Claude only to servers built and hosted by organizations you trust. OpenAI points out that custom MCP servers are neither developed nor verified by OpenAI. The official MCP registry lists servers; its home page mentions no security review.
- Tool poisoning. In April 2025, the security company Invariant Labs described malicious instructions hidden in a tool's description. The user does not see them; the model reads them. A variant: the server changes the description after you approved it. And some hosts pick up such changes on their own. In October 2026, Copilot Studio updates an agent's tools when the MCP server changes them. The specification says to treat descriptions as untrusted unless they come from a trusted server.
- Injection through a tool result. A call's result is content the model reads: an email, a ticket, a web page. If it contains instructions, the model may follow them. This is indirect prompt injection, described on the Guardrails page.
- Data leaving through a tool. According to OpenAI, in October 2026, any MCP server may receive sensitive data during a call. A tool that sends an email or calls a web address is also a way for data to get out. The Agents page describes the combination to avoid, the "lethal trifecta": private data, untrusted content and the ability to send data out.
What it means for you
For product managers
Specify each tool like a feature: what it does, what it does not do, and whether its action waits for approval. Prefer several narrow tools to one tool that does everything. Write the descriptions with the engineering team. Test them on real requests: the ones that should call the tool and the ones that should not. An assistant's evals (short for "evaluations") also check which tools it called.
For tech leads
Validate every call in code before running it: schema, user rights, capped amounts. Turn on strict mode when the API offers it. For an MCP server, open only the listed tools, request minimal scopes and pin the server's version. Review its descriptions with every update. Treat every tool result as untrusted data. Log every call with its parameters and the user's identity. In a coding agent, a hook (a command that runs automatically at a set point) can block a tool call with a rule written in code: in October 2026, Claude Code supports this, including for MCP tools.
For business leaders
Decide who may add a connector, and put it in writing. Each connector has an owner on the team responsible for the system it opens. When buying, ask the vendor four questions. Does the tool accept MCP connectors? Can you restrict which servers are allowed? Can you limit the tools and require confirmation for writes? Where are the logs? Without clear answers, the tool opens your systems without you knowing how.
The classic mistake
fAIling RULE XIII
The trap: Skip the guardrails. Move fast.
The connector works in the demo, so every tool gets opened, with an account that sees everything, and someone checks "always allow" to stop the interruptions. Every confirmation removed is an action nobody reviews anymore. The first malicious email the assistant reads can then use it. Set the tools, the rights and the approvals when you set up the connector, not after the first incident.
Read rule XIII in the manifestoTry it
Now. Open the settings of the AI assistant you use most and list its connectors. For each one, note what it can read, what it can change or send, and with which account.
This week. Pick the broadest connector. With the person who answers for the system it opens, turn off one tool nobody uses, or replace a permanent permission with a confirmation. Write down who now owns that connector.
Around this topic
Go deeperConnectors, skills and plugins
A connector gives access: read the CRM, create a ticket. A skill gives the method for using that access in a specific task. A plugin can bundle both. The Skills and plugins: know-how on demand page covers what a skill contains, who writes it and who reviews it.
Both together: the connector gives access to the system, the skill gives the method, meaning how to use that access for a given task.
Go deeperToo many tools cost money
Tool definitions are part of every request sent to the model, and you pay for them. According to Anthropic's documentation, in October 2026, tool names, descriptions and schemas are billed as input tokens (a token is a chunk of text, often part of a word). An MCP server with fifty open tools sends all of them, even for a simple question. Anthropic offers a tool search tool that loads definitions on demand. The simplest fix is still to open only the useful tools, in the harness: everything around the model in a product.
Go deeperA local MCP server runs on your computer
An MCP server can run on the user's computer or with a hosting provider. MCP's security best practices point out that a local server is a program downloaded and run on the same machine as the assistant. Before installing a server, the application must show the exact command and get the user's explicit consent. It must also run the server in a sandbox, with minimal privileges. For a company, the practical rule is the same as for any software: a list of approved servers, installed from a known source, at a pinned version.
What to do with it
Put permissions, checks and confirmations in your application, not in the model's instructions.
Prefer several narrow tools to one that does everything, and write each description with care: it decides when the tool is called.
MCP standardizes the plug, not the trust: open each connector with the fewest rights, and make the team that answers for the system its owner.