Day 26 Theory — MCP Architecture and the 2026-07-28 Protocol Model

Lesson goal

Today we apply the 2026-07-28 Model Context Protocol (MCP) mental model to the Service Desk.

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

• distinguish host, client and server responsibilities,
• separate MCP protocol semantics from transport,
• explain why the old initialize / initialized handshake is no longer part of the 2026-07-28 core,
• explain why Mcp-Session-Id is no longer a mandatory protocol session mechanism,
• construct a self-contained Streamable HTTP tool request,
• explain Mcp-Method, Mcp-Name and request _meta,
• explain optional server/discover,
• describe Multi Round-Trip Requests (MRTR),
• keep authorization and application state outside “protocol magic.”

What changed in the Service Desk today?

Previously, the Service Desk reached capabilities through application-specific Python interfaces.

Today we introduce a standards-based boundary:

Service Desk Host
      |
      | MCP client behavior
      v
MCP protocol boundary
      |
      v
Capability server
      |
      +-- tools
      +-- resources
      +-- other supported MCP capability surfaces

The protocol standardizes capability exchange. The Service Desk still owns user identity, permissions and product policy.

Architecture: 2026-07-28 Streamable HTTP

graph LR
    Host[Service Desk Host] -->|POST /mcp\nself-contained request| Gateway[HTTP Gateway]
    Gateway -->|Mcp-Method / Mcp-Name| ServerA[MCP Server Instance A]
    Gateway --> ServerB[MCP Server Instance B]
    ServerA -->|JSON-RPC response| Host
    ServerB -->|JSON-RPC response| Host

The important production consequence is that a request does not need to be pinned to the server instance that previously created a protocol session.

First: identify the protocol generation

Older MCP material commonly shows:

initialize
   ↓
initialized
   ↓
Mcp-Session-Id
   ↓
later requests

That is not the 2026-07-28 core lifecycle.

For the version taught in this course:

self-contained request
   ↓
server handles request
   ↓
response

If discovery is needed first, server/discover is available as an optional RPC. It is not a mandatory replacement handshake.

A self-contained tool call

The official 2026-07-28 model makes important routing information explicit on the HTTP request.

A representative request looks like:

POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_kb

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_kb",
    "arguments": {
      "query": "VPN certificate renewal"
    },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "service-desk",
        "version": "1.0.0"
      }
    }
  }
}

What the headers are doing

MCP-Protocol-Version : Identifies the MCP protocol version used by the request.

Mcp-Method : Makes the protocol method visible to HTTP infrastructure.

Mcp-Name : Makes a relevant capability name visible for operations such as tool calls.

This allows gateways and policy systems to reason about protocol operations without inferring intent from model-generated prose.

The same idea in Python

The goal of this example is to make the HTTP contract visible. Production applications may use the current MCP SDK rather than constructing every request manually.

import httpx

MCP_URL = "https://mcp.internal.example/mcp"

async def call_search_kb(query: str) -> dict:
    payload = {
        "jsonrpc": "2.0",
        "id": 1,
        "method": "tools/call",
        "params": {
            "name": "search_kb",
            "arguments": {"query": query},
            "_meta": {
                "io.modelcontextprotocol/clientInfo": {
                    "name": "service-desk",
                    "version": "1.0.0",
                }
            },
        },
    }

    headers = {
        "MCP-Protocol-Version": "2026-07-28",
        "Mcp-Method": "tools/call",
        "Mcp-Name": "search_kb",
    }

    async with httpx.AsyncClient(timeout=15.0) as client:
        response = await client.post(MCP_URL, json=payload, headers=headers)
        response.raise_for_status()
        result = response.json()

    if result.get("jsonrpc") != "2.0" or result.get("id") != 1:
        raise ValueError("Unexpected MCP JSON-RPC response")

    return result

Do not memorize the timeout value. It is an example. Production timeout policy belongs to the application and dependency contract.

Why removing the protocol session matters

Imagine three identical MCP server instances behind a load balancer.

Older session-coupled thinking often creates pressure for:

client -> instance A
           |
           +-- session state

future client call must somehow reach A again

With the stateless 2026-07-28 core:

request 1 -> instance A
request 2 -> instance C
request 3 -> instance B

Each request contains enough protocol context to be handled independently.

This simplifies ordinary horizontal scaling and reduces hidden transport-session coupling.

Stateless protocol does not ban stateful applications

Suppose a tool starts a browser session and returns:

{
  "browser_id": "browser_427"
}

A later tool call may include that handle explicitly:

{
  "name": "browser_click",
  "arguments": {
    "browser_id": "browser_427",
    "selector": "#submit"
  }
}

The application is stateful, but the state dependency is explicit in the application/tool contract.

Do not teach:

“MCP servers cannot store state.”

Teach:

“The 2026-07-28 core does not require a hidden protocol-level session.”

Optional discovery

A client may want to learn server capabilities before making other calls.

The current protocol provides optional server/discover behavior for that purpose.

Conceptually:

Client -> server/discover
Server -> advertised capabilities

Discovery answers what the server advertises.

It does not answer whether the current user is authorized to invoke every advertised operation.

List results and caching

The 2026-07-28 direction also improves cacheability of list-style capability results.

Why does that matter?

A large tool catalog does not need to be rediscovered and injected repeatedly when the server indicates it can be cached appropriately.

Benefits can include:

• lower latency,
• fewer repeated protocol calls,
• more stable upstream prompt/context construction.

Caching still needs invalidation semantics. Never assume a tool catalog is valid forever.

