Securely add remote tool endpoints after the MCP stateless update

To securely add remote tool endpoints after the MCP stateless update, platform teams need to change more than a transport setting. The MCP 2026-07-28 release candidate removes protocol-level sessions and the Mcp-Session-Id er. On the modern Streamable HTTP path, requests are sessionless by construction. That simplifies horizontal scaling because infrastructure no longer has to preserve transport-level affinity, but it also removes an implicit place where implementations may previously have hidden authentication context, workflow state, tool registration assumptions, or connection-specific behavior.

The practical model is straightforward: expose remote capabilities through an authenticated, origin-validated HTTP service; advertise them through a deterministic tools/list response; authorize every request; and pass any required state explicitly as tool arguments or approved ers. This model supports the web-native goal of making agent infrastructure stateless, cacheable, routable, and globally scalable. It is especially relevant to AI agent orchestration platforms, where a control plane must discover specialist tools, route requests safely, hand off context, and preserve operational oversight without assuming that two calls will reach the same process.

Understand what the MCP stateless update changes

The most important architectural change is the removal of protocol-level session continuity. Under the 2026-07-28 release candidate, modern Streamable HTTP requests do not carry an Mcp-Session-Id. A server should therefore evaluate each lifecycle request on its own, using the request credentials, method, tool name, arguments, and other explicit context supplied by the deploying application. Python and Ruby deployment documentation describes this modern flow as inherently sessionless; options such as stateless_http apply only to legacy paths rather than turning the modern path into something it is not already.

Stateless transport does not mean that an application cannot have durable business state. A remote code-analysis tool may still create an analysis job, a data tool may still produce an export, and an operations tool may still open an approval request. The distinction is that this state must not be hidden inside the MCP connection. If one tool call creates a resource that a later call needs, the first response should return an explicit handle. The caller then supplies that handle as a normal argument in the later request. The resource can live in an appropriate backend store, while the MCP transport remains independent of connection continuity.

This separation improves routing options. A load balancer can send consecutive requests to different server instances without requiring sticky sessions merely to preserve protocol state. A server process can be replaced or scaled out without invalidating an MCP session, because no such modern protocol session exists. The Go SDK guidance reinforces this boundary by noting that a stateless deployment may create a new server for each incoming request and register its tools again. Tool handlers must consequently be safe when invoked in request-scoped environments.

The update also changes how clients discover remote capabilities. Servers are expected to expose tools through tools/list, and the list no longer varies according to a long-lived connection. A client or orchestration control plane can discover the available tools without binding the catalog to a particular server process. The response may still vary according to the credentials presented on the request, but that is authorization-scoped discovery rather than connection-scoped discovery. This is a crucial distinction for enterprise deployments serving teams with different permissions.

Do not interpret statelessness as an instruction to make every backend operation ephemeral. Instead, treat the MCP server as a request-oriented policy and tool boundary. Durable records, approval workflows, job status, and audit data can remain durable where the application requires them. What disappears is the assumption that the transport remembers who the caller is, which tools were exposed earlier, or what happened in the preceding request. Every security-relevant fact needed to process a call should be recoverable from authenticated request context, explicit arguments, or an authoritative backend.

Harden the transport before registering remote tools

Transport hardening is the first security gate for a remote MCP endpoint. Streamable HTTP servers must validate the Origin er to protect against DNS rebinding. An endpoint that accepts requests merely because they appear to target a local or trusted address can be exposed through a browser-driven rebinding path if origin checks are absent. The server should compare the presented origin against an explicit policy appropriate to its deployment rather than treating any syntactically valid origin as trusted.

On a developer machine, the server should bind to 127.0.0.1 when remote network access is unnecessary. Binding locally limits exposure while a developer tests tools that may access source code, files, credentials, or internal services. This is not a substitute for origin validation or authentication. It is a complementary boundary that keeps a development endpoint from listening on every interface by default. If a team later needs remote access, that should be an intentional deployment decision with the same controls expected of any other remotely reachable service.

