Day 28 Theory — Remote MCP over Streamable HTTP: Auth, Discovery and Caching

Lesson goal

Yesterday our MCP server lived as a local child process. Today we move the capability boundary across a network using Streamable HTTP.

By the end of the lesson you should be able to:

• explain what changes when MCP becomes remote,
• construct a self-contained 2026-07-28 MCP HTTP request,
• distinguish authentication from authorization,
• explain how gateways can use Mcp-Method and Mcp-Name,
• use optional server discovery without treating it as a mandatory handshake,
• reason about cacheable capability listings and invalidation,
• identify SSRF, token and tenant-boundary risks,
• debug transport, auth and protocol failures separately.

What changed in the Service Desk today?

Day 27:

Host -> local STDIO child process

Day 28:

graph LR
    Host[Service Desk Host] -->|HTTPS + auth| Gateway[Gateway / Load Balancer]
    Gateway -->|Mcp-Method / Mcp-Name| MCP[MCP Server Pool]
    MCP --> Ticket[Ticket Service]
    MCP --> KB[Knowledge Service]

The protocol concepts remain MCP, but the network introduces new concerns: TLS, authentication, authorization, routing, latency, retries, DNS, proxies and remote trust.

Streamable HTTP is a transport

Do not confuse the protocol operation with the transport.

A request still expresses an MCP method such as:

tools/call

Streamable HTTP defines how that protocol exchange travels remotely.

This distinction matters when debugging:

HTTP 401        -> authentication/infrastructure layer
HTTP timeout    -> transport/dependency layer
JSON-RPC error  -> MCP protocol/application layer
Tool error      -> capability implementation layer

Different layer, different fix.

A current self-contained request

Representative 2026-07-28 request:

POST /mcp HTTP/1.1
Host: mcp.internal.example
Authorization: Bearer <access-token>
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_ticket

{
  "jsonrpc": "2.0",
  "id": 41,
  "method": "tools/call",
  "params": {
    "name": "get_ticket",
    "arguments": {
      "ticket_id": "INC-4821"
    },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "service-desk",
        "version": "1.0.0"
      }
    }
  }
}

Notice what is not required by the 2026-07-28 core:

initialize handshake
mandatory Mcp-Session-Id
sticky server instance

Authentication answers “who is calling?”

A remote MCP endpoint should not accept privileged capability calls merely because the caller knows the URL.

Authentication may use the approved mechanism for the deployment, for example OAuth/OIDC-issued bearer credentials or another enterprise identity mechanism.

The important principle is:

credential -> validated identity/claims

Do not log raw bearer tokens.

Authorization answers “may this identity perform this action?”

After authenticating the caller, evaluate policy.

Example:

Authenticated identity: service-desk-prod
User context: alice@example.com
Tenant: ACME
Requested tool: reset_password
Target: bob@example.com

The server/application still needs to decide whether this call is allowed.

Authentication success does not imply:

all tools allowed
all tenants allowed
all records readable
all mutations allowed

Use least privilege and enforce policy at the capability/data boundary.

Why Mcp-Method and Mcp-Name help infrastructure

Because the current HTTP request exposes protocol routing metadata, a gateway can apply controls such as:

tools/list -> lower-risk read route

tools/call + search_kb -> allowed for support app

tools/call + reset_password -> stricter policy / different backend

This is useful for:

• routing,
• metrics,
• authorization policy integration,
• rate limits,
• audit categorization.

But a header supplied by the caller is not itself proof of authorization. Server logic must ensure header/body semantics are consistent and enforce policy.

Optional discovery

If the client needs to learn server capabilities, the 2026-07-28 protocol provides optional discovery.

Mental model:

client -> server/discover
server -> capability information

Discovery is not a login handshake and is not required before every tool call.

It also does not mean every discovered capability should be shown to every model/user. The host can filter capabilities according to product policy.

Capability-list caching

Repeatedly fetching large tool/resource catalogs can waste latency and tokens.

Where the current protocol/server response permits caching, a client or intermediary can reuse list results for an appropriate period.

Cache design still needs answers to:

• What is the cache key?
• Does tenant/user scope affect the result?
• How long is it valid?
• How does the client detect/handle capability changes?
• Can authorization changes invalidate it?

Never share one cached privileged tool list across tenants if the visible capabilities are identity-dependent.

Remote retries require operation semantics

A network timeout does not prove the server performed no work.

For a read-only get_ticket, a retry may be straightforward under the API's contract.

For a mutation, a timeout can be ambiguous:

client -> tool mutation -> server performs action
client <- response lost / timeout

Blind retry can duplicate the effect.

