The tool arrives before the operating model
An MCP connection can be working while the business process around it is still unresolved. I have seen teams reach that point in Claude deployments: the assistant can call a tool, but people disagree about the answer’s meaning or who may act on it. Model Context Protocol gives applications a consistent interface to tools and context. The team still has to decide what each operation means in its own business.
My team built an internal enterprise data integration platform before managed integration products became common. We had to settle who owned each feed, who could change it and who investigated a downstream discrepancy. That experience stays with me when reviewing MCP deployments. The interface helps us connect systems, while the operating agreement tells the team how to run that connection after the original project is over.
So describe the connection and the decision separately in every pilot brief. The connection description names the client, the server, the operations exposed and the deployment boundary. The decision description names the user, the intended outcome, the supporting evidence and the authority to act. When something breaks, those two descriptions tell you whether you have a technology problem or a business meaning problem.
A protocol cannot settle what revenue means
Consider a CFO asking Claude why gross margin moved last quarter. The interface can route that request to a data service. It cannot supply an approved margin definition, the right reporting period or a reviewer qualified to judge the explanation. If sales and finance disagree about revenue, no protocol resolves that. If an analyst transfers departments, the protocol does not decide whether her access should follow her.
Every connection needs three named owners. An operational owner handles credentials, monitors availability and knows how to disable the connection. A business owner approves the workflow. A data owner maintains the meaning of the information. In a smaller organization one person may hold two roles, but the roles must be distinct on paper.
Then write down the handoffs. If the assistant returns a number that conflicts with the board deck, who investigates the records, who settles the definition and who tells the users? Without that sequence, the engineer who configured the server becomes the default interpreter of every business disagreement. I have watched that happen. It burns out good engineers and leaves the real question unanswered.
Test behavior at the boundary, not the happy path
A successful tool call in a demonstration proves very little. Test four cases at minimum: a permitted request, a request outside the user's scope, an ambiguous question and an unavailable source. Watch how the assistant explains each outcome. A technically correct error that the user reads as a valid empty result can drive a poor decision as surely as a wrong number.
Look hard at what crosses the boundary and what lands in logs or support tickets. Do not expose extra fields simply because the interface can carry them. In regulated industries this is not a style preference. A HIPAA covered entity or a bank under examination will be asked to justify the data scope of each connection, and a narrow information contract is far easier to defend.
Keep compatibility claims precise. A server that implements MCP has not necessarily been tested with every client or authentication configuration. Record the combination used in the pilot and check current product documentation before expanding it.
Size the operating model to the institution
Fit the operating agreement into the service’s existing change and access reviews. Name who can approve a new tool, expand a source scope or retire a connection. For each change, identify which evaluation cases must be rerun and who reviews the result. This makes the agreement useful during ordinary maintenance, when the original project team may no longer be responsible for the service.
Whatever the size, agree on supported questions, freshness expectations, the escalation route and the conditions that trigger reevaluation before you widen access. Include a retirement path for connections that lose their owner or purpose. These are ordinary service management responsibilities applied to a new interface.
Build the responsibility map before you widen access
The most useful artifact I ask clients to produce is a two-column map: interface behavior on one side, business responsibility on the other. A tool returning a source error maps to an operator investigating availability and a business owner deciding whether a partial answer is usable. Every empty cell is work the integration alone cannot complete.
Then have the business sponsor walk one complete example from question to decision: the source evidence, the permission boundary, the user's interpretation and the next human action. It takes an hour, and it routinely exposes an unsupported leap between a successful response and a consequential decision.
MCP makes enterprise AI connections practical and reusable, and I expect it to become standard plumbing. Plumbing still needs a building code. Treat the interface as part of an accountable service, define the responsibilities around it, and your integration team can work inside clear boundaries instead of inferring policy from what is technically possible.