MCP Concepts: Servers, Clients, and Capabilities

Goal

Explain MCP client/server roles and capability discovery in the pinned 2026-07-28 release without carrying over old session assumptions.

Three roles, three responsibilities

Imagine a school help-desk app. A student asks the app, "What books about volcanoes are available?" The host application is the help-desk app the student is using. Inside it, an MCP client is the connector that knows how to send an MCP-shaped request. The library-side program is the MCP server. It advertises capabilities such as searching the catalog or reading a book record.

Those roles answer different questions. The host knows the student's goal and the school's rules. The client knows how to speak the protocol. The server knows which capabilities it offers. A server saying "I can search the catalog" is like a service desk listing what it can do; it does not decide whether a particular student may access a restricted record.

user → host application → MCP client → MCP server
       local policy       protocol     advertised capability

Pin the protocol version

This Lesson also depends on the protocol version. The course uses MCP 2026-07-28. Older examples may show an initialization handshake or session ID that no longer matches this release. The pinned core uses stateless request/response.

Here, stateless means that one protocol request should carry enough information to be understood at that boundary without depending on a hidden earlier handshake. Think of mailing forms where every envelope includes the required form type and sender information instead of saying, "Use the details from the envelope I sent yesterday." Your overall app can still remember the student's task, approvals, and history.

In this release, each core request carries the information needed to understand it, including protocol and client metadata. The server does not need to remember a previous protocol handshake to interpret the request.

Discover capabilities without trusting them

A client may use the optional server/discover operation to ask what the server supports. Discovery helps compatibility and planning, but the returned description is still remote data that local policy must check.

The HTTP transport can also put operation information in headers such as Mcp-Method and Mcp-Name. Gateways can use them for routing or policy. The headers and body must agree.

Stateless MCP does not mean your application has no state. The Level 12 harness can still keep durable tasks, approvals, operation IDs, and memory. Only the protocol core avoids depending on a remembered session.

Keep local authority in the host

Narrow capabilities when they enter the host. A server may advertise ten tools while one user role is allowed to use only two. The host can also reject a tool whose schema or security rules do not fit local requirements.

Keep version evidence in traces. If versions disagree, record the expected and observed versions instead of hiding the problem as a generic tool error.

Trace the full request boundary

Use this flow: receive request → validate version and shape → apply local capability policy → perform or reject → trace the result. MCP standardizes communication; the harness keeps authority.

Consider a host that wants to let an agent read a support ticket. Discovery may report a ticket-reading capability and describe its input shape. That tells the host what the server says it can do. It does not yet answer whether this user may read that ticket. The host should first check the protocol version and discovered schema, then apply its own rule for the current user and ticket. Only after both checks pass should it send the operation. This separation is important: discovery supports compatibility, while local policy controls authority.

Predict

A developer copies an old MCP example that requires a session handshake. What should they do for this course?

Check it against the pinned 2026-07-28 release because the core is stateless and earlier session assumptions may be obsoleteKeep the old handshake because all MCP releases use the same session lifecycleRemove protocol-version checks so either example can run unchanged

Run the local Lab

Run:

python3 labs/notebooks/level-13/l13-03-mcp-concepts.py

The Lab validates a small MCP 2026-07-28 request fixture.

1. Run it unchanged and confirm the request ends with PASS: pinned MCP request and discovery fixture are compatible.
2. Find "protocol_version": PINNED inside request. Keep the PINNED = "2026-07-28" course version unchanged. Before editing, predict which compatibility check should fail if the request alone claims an older version.
3. Change only the request field to "protocol_version": "2025-11-25", then rerun.
4. Confirm that the script reports the request version does not match the pinned version and exits non-zero. Restore the starter afterward.

Loading lab…

Quick Check

1. What changed at the MCP core in the pinned 2026-07-28 release?

Tools were removed and resources remainedCore requests became statelessVersion information was removed from requests

2. What is server/discover used for in this release?

To create a mandatory persistent session for all later requestsTo discover server capabilities before later operationsTo grant every server capability local authorization

3. Where should user authorization remain?

In the model prompt, since the protocol already checks syntaxIn the host/harness policy that maps remote capabilities to allowed local actionsInside server discovery metadata alone

0 of 3 questions answered.

Explain it back

Explain how a stateless MCP request can still participate in a stateful user task. Name which state belongs to the protocol request and which remains in the Level 12 harness.

Key Takeaways

• Level 13 MCP examples are pinned to 2026-07-28.
• The pinned core is stateless request/response.
• Clients may use server/discover for capability information.
• Protocol metadata can support routing and validation.
• Host policy still decides which capabilities become executable.

Next Lesson

Next, L13.4 — MCP Server Design focuses on exposing a narrow, testable capability surface.

References

• Model Context Protocol, 2026-07-28 Specification.
• Model Context Protocol, 2026-07-28 Specification Release.