Every connection also needs proper authentication. In the stateless model, authentication cannot be completed once and then inferred from an MCP session on later calls. Recent Ruby documentation makes this explicit: modern lifecycle requests carry no Mcp-Session-Id, touch no stored session, and are authorized per request by the deploying application. The authentication mechanism itself depends on the environment, but the evaluation point is consistent. A request that lists tools and a request that invokes a tool must each carry enough trustworthy information for the application to authenticate and authorize the caller.

Separate network reachability from permission to act. A service may be reachable from an orchestration workspace while exposing different tools to different identities. Because tools/list may be authorization-scoped, the server can return only the tools permitted for the credentials on that request. The same policy must be enforced again during tools/call. A cached catalog or previously observed tool name is not proof that the current caller may invoke it. Discovery improves user and agent experience, while call-time authorization remains the security control.

For a control plane, endpoint registration should therefore capture a small but meaningful security contract. Record the expected transport, allowed origin policy, authentication configuration, credential scope, ownership information, and intended environment. Verify that the service presents a valid tool catalog only after those controls are configured. Avoid activating an endpoint merely because it responds to an HTTP probe. Availability confirms reachability; it does not confirm identity, authorization behavior, or safe tool semantics.

Keep secrets out of tool descriptions, URLs, and ordinary arguments unless an argument is specifically designed to carry protected data through an approved path. The stateless update does not require credentials to become model-visible context. An orchestration layer can attach authentication material at the transport boundary while presenting the model with only the tool name, safe description, and permitted schema. This separation reduces the risk that an agent copies a credential into a prompt, log, tool argument, or handoff to another specialist.

A practical pre-registration gate should confirm that the endpoint validates origins, uses per-request authentication, returns an authorization-appropriate catalog, rejects unauthorized calls, and does not rely on a prior request for identity. For local development, it should also confirm loopback binding. These checks directly follow the new request-oriented architecture. They are more reliable than asking whether a server supports sessions, because modern Streamable HTTP is sessionless by construction.

Discover tools through a deterministic and scoped catalog

After transport controls are in place, use tools/list as the discovery interface. Do not bind remote tool availability to a long-lived connection, a specific worker, or an initialization sequence that stores a private catalog in server memory. The client should be able to request the tool list with its current credentials and receive the tools that identity is allowed to see. This makes endpoint onboarding compatible with horizontally scaled servers and with orchestration systems that periodically reconcile remote capabilities.

The 2026-07-28 guidance says servers should return tools from tools/list in deterministic order. This requirement is not cosmetic. Stable ordering makes client-side caching more effective and can improve LLM prompt cache hit rates because equivalent catalogs are less likely to be serialized differently from one request to the next. If a server emits the same authorized tool set in arbitrary order, the semantic content may be unchanged while the resulting prompt or cache key changes unnecessarily.

Choose a stable ordering rule and apply it after authorization filtering. Ordering tools by a canonical key such as the exposed tool name is a simple implementation approach, provided that names are unique within the returned catalog. The important property is determinism for the same effective inputs. Do not let process startup order, map iteration, worker identity, or backend response timing determine how tools appear. In a stateless deployment that re-registers tools per request, nondeterministic registration order can otherwise leak into every catalog response.

Authorization-scoped catalogs need equally careful cache boundaries. A control plane should not reuse a tool list across identities merely because the endpoint URL is the same. The effective catalog can vary with the credentials presented on the request, so any cache key must account for the relevant authorization scope without exposing credential secrets. If the orchestration workspace supports projects, teams, or environments, it should also prevent a catalog discovered in one boundary from becoming available automatically in another.

Cache freshness deserves an explicit policy. Deterministic ordering makes caching safer and more efficient, but it does not prove that a cached list is current. Tool additions, removals, or permission changes can make an earlier response stale. A control plane can reconcile catalogs at controlled intervals, refresh during endpoint administration, and refresh after an authorization change. The suitable cadence depends on how dynamic the endpoint is; the key is to define the behavior rather than silently assuming that initial discovery remains valid forever.