Use the idempotency principles from Day 22 and provider/tool-specific semantics before retrying side effects.

SSRF and endpoint trust

If your application accepts an MCP server URL from untrusted input and then performs server-side HTTP requests, you can create a Server-Side Request Forgery (SSRF) path.

For enterprise integrations, apply controls such as:

• approved server registry/allowlist,
• URL/scheme validation,
• DNS/IP egress policy,
• block metadata/internal administrative endpoints unless explicitly required,
• TLS verification,
• network segmentation.

Do not let the model choose an arbitrary URL and tell your backend to connect to it.

Token forwarding risk

A host may have powerful credentials for many systems.

Do not forward a broad host credential to every remote MCP server.

Ask:

What is the minimum credential this server needs for this call?

Prefer audience/scope-restricted credentials and explicit delegation mechanisms appropriate to the environment.

Tenant isolation

For multi-tenant Service Desk traffic, tenant identity must survive every boundary:

incoming authenticated request
       ↓
tenant/user context
       ↓
MCP authorization
       ↓
backend data filter

Do not rely on a model prompt such as:

“Only read this user's tenant data.”

Tenant isolation belongs in deterministic policy and data access.

Debugging remote MCP

HTTP 401 / 403

Inspect:

• token validity,
• audience/scope,
• identity mapping,
• authorization policy.

HTTP 404

Check route/base URL and deployment routing before changing JSON-RPC payloads.

HTTP 429

Inspect rate-limit policy and retry guidance. Do not create a retry storm.

HTTP 5xx

Determine whether failure is gateway, MCP server or downstream capability. Use trace/request IDs.

JSON-RPC error with HTTP success

The HTTP transport worked. Investigate MCP method/params/tool behavior.

Stale tool list

Inspect cache key, TTL/revalidation and whether capability visibility changed with identity/tenant.

Practical lab

Work in:

service-desk-day-28/

Task A — trace one request by layer

For a remote get_ticket call, annotate:

DNS/TLS
HTTP auth
MCP headers
JSON-RPC method
argument validation
authorization
backend lookup
response

Task B — authorization test

Use two identities/roles and prove that authentication alone does not grant the same tool access.

Task C — cache test

Exercise capability discovery/listing twice and show when a cached result can be reused.

Then change the relevant identity/version/capability state and prove stale data is not reused incorrectly.

Task D — remote failure test

Simulate one of:

• 401,
• 429,
• timeout,
• malformed JSON-RPC response.

Explain which layer owns the recovery.

Task E — endpoint trust test

Attempt to configure an unapproved MCP URL and verify application policy rejects it before making a request.

Task F — run the Day 28 tests

cd service-desk-day-28
PYTHONPATH=. pytest -q

Map each important test to one production invariant rather than treating pass count as the learning objective.

Knowledge check

1. What changed from STDIO to Streamable HTTP?

The capability server is now reached across a network transport, adding TLS/auth/routing/latency/trust concerns. MCP protocol responsibilities remain distinct from the transport.

2. What is the difference between authentication and authorization?

Authentication establishes caller identity; authorization decides whether that identity may perform a specific action on a specific resource.

3. Why are Mcp-Method and Mcp-Name useful?

They expose protocol routing metadata to HTTP infrastructure for routing, policy and observability, but they are not authorization by themselves.

4. Is server/discover mandatory before every request?

No. It is optional discovery, not a replacement mandatory handshake.

5. Why is caching capability lists potentially security-sensitive?

Visible capabilities can depend on server version, tenant, identity or policy; a cache with the wrong key/invalidation can expose stale or unauthorized capability metadata.

Scenario

A backend lets the LLM return any mcp_server_url, then connects to it using a service token with broad internal access.

What are the risks?

Answer: This can create SSRF and credential-delegation exposure. Restrict server destinations through deterministic policy, validate network targets, and use least-privilege credentials scoped for the approved remote MCP service.

Key takeaways

• Streamable HTTP moves MCP across a network; protocol and transport remain separate concepts.
• The 2026-07-28 core uses self-contained requests rather than mandatory initialization/session coupling.
• Authenticate the caller, then authorize the exact tool/resource operation.
• Use protocol-visible routing metadata without trusting caller-supplied headers as policy decisions.
• Cache discovery/list results only with correct scope and invalidation.
• Protect remote server selection against SSRF and credential leakage.
• Retry remote side effects only when the operation contract makes repetition safe.

Official references

• Model Context Protocol specification: https://modelcontextprotocol.io/
• MCP 2026-07-28 release: https://blog.modelcontextprotocol.io/posts/2026-07-28/
• OAuth 2.0 Authorization Framework: https://datatracker.ietf.org/doc/html/rfc6749