A shared tool protocol still needs application permissions
MCP's November 2024 launch standardized a connector interface. Applications still had to decide which data a user could read and which writes required approval.
By 
Paul. AI and agentic engineering
A common connector protocol can reduce repeated integration work without deciding what an assistant is allowed to do. MCP's November 2024 launch made that distinction worth stating early. Standardizing how an application discovers and calls a tool does not grant the application legitimate authority to read every record or change every system the tool can reach. For a business, the expensive mistake is connecting a useful interface before defining the permitted action.
Looking back from November 2026, the launch should retain its original boundary. Anthropic announced MCP on 25 November 2024, including a specification, SDKs, example servers and local server support in Claude Desktop. The same announcement described remote production tooling as forthcoming. Later authentication and transport capabilities should not be projected backwards into that initial desktop experience.
A connector boundary becomes reusable
The launch architecture separated servers exposing data or capabilities from clients connecting to them. That separation offered a way to reuse an interface across compatible applications instead of rebuilding a bespoke connection for each combination. It was a standardization proposal with working components, rather than evidence that every business system already supported it.
Simon Willison's launch-day account described his preview experience with desktop-launched processes communicating through standard input and output using JSON-RPC. He distinguished that working local path from the HTTP SSE direction already described in the specification. His SQLite example included read and write capabilities. These are his contemporary observations, not an AL+ installation or test.
That history differs from the earlier availability of model tool use. A model's ability to request a function call and a shared convention for exposing application capabilities solve related but separate problems. MCP's attraction was reusable integration structure. It did not make the application's authorization choices disappear.
A local process can have consequential authority
“Local” identifies where a process runs. It does not establish that its actions are harmless. In a proposed desktop assistant, a connector might receive a path to a database or credentials for a business service. The resulting authority comes from that configuration and the service's access controls, not from the physical proximity of the process to the user.
Consider an illustrative assistant preparing a draft customer response. Reading one customer's approved notes could be appropriate. Reading every customer's private correspondence would be a different grant. Sending the response changes another boundary again. A connector that can perform all three actions does not establish that each should be available during this task.
These are proposed design distinctions, not a claim that the launch software performed those exact operations. The principle is to map each tool to its real effect before selecting credentials. A friendly tool name can conceal a broad underlying account, especially when the external API offers more authority than the assistant needs.
The application must also distinguish model-selected arguments from trusted identity. A customer identifier supplied in a tool call cannot, by itself, demonstrate that the requesting user may read that customer. The service handling the request needs enough trusted context to enforce the relevant boundary independently of the generated request.
Make write approval specific enough to mean something
If the proposed assistant can update records, approval should concern the actual change. “Allow this connector” is a setup decision. “Send this message to this recipient” is a business decision. They happen at different times and can reasonably have different owners.
A useful approval view would show the proposed effect and the destination using information the application has checked. After approval, the application should execute that accepted action, rather than quietly substituting newly generated arguments. This is a recommended application design, not a description of a particular MCP client's November interface.
Retries deserve the same attention. If a write succeeds but the response is lost, repeating the request can duplicate the effect unless the underlying operation handles repetition safely. The connector interface alone cannot determine whether a second customer email or a duplicate record is acceptable. Record the outcome and define how an uncertain result is investigated before automatically trying again.
These details affect the business case. A reusable connector may reduce integration duplication while leaving substantial work in permission checks, approvals and failure handling. Budgeting only for connection setup would omit the parts that determine whether the assistant can be used responsibly for the intended task.
Share the interface while limiting the task
For a proposed rollout, start with a narrow read-only capability over data the user is already entitled to see. Document which account the connector uses and which service enforces access. Then decide whether a separate write capability has enough value to justify its approval and recovery design. Read-only access still needs confidentiality controls; it simply avoids one class of state-changing effects.
Keep the protocol version and client capabilities in that record. A current implementation may offer a different connection path from the original local desktop setup. Evaluate the actual combination selected for the project. A historical launch article cannot certify a later deployment's authentication, account isolation or logging behaviour.
A suggested acceptance exercise would trace one permitted read, one denied read and one proposed write through the application. Identify where identity is checked and where the user accepts the change. This is an illustrative verification proposal, not an experiment executed here or a claim about measured protection.
A direct integration can remain simpler
The strongest counterargument is that one assistant calling one stable service may be easier to maintain with a direct integration. Introducing a server and a protocol adds a boundary with its own configuration and lifecycle. Reuse is valuable when multiple consumers or capabilities actually need it; anticipated ecosystem growth is not sufficient proof of savings for a small project.
Choose MCP when the shared interface solves a concrete integration problem. Keep a direct call when it makes responsibility clearer at lower cost. For an AI agent project, ask which connections will be reused and which person approves every consequential write. The connector decision is complete only when the application can explain both the path to the tool and the authority behind the action.