Tool-list change notifications require special caution. A recent SDK issue reports that tools/list_changed notifications can be dropped on stateless Streamable HTTP transports when the related request context is missing. This is an edge case, not a reason to abandon notifications, but it means notifications should not be the only correctness mechanism for highly dynamic catalogs. A periodic or event-triggered reconciliation path gives the control plane a way to recover when a notification is not delivered.

Catalog quality also affects safe agent routing. Tool names and descriptions should distinguish capabilities clearly, while input schemas should constrain what can be requested. A deterministic catalog helps the model see a stable interface, but stability does not compensate for ambiguous tools. Platform reviewers should examine whether each tool has a narrow purpose, whether consequential actions are identifiable, and whether the schema provides the data needed for policy checks and human review.

Authorize each request with method, name, and approved ers

The stateless release makes authorization more request-centric by adding standard request ers such as Mcp-Method and Mcp-Name. These values provide useful request-level context when MCP traffic is routed to policy enforcement, gateways, or backend services. A deployment can distinguish a tool listing operation from a tool call and can identify the requested tool without relying on connection history. This is particularly helpful when one remote MCP endpoint fronts several backend capabilities with different risk levels.

These ers should contribute to authorization rather than replace it. A policy decision should still be tied to an authenticated identity and the server's authoritative interpretation of the request. Treat routing metadata as context, not as proof that the caller is permitted to use a method or tool. The endpoint must verify that the named tool exists in the caller's authorized scope and that the request arguments satisfy the tool's schema and application policy.

MCP also supports custom ers derived from tool parameters through x-mcp-er-style annotations or equivalent SDK mechanisms. Documentation for C#, Go, PHP, and TypeScript describes mappings that cause clients to send Mcp-Param- ers on tools/call requests. This capability is relevant when a remote tool must pass request context to a backend endpoint through ers rather than through a connection-bound session.

Header mapping should be designed conservatively. A tool schema should identify only the parameters that genuinely need to become ers, and the receiving service should allow only expected names and formats. Do not provide a generic parameter that lets an agent choose arbitrary HTTP er names. Such flexibility can blur trust boundaries or interfere with routing and security controls. A narrow mapping from a validated tool argument to a known Mcp-Param- er is easier to review and enforce.

Also distinguish business context from authentication credentials. A tenant reference, locale, job handle, or backend routing key may be appropriate as an explicitly validated parameter-derived er. A secret used to authenticate the MCP client should usually be attached by trusted infrastructure, not generated from model-controlled tool arguments. This keeps the model's decision space separate from the credentials that establish authority. The fact that MCP can map parameters into ers does not mean every sensitive er should be controlled by a tool parameter.

When a remote MCP server delegates work to another service, define which layer owns each authorization decision. The MCP-facing layer should authenticate the caller and determine whether the requested tool is allowed. The backend should still validate the context it receives according to its own trust boundary. If the MCP layer forwards identity or scope information, the backend needs a reliable way to know that the information came from that trusted layer rather than directly from an untrusted caller. The exact mechanism is deployment-specific, but the trust relationship should be documented and testable.

Request-centric authorization also improves audit clarity. An operational record can associate the authenticated principal, Mcp-Method, Mcp-Name, approved parameter context, decision, and outcome with one request. Avoid placing secrets or unnecessarily sensitive argument values in logs. The objective is to preserve enough information to investigate tool access and policy decisions without turning observability systems into a secondary store of credentials or confidential payloads.

Test authorization at both discovery and invocation time. A restricted identity should receive an appropriately limited tools/list, and a direct attempt to call an omitted tool should still be denied. A changed or expired credential should affect the next request without waiting for session cleanup. That behavior is an advantage of the stateless model: current credentials and current policy can govern each action rather than inheriting authority from a long-lived protocol session.

Make tool state explicit and handlers request-scoped

The safest design rule after the update is that any state needed later must be represented explicitly. Suppose a tool begins a long-running operation. Its response can return a job handle, and a separate status tool can accept that handle. If a tool prepares a change that requires approval, it can return a proposal identifier, and a later tool can accept that identifier after the approval condition is satisfied. The caller is responsible for carrying the handle forward through the orchestrated workflow.

