The MCP server author’s checklist

October 24, 2026 · Part 35 of 35

Thirty-four parts is a lot to hold in your head while you build. So this last part folds the series into one page: a checklist to keep beside a pull request, each item linked to the part that explains it, the seven ideas I’d keep, and what I’m watching next.

This is part 35 of my series on what a Model Context Protocol (MCP) server does under the 2026-07-28 specification, and the last, after part 34’s reference architecture. The facts are as I read them in October 2026.

In brief

1. An MCP server in 2026 is a small, well-defined platform, not a list of tools: five layers, from its protocol duties to its extensions.
2. A MUST, SHOULD, MUST NOT or SHOULD NOT in the checklist is the specification’s word; the other checks are practice I recommend, across eight areas from the protocol core to compatibility.
3. Deprecations run on more than one clock. Roots, sampling and logging can go no earlier than the first revision on or after 2027-07-28, the HTTP with Server-Sent Events (HTTP+SSE) transport sooner, and Dynamic Client Registration gives way to Client ID Metadata Documents.
4. Extensions sit on top of a core that works everywhere, and your telemetry shows which of them your users’ hosts support.

The series on one page

An MCP server in 2026 describes itself through server/discover and handles every request on its own terms, reading the protocol version, capabilities and identity from _meta, and trace context when the client sends it. It tells clients how long they can cache what it says, asks for missing input with Multi Round-Trip Requests (MRTR) without holding a connection open, reports progress, and stops when told to.

When it uses authorization over HTTP, it validates every token as an OAuth resource server and never forwards one. It offers tools to the model, resources to the application and prompts to the user, and where both sides agree it goes further: it renders interfaces, runs long jobs and ships whole workflows as verified skills.

Each band covers a run of parts, top to bottom: parts 3 to 7, parts 8 to 12, parts 13 to 17, parts 18 to 22 and parts 23 to 29. Part 1 and part 2 set the scene, and parts 30 to 34 put it together.

The checklist

Here is my guide’s checklist, condensed. The marks in capitals are the specification’s words. The unmarked checks are practice I recommend, though some are the specification’s rules too; the part in the last column has the detail.

Protocol core

Transport

Features

Interaction patterns

Security

Operations

Extensions

Compatibility

Those dates come from the registry of deprecated features. Under SEP-2596, twelve months is the usual floor, but a feature that presents an active security risk can go after at least 90 days. When a window closes, the feature only becomes eligible for removal; taking it out is the core maintainers’ decision.

Hosts can ask for more than the specification, such as shorter tool names and required annotations; my rulebook of what each AI host requires lists them. For testing in both protocol eras, my review of MCP testing tools covers the options, from the official conformance suite to the MCP Inspector.

Seven ideas to keep

1. Stateless by default, stateful by design. There are no sessions, so handles, tasks and listen streams are deliberate choices with a durable store behind them.
2. Control determines the primitive. The model decides on tools, the application on resources and the user on prompts (part 12). Server instructions sit beside all three, though whether they reach the model is the host’s choice.
3. Ask, don’t block. MRTR turns “wait for the user” into “return and retry”. Protect requestState, and do nothing irreversible before the last input round.
4. Two audiences for every result. content for the model and text-only hosts, structuredContent for programs and apps. Under the MCP Apps convention, structuredContent stays out of the model’s context, so write content that stands on its own. Hosts differ, though: Claude Code and its Agent software development kit (SDK) pass structuredContent to the model in place of the text blocks, and ChatGPT lets the model see it.
5. Security lives in the server. Annotations, instructions and descriptions are hints. Validation, authorization, audience checks and rate limits are what protect you.
6. Extensions are negotiated per request and degrade gracefully. Build the core so it works everywhere, then add MCP Apps, Tasks and Skills where hosts support them.
7. Your telemetry is your support matrix. clientInfo and the capabilities each request declares show what your users’ hosts can really do.

What to watch next

What I’m watching, as of October 2026:

• Tasks moving into the core. SEP-2663, the Tasks extension, states the intent to promote it once it stabilizes and is widely adopted (part 26).
• Skills adoption. The specification is final, and the official SDKs are catching up: all four, for Go, TypeScript, Python and C#, have open pull requests, and the Go SDK’s already passes the conformance suite (part 27). Hosts will decide how fast servers can rely on it.
• Interceptors. A standard policy layer for validation, redaction and audit would change how enterprises deploy MCP. The proposal, SEP-2624, is still open (part 29).
• Host adoption of 2026-07-28. The removal clock for roots, sampling and logging is running, and part 31 shows where each host stands.
• Enterprise identity. Enterprise-Managed Authorization in mainstream hosts and identity providers would remove most of the consent friction in corporate rollouts (part 28).

The protocol has grown from a way to give models tools into a full contract between AI applications and the systems they work with. I think the servers that do well will be the ones that treat that contract carefully: honest descriptions, strict validation, graceful degradation and good observability. Thank you for reading along. I hope the series makes your next server a little easier to build.

Method and caveats

• Built from my guide’s checklist and conclusion, and written against the 2026-07-28 specification. Product facts are as of October 2026.
• The MUST, SHOULD, MUST NOT and SHOULD NOT marks are my guide’s, plus five that its own chapters or the specification set: -32021, prompt validation, x-mcp-header, progress rate limits and content in MCP Apps.
• Where the specification is more precise than my notes (the deprecation windows and Dynamic Client Registration, caching hints, Mcp-Name, -32021, optional authorization, trace context and instructions), this article follows the specification.
• Where the hosts’ docs and the extensions’ records are newer (structuredContent in hosts, the SDKs’ Skills work, the Interceptors proposal), it follows them, as checked on 8 October 2026.