Multi Round-Trip Requests (MRTR)

Some logical operations require additional input after work has started.

Example:

Service Desk -> call privileged remediation tool
MCP server   -> input_required: approval needed
Service Desk -> obtain approved human input
Service Desk -> continue/retry operation with inputResponses
MCP server   -> result

MRTR allows this without reintroducing a mandatory long-lived bidirectional protocol session.

MRTR means Multi Round-Trip Requests. It does not mean arbitrary hidden conversation state.

MCP is not authorization

Suppose the model requests:

reset_password(user="ceo")

MCP can standardize how that tool call is represented and transported.

It does not prove the current caller is allowed to perform it.

The application security path should still look like:

authenticated caller
      |
      v
authorization policy
      |
      v
allowed server + tool?
      |
      v
validate arguments
      |
      v
execute using least privilege
      |
      v
audit outcome

The model proposes. Deterministic application policy decides.

Capability metadata is also input

Tool names, descriptions and schemas can influence model behavior.

Treat capability metadata from an external server as data crossing a trust boundary.

A valid MCP schema does not prove that:

• the server is trusted,
• the tool implementation is safe,
• the description is honest,
• the caller should be allowed to invoke it.

We will explore this security problem in depth on Day 29.

Migration exercise: identify outdated assumptions

For each statement, decide whether it belongs to the old lifecycle or the 2026-07-28 core.

Statement A

Every client must call initialize() before calling a tool.

Answer: Old lifecycle assumption. Not part of the 2026-07-28 stateless core.

Statement B

Every later HTTP request must carry Mcp-Session-Id.

Answer: Old lifecycle assumption. The protocol-level session header is retired in the 2026-07-28 core.

Statement C

An MCP application may still use a database or explicit application handle across calls.

Answer: Correct. Stateless protocol does not forbid stateful application behavior.

Statement D

A client may optionally discover server capabilities before making other calls.

Answer: Correct. Discovery is optional rather than a mandatory initialization handshake.

Debugging a 2026-07-28 HTTP request

When a call fails, inspect the protocol boundary systematically.

1. Is MCP-Protocol-Version the expected value?
2. Does Mcp-Method match the JSON-RPC method?
3. Does Mcp-Name match the named capability where required?
4. Does the JSON-RPC request have a valid id, method and params shape?
5. Is client metadata present as required by the current contract?
6. Did authentication/authorization reject the request before tool execution?
7. Is the server returning a protocol error or an HTTP infrastructure error?
8. Are you accidentally reading documentation for a previous MCP version?

Common mistakes

1. Mixing 2025-11-25 handshake examples into a 2026-07-28 lesson.
2. Saying stateless protocol means the application cannot persist state.
3. Treating server/discover as mandatory initialization.
4. Treating discovery as authorization.
5. Using a discovered tool description as trusted policy.
6. Assuming a protocol standard automatically provides safe credentials or least privilege.

Practical lab

Work in:

service-desk-day-26/

Task A — find protocol-generation assumptions

Inspect the Day 26 implementation and tests for any use of:

initialize
initialized
Mcp-Session-Id

For material labelled 2026-07-28, explain whether each occurrence is valid, migration comparison material, or stale code that should be removed.

Task B — inspect a self-contained request

Trace one tools/call request and identify:

• HTTP routing headers,
• JSON-RPC request ID,
• method,
• tool name,
• arguments,
• client metadata.

Task C — separate protocol and security

For a privileged Service Desk tool, write down:

what MCP validates/transports

versus:

what the Service Desk authorization layer must decide

Task D — explain state explicitly

Design a two-call workflow that returns an explicit handle on call 1 and requires that handle on call 2.

Explain why this is compatible with a stateless protocol core.

Task E — run tests

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

If tests encode the old mandatory initialization/session model, treat that as a course bug—not as evidence that the old model is current.

Knowledge check

1. What was removed from the 2026-07-28 core lifecycle?

The mandatory initialize / initialized handshake and protocol-level Mcp-Session-Id session model were retired.

2. Does that mean every MCP server must be application-stateless?

No. Application state may be persisted and referenced explicitly through tool arguments/handles or other application mechanisms.

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

They make protocol operation metadata visible to HTTP routing, policy and observability infrastructure.

4. Is server/discover mandatory?

No. It is an optional way to learn server capabilities before other calls.

5. What does MCP not decide?

It does not decide whether the authenticated user is authorized to perform a business action, whether a server is trusted, or whether a side effect is safe for the product.

Scenario

A team migrates to MCP 2026-07-28 but keeps sticky load-balancer routing because “the client must return to the server that initialized its session.”

What is wrong?

Answer: That assumption belongs to the older protocol session lifecycle. The 2026-07-28 core is designed around self-contained requests without the retired mandatory protocol session. Application-specific state may still exist, but it should not be confused with the old transport-level session requirement.

Key takeaways

• Always identify the MCP specification version before copying examples.
• MCP 2026-07-28 uses a stateless protocol core with self-contained requests.
• The old mandatory initialize handshake and Mcp-Session-Id model are retired.
• server/discover is optional.
• MRTR supports defined multi-exchange interactions without requiring a permanent bidirectional protocol session.
• Protocol interoperability does not replace authentication, authorization, trust policy or side-effect safety.

Official references

• MCP 2026-07-28 release explanation: https://blog.modelcontextprotocol.io/posts/2026-07-28/
• Model Context Protocol specification site: https://modelcontextprotocol.io/
• MCP Python SDK: https://github.com/modelcontextprotocol/python-sdk