Based on the current stable MCP specification
Production implementation
The current MCP protocol is deliberately small and composable. That makes servers easier to build, but it leaves service ownership, idempotency, downstream failure, data freshness, change control and recovery with the implementation team. Production readiness begins when each capability has an explicit contract and an accountable owner.
MCP standardises discovery and invocation. It does not standardise the business meaning of success. Production architecture must make that meaning testable across the host, transport, server and system of record.
Contract before SDK
Its name, schema, permission, failure behaviour and evidence model become part of the runtime surface seen by hosts and models. Define that contract before choosing framework decorators.
Illustrative operation contract
This record is deliberately implementation-neutral. It states what must be true for the capability to be safe to build and operate.
Implementation sequence
Is this a focused capability with a clear owner, consequence and trust boundary?
Evidence: Contract draft, data-flow map, threat model and proposed SLO.TechOne recommendationDoes the implementation reject invalid identity, inputs, states and protocol metadata before it reaches the backend?
Evidence: Contract, security, tenancy, failure and compatibility test results.TechOne recommendationHas the organisation recorded the publisher, endpoint, transport, version, schemas, owner and approved environments?
Evidence: Private catalogue record and schema fingerprint.TechOne recommendationAre only the approved tools visible to the intended principals and clients?
Evidence: Policy decision, filtered tools/list response and release approval.Protocol-supported and TechOne recommendationCan the team observe latency, errors, policy decisions, approvals, cost and downstream health by capability and tenant?
Evidence: Dashboards, trace samples, audit records and alert tests.TechOne recommendationDoes a schema, description, authorisation or side-effect change trigger compatibility testing and the right level of re-approval?
Evidence: Semantic diff, version decision, migration test and updated catalogue record.TechOne recommendationCan consumers move without silent breakage, orphaned credentials or retained state?
Evidence: Usage inventory, deprecation notice, credential revocation and state-retention outcome.TechOne recommendationCache with an authorisation context
The current protocol defines cache hints for discovery, list operations and resource reads. It does not make arbitrary tool execution safely cacheable.
| Surface | Cache position | Why |
|---|---|---|
| server/discover | Cacheable with ttlMs and public or private cacheScope. | The 2026-07-28 caching model explicitly includes discovery results. Capabilities may still differ by deployment or authorisation context. |
| tools/list | Cacheable. Use public only when the same catalogue is safe for every caller. | The protocol requires cache hints and recommends deterministic tool ordering. Authorisation may change the visible tool set. |
| prompts/list | Cacheable with a scope matching the caller-specific catalogue. | Prompt lists are included in the protocol cache model and may vary by authorisation. |
| resources/list and resources/templates/list | Cacheable per page with consistent cacheScope across one paginated list. | Pages are independently fresh; there is no cross-page snapshot guarantee. |
| resources/read | Cacheable only with a TTL and scope appropriate to the resource and identity. | A private resource result must not be reused across authorisation contexts. A notification can invalidate a still-fresh result. |
| tools/call | Not cacheable through the MCP protocol cache contract. | tools/call is absent from the defined cacheable operations. Any application-level memoisation needs explicit semantic, identity, freshness and side-effect rules. |
| input_required and MRTR retries | Do not cache. | The specification excludes interim results and retries carrying inputResponses or requestState from caching. |
Failure is part of the contract
Transport recovery, business idempotency and downstream confirmation are separate mechanisms. Writes require an explicit command identity and a result that can be reconciled.
Protocol fact and TechOne recommendation
At the protocol layer, MCP 2026-07-28 allows any request to reach any compatible instance. Persist required workflow state behind an explicit, opaque handle, keep that state reachable by the selected instance and bind the handle to the verified principal.
TechOne recommendation; optional draft Tasks extension where supported
A transport response may confirm acceptance while downstream work remains in progress. Return a durable job or task reference and an unambiguous terminal outcome for long-running operations.
TechOne recommendation
Timeout does not prove that a write failed. Give mutations a stable command ID, deduplicate server-side and expose a status lookup before retrying.
Protocol-supported and TechOne recommendation
Define separate host, gateway, server and downstream deadlines. Propagate cancellation where possible and document any work that cannot be stopped safely.
TechOne recommendation
Apply per-principal, tenant, tool and downstream limits. A model can generate valid calls faster than a legacy service can process them.
Protocol fact and TechOne recommendation
Distinguish protocol errors from tool execution errors. Return bounded, actionable business errors without leaking internal topology, credentials or sensitive records.
Protocol fact and TechOne recommendation
The 2026-07-28 lifecycle is materially different from the 2025-era `initialize` handshake and session behaviour. Negotiate deliberately and test the clients that will actually consume the server.
Protocol fact and TechOne recommendation
The transports have different process, network, cancellation and isolation boundaries; they are not interchangeable deployment labels.
Performance evidence
Release evidence
| Scenario | Expected behaviour | Evidence |
|---|---|---|
| Modern protocol request reaches any healthy compatible instance | No connection affinity is required for protocol state; the request carries its protocol version and client capabilities, while any application state remains reachable through its explicit handle. | Load-balancer test across multiple instances with trace correlation. |
| Unsupported protocol version | The server returns the defined structured error and advertises supported versions rather than silently interpreting the request. | Captured HTTP and JSON-RPC response. |
| Mcp-Method or an applicable Mcp-Name disagrees with the body | The server rejects the request with HTTP 400 and HeaderMismatch -32020. | Negative transport conformance test. |
| Caller has a narrower scope or different tenant | The visible catalogue and object access are reduced; no cached private result crosses the authorisation boundary. | Two-principal comparison with cache instrumentation. |
| Two servers expose the same tool name | Policy, logs and approval UI retain an unambiguous server-qualified identity. | Aggregation and routing test. |
| Tool definition changes after approval | The release is blocked or moved through semantic review and re-approval before the new contract is active. | Schema and description diff in the release record. |
| Expired or stolen state handle is presented by another principal | The server rejects the call and does not reveal whether another user’s state exists. | Cross-principal and expiry test. |
| Client times out during a write | A repeated command cannot duplicate the side effect; the client can query the original command outcome. | Injected timeout with downstream record count and command log. |
| A resource changes before ttlMs expires | A supported change notification invalidates the cached result, or the documented freshness limitation remains visible to the consumer. | Cache invalidation test and resource timestamps. |
| Downstream system slows or returns partial failure | Concurrency remains bounded, timeouts do not cascade and the tool returns an accurate recoverable state. | Fault-injection trace and SLO result. |
| SSE response stream is closed by the client | The server treats the close as cancellation, stops work where practical and emits no further messages on that request. | Cancellation test with server and downstream traces. |
| OAuth metadata redirects to a private or link-local address | The client or controlled egress path blocks the request. | SSRF test with network-deny evidence. |
Handover boundary
Primary sources
Official sources establish the protocol baseline and identify any draft extension. Unless a statement is labelled as a protocol fact, the surrounding control pattern is a TechOne architecture recommendation.
Direct answers
No. MCP 2026-07-28 removes protocol-level sessions. An application may still keep carts, jobs, browser contexts or transactions, but it should expose an explicit handle and validate the caller on every use.
The current protocol cache model covers server discovery, tool, prompt and resource lists, resource-template lists and resource reads. It does not make tools/call results generally cacheable.
Only if the response is identical and safe for every caller. A public result may be shared across authorisation contexts. If identity or scopes affect visibility, use private caching and partition it correctly.
Usually not. A smaller, task-relevant capability surface reduces model context, policy complexity, unintended authority and the blast radius of a compromised server. The right boundary follows ownership and trust, not an arbitrary tool count.
No general business idempotency guarantee is provided by the protocol. Consequential tools should define a command identifier, duplicate behaviour and a way to retrieve the original outcome.
Use stdio for a deliberate local child-process integration with a controlled executable and local isolation. Use Streamable HTTP for a shared remote service that needs ordinary network, identity, gateway and horizontal-scaling controls.
No. Tasks is an optional draft MCP extension and support must be negotiated and tested. Where it is unavailable, use an explicit durable job contract with status, cancellation and expiry semantics.
Not a successful demo. Evidence should cover contract validation, authorisation, tenancy isolation, side-effect idempotency, failure recovery, protocol compatibility, observable SLOs, change control and an exercised runbook.