hamsa softwareA source-checked illustrative transcript separates the original protocol’s common lifecycle and tool calls from source-specific meaning.
Connecting another source often means teaching an application another way to introduce itself, discover an operation and ask for its result. Anthropic’s 25 November 2024 Model Context Protocol (MCP) announcement offered a common version of that conversation, alongside developer material, local desktop support and example servers.[1] That is an interesting integration promise without needing an autonomous agent in the story. The repeated adapter work is familiar enough on its own.
The common protocol has a narrower scope than the application using it. It can define how a client requests a tool list, but cannot establish whether a project note is current or a returned statement describes an implemented feature. Following one small exchange makes that boundary visible: lifecycle and invocation become common, while source meaning and the decision to expose a capability still need application-specific work.
Suppose a host is comparing a project’s release note with its repository setup instructions. The note says owner review is pending; the repository source may be unavailable. The accompanying hand-written transcript follows that comparison using the 2024-11-05 specification, with invented material and no live server or model session. Its outer connection and direction labels are teaching annotations; the nested objects are protocol messages. Keeping the two sources separate will matter more to the final answer than the fact that both use the same request grammar.
Before reading either source, the client and server establish which conversation they support. The client sends initialize with its protocol version, capabilities and implementation information; the server replies with its version and capabilities. The client then sends notifications/initialized before ordinary requests.[2] Both example connections agree on 2024-11-05 and advertise tools. That lets the host proceed on a declared common basis, instead of assuming that a process it managed to launch can perform every operation the application might want.
A returned version must still be supported by the client. The specification describes negotiation and disconnection when it is not.[2] A nearby date is insufficient: treating it as compatible could make the host interpret later messages under rules the server did not agree to use. The transcript begins with matching versions so the source comparison can proceed. An operational client has to enforce that decision and retain session state; the agreeable example does not replace the negotiation and conformance work needed at an actual connection.
The 2024-version transport documentation describes standard input/output and HTTP with Server-Sent Events.[3] That historical scope matters because later protocol discussions can use different transport terminology or authorisation arrangements. For a local standard-input/output connection, the client launches a subprocess and exchanges newline-delimited protocol messages; diagnostic logging belongs separately from that message stream. A process that prints a friendly startup banner into the protocol output can make a connection unusable despite exposing a perfectly reasonable business function.
Reusing a lifecycle and message grammar makes introductions, feature descriptions and invocation formats more predictable across sources. Installation, configuration, supervision and trust in the server process remain separate responsibilities. A local process may have capabilities beyond the current task, regardless of how narrow its advertised tools appear. Assessing that process's actual permissions is therefore additional work alongside checking that its protocol exchange is well formed.
The versioned transport discussion is separate from task and server authority.
Follow the labelled arrows. On a narrow screen, scroll sideways if needed.
stdout can break messaging without saying anything about the legitimacy of the underlying business function.The notes connection first asks which tools are offered, using tools/list. Its read_note description requires a note_id, so the client can ask for N17 through tools/call. The returned text says the release decision awaits owner review, with isError false. The versioned tools specification defines these discovery, call and result shapes.[4] The name and note contents are illustrative. For the host, the important new fact is that it has retrieved one source for the comparison, with a known connection and an explicitly described read operation.
The repository connection offers read_readme and accepts repository_id R3 through the same methods. The client can reuse discovery and invocation code while keeping this operation attached to the repository server. It still needs to understand what setup instructions would contribute: they might explain how the project is configured, but would not by themselves approve a release. A shared protocol saves the host from learning a different outer conversation; it does not make a repository file and an owner’s pending decision interchangeable evidence.
A tool called read_note does not become read-only by its name alone. Its schema describes inputs, while the implementation determines what actually happens. The host must decide which server process it trusts and which operations belong in this comparison; the server must enforce its source-side limits. Automatically exposing every discovered tool would be an additional application policy. For a task that only needs two reads, a newly discovered write operation should therefore trigger a deliberate capability decision rather than quietly joining the available work.
The connection association must survive routing too. Two servers can offer the same short tool name, and a read intended for the repository must not be sent to the notes system merely because the names match. A clearer display name may help the user, but the host still needs an exact underlying mapping. The teaching transcript places connection identity outside the message for that purpose. It is not another tools/call argument the server is expected to understand, and it should not be rewritten into one by a generic forwarding helper.
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"read_note","arguments":{"note_id":"N17"}}}The repository branch returns text saying the source is unavailable, with isError true. That is an execution error, distinct from a protocol error such as an unknown tool or invalid arguments in the versioned tools specification.[4] The server understood the request but could not read its source. This is a more useful outcome than a successful empty README: it preserves the reason the comparison cannot finish, instead of turning a failed read into apparent evidence that there are no instructions.
The comparison is now incomplete. The note says owner review is pending, while repository instructions could not be retrieved. The host should retain the useful note with its source identity and show the repository error beside it. It cannot say the repository confirms the note or contains no instructions. A later authorised R3 read might complete the missing part, but changing to an unrelated document would answer another question. The common envelope has carried the failure back successfully; the application still owes the person an honest account of which part of their requested comparison remains undone.
A simple application might stop at the first unavailable source. Another could retain the note result and let the user decide whether to continue with a partial summary. Either can be appropriate if the output makes its evidence boundary clear. Repeatedly asking a different server for vaguely related content would change the question, and could enlarge access without improving the original comparison. The protocol makes additional calls possible; the task still determines which calls are worthwhile and permitted.
Illustrative messages checked against the 2024-11-05 lifecycle/tools pages; no live MCP session was executed.
Follow the labelled arrows. On a narrow screen, scroll sideways if needed.
For one stable read against one source, a direct API may be simpler than another process to install, configure and supervise. MCP is more attractive when several hosts or sources would otherwise repeat discovery, invocation and result handling. Compare that repeated work with the responsibility for each server’s lifecycle and access. If the host still needs entirely different source interpretation and policy for every operation, those costs remain even after message handling is shared. The architectural choice should turn on which common work actually disappears and which source-specific work somebody must continue maintaining.
In this small comparison, the common conversation works while the requested comparison remains incomplete. Both connections agree a version; the note returns a pending owner review; the repository returns an execution error. The host has enough to explain what it retrieved and what it could not check. That partial answer is useful. Calling it a completed comparison would throw away the source distinction the protocol successfully carried all the way back.
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.