An explicit handle should identify backend state without granting more authority than intended. Possession of a handle should not automatically bypass authentication or authorization. On every follow-up request, the server should validate the caller, verify access to the referenced resource, and enforce the operation allowed in the resource's current state. Stateless transport removes connection continuity; it does not remove access control for durable resources.

Tool handlers should also tolerate one-request-at-a-time execution. The Go SDK notes that stateless deployments may instantiate a server and re-register tools for each incoming request. Avoid depending on mutable process memory populated by a previous call. A worker-local variable is not an appropriate place to keep the only copy of a workflow token, selected tenant, approval status, or authorization result that another request will require.

Idempotency is an important design objective for request-scoped tools, especially when infrastructure or an orchestrator may retry after an uncertain outcome. A read operation should return a result based on its explicit inputs and current authorized state. For a consequential write, the tool can accept an explicit operation identifier or other application-level guard when the backend supports it. The exact strategy depends on the action, but the handler should not assume that a repeated request can be recognized through an MCP session.

Keep request-scoped execution separate from cross-request workflow coordination. The orchestration control plane can hold the workflow graph, handoff context, approvals, and returned resource handles. The tool server remains responsible for validating each call and acting on authoritative backend state. This division lets specialist agents collaborate without turning the MCP transport into a hidden workflow engine. It also makes failures easier to reason about because the control plane can show which explicit input produced each tool call.

Review existing tools for accidental session dependencies before moving them to the modern path. Common warning signs include phrases such as current workspace, previously selected project, last query, or active transaction when those concepts are not present in the call arguments or authenticated context. Replace the hidden dependency with an explicit identifier, or redesign the operation so that it can complete in one request. If a backend transaction genuinely spans operations, expose a controlled transaction handle and apply authorization and expiry rules at the application layer rather than relying on MCP connection state.

Request-scoped behavior also makes failure semantics clearer. If a server instance disappears after returning a durable handle, another instance should be able to process the next authorized request using that handle. If an operation cannot provide that property, document the limitation and avoid presenting it as a generally routable stateless tool. Horizontal scaling becomes simpler only when application design follows the transport model instead of rebuilding connection affinity through undocumented dependencies.

Integrate remote endpoints through a controlled orchestration plane

An AI agent orchestration workspace should treat endpoint onboarding as a managed lifecycle, not a one-time URL entry. Begin with ownership and purpose: identify which team operates the endpoint, which specialist agent needs it, what backend systems it can affect, and whether its tools are read-only, mutating, or consequential. This information supports routing, approval policy, incident response, and later removal. It also prevents a technically reachable endpoint from becoming an ungoverned capability shared across unrelated workflows.

Next, validate the transport profile in a non-production environment. Confirm local binding behavior where relevant, origin validation, authentication on every request, and correct rejection behavior. Call tools/list more than once with the same authorization context and verify deterministic ordering. Use credentials with different permissions and verify that each receives the expected authorization-scoped catalog. Then attempt direct calls to unavailable tools to confirm that invocation policy does not depend solely on catalog hiding.

Inspect every discovered tool before making it available to an agent. Review the name, description, input schema, parameter-to-er mappings, backend effect, and state model. Identify parameters that can influence tenants, destinations, resources, or execution scope. Confirm that mapped ers have allowlisted names and validated values. Determine whether a call returns an explicit handle and whether later calls reauthorize access to the referenced resource.

Register approved tools in the control plane with an explicit exposure policy. A specialist research agent may need read-oriented data tools but not deployment controls. An operations agent may need a mutating tool only when a workflow reaches an approval gate. Because tools/list can already be credential-scoped, platform-level filtering should complement server authorization rather than substitute for it. Defense in depth is useful here: the model should not be offered irrelevant high-risk tools, and the server should still reject any unauthorized direct request.

Preserve context through structured handoffs rather than transport sessions. When one agent invokes a tool and another agent continues the workflow, pass only the necessary result, resource handle, provenance, and approval status. Do not imply that the receiving agent inherits the first agent's connection or authority. It should use its own permitted tool set and trigger a newly authenticated request. This keeps multi-agent collaboration aligned with the stateless boundary.

