hamsa softwareA connector can move between assistants while changing the identity behind the request. A worked template-service contract separates portability from permission.
Alex switches assistants and asks for the same Operations proposal template. The old client acts as Alex; the replacement has only a shared account. Under the illustrative service’s access rule, that new request must stop. Returning the right-looking document would make the demonstration smoother while concealing that it came through a different identity. The connector can understand the request and still fail to preserve the job Alex was allowed to do.
That is the part of an exit demonstration I would want to see. The messages can remain compatible while the identity, consent and document rules change around them. A protocol can preserve useful integration work; the business still needs to know which arrangements move with the connector and which someone has to build again. Relaxing the access rule would be a change to the service, rather than a successful replacement of its client.
On 9 December 2025, Anthropic announced that the Model Context Protocol (MCP), an open standard connecting AI applications to external systems, was being donated to the Agentic AI Foundation under the Linux Foundation.[1] Foundation stewardship is a reason to take the protocol's future seriously. It is not evidence that any particular connector will behave identically in two clients. The business still needs an account of what it is moving.
The synthetic service below follows that lookup through two hypothetical clients, including the wrong team, a missing market and a credential intended for another service. Its outcomes are requirements for an exit trial, rather than measurements of named products. Each awkward request asks what Alex can still do, and what the replacement must continue refusing.
The service has approved proposal templates and restricted internal material. Alex belongs to Operations; Robin belongs to Sales. Each may retrieve approved templates for their own team. Neither may retrieve internal pricing notes through this template operation. An authorised server-side identity establishes the team; the assistant does not earn access by supplying a convincing team name in its arguments.
In this fictional service, the operation accepts a template type and market, then returns a stable document identifier, revision, approved status and source link. Alex's Operations proposal request should return template-ops at revision 3; Robin's identical request should be denied. An unknown template produces a defined unavailable result. Choosing an approximately matching draft would change this business contract, which the service owner must specify independently of MCP.
The request needs to make sense outside the original conversation. If the tool depends on a long chat to identify the customer or team, that conversation is an input whether anyone documented it or not. The dependency tends to introduce itself when someone tries to leave. Derive identity-related context from the server’s authenticated request and put the employee’s explicit business choices in the input contract, so a replacement client can supply each through the right route.
The response needs meaning too. Revision 3 means the approved source revision, not the third response the assistant happened to receive. A link must be usable by the intended reader. An unavailable result should explain the permitted next step without leaking restricted document titles. These are the details that let the business preserve the task, rather than merely preserve a function name.
{
"request": {"template_type": "proposal", "market": "UK"},
"identity": "derived from authenticated server context",
"expected_for_alex": {
"document_id": "template-ops", "revision": 3,
"status": "approved", "source_link": "access checked separately"
}
}An illustrative response contract for Alex’s template lookup, separate from the migration acceptance matrix.
Scroll sideways to see all columns.
| Returned item | Meaning in this service | What the client must preserve |
|---|---|---|
template-ops | Stable approved document identity | Do not substitute a nearby draft |
| Revision 3 | Revision of the approved source | Not the third generated answer |
| Source link | Route for the intended reader | Access must work for that reader |
| Unavailable | Defined missing-template outcome | No restricted titles or guessed replacement |
The November 2025 MCP lifecycle specification includes protocol-version agreement and capability negotiation during initialization.[2] That is a useful boundary: client and server should operate using capabilities they agreed. It is not a promise that every optional feature exists everywhere, or that the user interface around the feature has the same behaviour.
Suppose hypothetical Client A supports a form interaction that asks the employee to choose a market. Client B supports the required read operation but not that optional interaction. A server which refuses to proceed without the form has made the optional feature a practical requirement of this workflow. Client B may speak a compatible protocol while being unsuitable for the application as currently designed.
The business could retain the dependency if the form provides safeguards it needs. It could instead supply the market through a route both clients support before calling the tool. These choices deserve an explicit comparison because silently defaulting to UK changes what happens when information is missing, and may cause an employee to receive a different proposal template after the migration.
Does the new client ask the missing question, return a recoverable error or choose a default? In the template example, those outcomes can give Alex different documents even when both clients complete their protocol handshake. Record which one actually happens and whether the business accepts it. The handshake still matters: it tells you the agreed capabilities. Watching Alex complete the authorised lookup tells you how those capabilities are being used.
Client A can act for a named employee, while Client B begins with only the shared service identity. The template service requires an employee, so B’s well-formed first request is rejected. I would keep that refusal while arranging an acceptable identity route. Removing the employee requirement makes the demonstration easier by changing the access policy the business had agreed to move.
The MCP authorization specification distinguishes transport arrangements: its authorization flow concerns HTTP, authorization support is optional, and STDIO implementations obtain credentials through their environment rather than following that HTTP flow.[3] Those distinctions make it unsafe to infer the same employee boundary merely from a claim that a connector supports MCP. Inspect the actual deployment and credential arrangement.
For this example's HTTP service, a token intended for another resource must not become a route into the template server. The specification discusses resource and audience binding.[3] The business trial should include that negative case, using harmless test credentials. Likewise, removing Alex's eligibility must affect future reads according to the service's stated policy; a copied document in an existing conversation is a separate retained-information question, not something transport portability automatically retracts.
The internal mechanisms can differ without undermining the migration. An approved identity gateway in one client and a direct integration in another may preserve the same access policy. What needs comparing is the principal acting, the material returned and the evidence explaining each decision. Differences in implementation become procurement concerns when they change those outcomes or create operating work the team cannot support.
The matrix below is a set of contract expectations, not measured results. Once Client B has an acceptable named-identity route, run both clients against the same synthetic source set. Record the actual request, authenticated principal, source revision, result and decision reference for each case.
Include the approved lookup, the other-team lookup, restricted material, missing market, changed eligibility and a token with the wrong audience. These cases expose different dependencies. A failure to ask for a market may need interface work. A restricted result needs access-control investigation. An inaccessible source link may need a document-permission repair even when the tool's returned text appears correct. Assign each failed case to its responsible component and owner, then record whether fixing it changes the business contract. That prevents a migration checklist being closed by a workaround that quietly broadens access or removes a required question.
There is also a cost to portability. Maintaining two fully functioning clients indefinitely may be unnecessary for a small team. A bounded exit rehearsal can identify what would have to change without turning the secondary route into another production service. Keep a concise dependency inventory, the test fixture and the person responsible for repeating the exercise after a material identity or contract change.
The platform with the awkward dependency may still be the one the business wants. A capability worth paying for can also be worth some migration work later. Keep the exit exercise so that choice remains understandable: which contract survives, which identity route needs replacing and which differences were actually observed? When someone eventually moves the service, that account gives them something more substantial than an old slide saying the protocol was open.
Illustrative expectations for two hypothetical clients after each has an approved named-employee identity route. These are contract requirements, not empirical compatibility results.
Scroll sideways to see all columns.
| Request or condition | Required result | Evidence to retain |
|---|---|---|
| Alex requests Operations proposal | Approved template-ops, revision 3 | Named principal, team policy, source revision |
| Robin requests Operations proposal | Deny; no restricted content | Named principal and denial decision |
| Either client requests pricing notes | Unavailable through this operation | Tool contract and safe denial |
| Market is missing | Ask through supported route or return recoverable error | No silent market default |
| Alex loses eligibility | Deny subsequent read under stated service policy | Updated eligibility and decision reference |
| Token is intended for another resource | Reject before document retrieval | Audience/resource validation result |
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotPrimary sources behind this article. Living documentation may change.
Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.A saved replacement, a running service and an attacker’s existing access can change at different times. Railway’s guidance explains why that matters; PingCAP and PHP show where the next job differs.
Computer use needs an observation contract for account, object and outcome, especially when a visible click produces only partial completion.
Local inference offers a different operating boundary. Evaluate the completed task, data routes and maintenance responsibility before buying into it.