Roll out incrementally. Start with a restricted identity and a narrow tool subset, observe listing and call behavior, and verify that retries or worker changes do not alter correctness. Expand access only after the endpoint behaves consistently across independent requests. If a tool requires server affinity, undocumented initialization, or a previous call to establish permissions, it is not ready for the modern stateless path. Either redesign it or isolate it behind a clearly managed legacy integration until its assumptions are removed.

Operational controls should include a way to disable an endpoint or individual tool without editing agent prompts. The orchestration layer should be able to stop routing new calls, refresh catalogs, and preserve enough request records to investigate failures. Since dynamic list notifications may be missed in the identified stateless edge case, administrative changes should also trigger an explicit reconciliation where possible. The control plane should converge on the server's authorized catalog even if a notification never arrives.

Test, monitor, and govern the stateless integration

A secure implementation needs tests that reflect independent requests. Restart the server between listing and invocation, route consecutive calls to different workers, and avoid preserving cookies or hidden client state unless the application explicitly requires them outside MCP session semantics. A successful workflow under these conditions provides evidence that required state is truly carried through arguments, approved ers, credentials, or durable backend records.

Include negative tests. Send a request with a disallowed origin, omit authentication, use credentials that lack the requested tool, alter an explicit resource handle, and attempt to call a tool that is not present in the caller's authorized catalog. The expected result is rejection at the appropriate boundary without relying on a previous request. Also test malformed parameter-derived er values so that er mappings cannot bypass schema or backend validation.

Test catalog determinism as data, not merely by visual inspection. For the same endpoint version and authorization scope, repeated tools/list calls should produce the same ordered tool set. When permissions differ, verify that the response changes only as intended. When a tool is added or removed, confirm that refresh and reconciliation behavior updates the control plane even if tools/list_changed is unavailable or dropped.

Monitoring should distinguish discovery failures, authentication failures, authorization denials, validation errors, backend failures, and orchestration cancellations. These outcomes have different owners and remediation paths. A denied request may show that policy is working, while a nondeterministic catalog may indicate an implementation problem. Avoid measuring health only by HTTP availability; an endpoint can be reachable while returning the wrong scoped catalog or depending on state from a previous request.

Human oversight remains part of the MCP tools guidance. There should always be a human in the loop with the ability to deny tool invocations for trust and safety. The orchestration experience should make consequential calls legible: show the selected tool, intended action, relevant target, and meaningful arguments before approval. Do not bury approval behind a generic continue button that gives the operator no basis for judgment.

Human review should be enforceable rather than advisory. If a tool requires approval, the workflow should not invoke it until the approval condition is recorded. A remote endpoint should also enforce any application-level approval reference it receives rather than trusting an agent's assertion that approval occurred. The stateless model supports this pattern well because approval can be represented as explicit, durable state checked on the relevant request.

Finally, document the integration contract. Record that the endpoint uses modern sessionless Streamable HTTP, how it authenticates each request, how origins are validated, which credentials shape tools/list, how catalogs are refreshed, which parameters map to ers, and which tools return durable handles. Documentation should also name the operating owner and the process for disabling access. This gives platform engineers and product or operations teams a shared basis for reviewing changes without relying on knowledge held by one implementer.

Securely adding remote tool endpoints after the MCP stateless update means embracing the request as the complete protocol unit. Harden Streamable HTTP with origin validation, local-only binding during developer use, and authentication for every connection. Discover capabilities through a deterministic, authorization-scoped tools/list. Apply authorization again at invocation, use Mcp-Method and Mcp-Name as request context, and constrain any x-mcp-er-style parameter mappings to approved uses.

The lasting architectural rule is to make state and authority explicit. Return handles when workflows need continuity, pass them as normal arguments, and reauthorize their use on every request. Design handlers for independent, potentially retried calls, reconcile dynamic catalogs instead of trusting notifications alone, and keep a human able to deny consequential actions. With those controls, the stateless MCP model gives orchestration platforms a cleaner foundation for routing specialist agents and scaling remote tools without making security depend on connection continuity.