Where we are - and the finish line
You have built (b2-b3), connected (b4), written a client (b5), gone remote (b6), and secured it (b7). Two things remain. First, make Daybreak discoverable by publishing it to registry.modelcontextprotocol.io. Second, look forward: the 2026-07-28 revision reshapes the protocol you just learned, and because it lands days after this course, you get it decoded ahead of nearly everyone. Then a graduation trace where you narrate the whole protocol end to end.
io.github.yourname/daybreak), a server.json manifest you understand line by line, the entire 2026-07-28 change register decoded with migration advice per theme, and a checklist that makes the upgrade a non-event. Plus the graduation trace: you can now read and narrate every message MCP puts on the wire.
Publish Daybreak 6 min live
The registry (live since Sept 2025) is how servers get found. It hosts metadata, not code - your package lives on PyPI (or npm), and the registry points at it. You describe your server in a server.json manifest, authenticate with GitHub, and publish with the mcp-publisher CLI. GitHub auth locks your namespace to io.github.yourname/*, so no one can squat your name.
LiveThe manifest walkthrough - server.json for Daybreak4 min▶
mcp-publisher init generates a template; you edit it. The key fields: a namespaced name, a human description, the repository, a version, and a packages array telling installers where the artifact lives and how to run it (transport stdio for Daybreak). The name must match the mcpName you put in your package metadata.
LiveWhat a good listing looks like - description quality = adoption3 min▶
Discovery is a marketplace. Two servers that do the same thing get wildly different adoption based on their metadata. Your description and your tool descriptions are the pitch - and, as you learned in b7, tool descriptions are also what the model reads to decide what to call. Bad descriptions hurt twice.
- Say what it does in one line - "Sales and subscription analytics for Daybreak", not "an MCP server".
- Version honestly with semantic versioning; publish a new version rather than mutating an old one.
- Point at a real repo - reviewers and users check it. A README with setup + the security section from b7 builds trust.
- Respect moderation - the registry removes spam and malicious servers; a clean, accurate listing survives.
The 2026-07-28 delta, in full 10 min live
This revision finalizes 2026-07-28 - six days after this course shipped. Everything below is decoded from the release candidate; re-verify against the published spec after that date. It is the freshest material in any MCP course, and it touches things you built this term. Here is the whole change register with what to do about each.
LiveStateless core - the handshake disappears3 min▶
The biggest change. The initialize/initialized handshake and the Mcp-Session-Id header are removed. Capabilities travel in _meta on each request, and new Mcp-Method / Mcp-Name routing headers let infrastructure route without parsing the body. Any node can serve any request - horizontal scale becomes trivial.
Migration advice: keep tool handlers pure (everything from arguments, nothing from cross-request server memory) as you practiced in b6. Stateless-friendly servers barely notice the switch.
LiveDeprecations - roots, sampling, logging2 min▶
Roots, sampling, and logging are deprecated with a 12-month removal window. Two of the three client-side primitives you met in b1 are on the way out; elicitation stays. Logging as a protocol feature is deprecated too - use your host's own observability.
Migration advice: do not start new work on sampling or roots. If you have existing use, plan the 12-month exit. Build interactive UX on elicitation (b7).
LiveMCP Apps + Extensions + Tasks3 min▶
- MCP Apps (SEP-1865): servers can ship sandboxed-iframe UIs - first-class interactive surfaces, not just text. Powerful, but host support is early; treat it as a preview and watch which hosts render it.
- Extensions framework, first-class: optional capability bundles layered on the core. This is how new features ship without bloating the base protocol.
- Tasks graduated to an extension: long-running work gets a standard shape, now delivered through the extensions mechanism rather than the core.
Migration advice: keep your core server lean and standard; adopt extensions deliberately as host support lands.
Self-studySchema + error-code changes2 min read▶
- JSON Schema 2020-12 is the default for tool input schemas. If you hand-write schemas, target that draft.
- Error code change: the "invalid params / unknown tool" style error moves from
-32002to-32602. (The live error scenario in this track already shows-32602.)
Migration advice: if any code branches on the exact numeric error code, update it. Most SDKs abstract this for you.
Your migration checklist + where MCP goes 5 min live
You cannot flip to 2026-07-28 before it finalizes, but you can build today so the upgrade is a non-event. Here is the checklist, then a look at the trajectory.
LiveThe migration checklist3 min▶
Design stateless now. Tool handlers derive everything from arguments; no per-user state built up across requests in a session.
Avoid roots and sampling in new work; plan a 12-month exit for any existing use.
Keep elicitation - it survives, and it is your interactive-UX mechanism.
Validate the issuer (RFC 9207) in your auth code today; it becomes required.
Target JSON Schema 2020-12 for any hand-written tool schemas; don't hardcode the old error number.
Watch host support for MCP Apps before shipping iframe UIs; adopt extensions as they land.
Self-studyEcosystem trajectory - where MCP is heading3 min read▶
Two forces to watch. First, the registry keeps growing - as it matures out of preview, discovery and trust signals (verification, moderation, download stats) will shape which servers win, much like npm did for JavaScript. Second, governance under the Agentic AI Foundation (Linux Foundation) means the roadmap is now public and multi-vendor: stateless core, Apps, and extensions are the current bets, and the SEP process is where the next ones get argued. Translation: MCP is stabilizing into infrastructure. Betting on it is betting on a standard, not a vendor.
Write the manifest ★ 7 min · scaffold + edit
Generate and edit a real server.json for Daybreak, then dry-run the publish path.
Package Daybreak for PyPI (add an mcpName of io.github.yourname/daybreak to your package metadata so the registry can verify it).
Run mcp-publisher init and edit the generated server.json to match the Part 1 example - name, description, repository, version, the pypi package with stdio transport.
Authenticate: mcp-publisher login github, complete the device-code flow. This is what binds you to the io.github.yourname/* namespace.
mcp-publisher publish, then verify with a search against the registry API. Your server is now discoverable.
The graduation trace ★ 10 min · narrate every byte
The whole track in one exchange. A host connects to Daybreak, discovers its tools, the user asks the March question, the model calls query_sales, and the $150.00 answer comes back. Narrate each message out loud - if you can, you have graduated.
Connect + handshake (b1, b5): the client sends initialize, the server agrees on version and capabilities. On 2026-07-28 this step vanishes - say why.
Discover (b1, b2): tools/list returns query_sales with its schema - the description the model reads (b7: also the injection surface).
Call (b1, b5): the model fills {"month":"2026-03"}; the client sends tools/call; the server queries the DB.
Answer: the content array carries "$150.00, down from $271.00" back to the model, which writes the founder's answer. Now name the transport (b6) and the auth (b7) that carried it if remote.
This is the skill that separates operators from users. Most people who "use MCP" cannot read this traffic. You can build the server, write the client, deploy it, secure it, publish it, and debug it at the wire level - and you know what the next spec revision changes. That is a rare, durable skill in the agent era.
Try it yourself - this week ◐ 45-90 min total
- Publish a real toy server under your own
io.github.yourname/*namespace - even a two-tool server counts. Confirm it appears in a registry search. - Write a one-paragraph migration note for Daybreak: which of your code touches the stateless core, roots/sampling, error codes, or schemas - and what you would change.
- Set a calendar reminder for 2026-07-28 to re-verify every "changes 2026-07-28" callout in this track against the published spec and flip the framing from "coming" to "landed".
- Do the graduation trace from memory - narrate handshake → list → call → answer without looking, then say what disappears on the new spec.
Official sources covered
The capstone: registry publishing and the forward-looking spec, decoded before it finalizes. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · What does server.json actually put in the registry?
The registry hosts metadata, not artifacts. The package lives on PyPI or npm; server.json describes it and points at it. The name must match your package's mcpName, and GitHub auth locks your io.github.yourname/* namespace.
2 · What does the 2026-07-28 stateless core remove?
The handshake and session id go away; capabilities travel in _meta per request, with Mcp-Method/Mcp-Name routing headers, so any node can serve any request. Tools, resources, and Streamable HTTP all remain.
3 · Which primitives are deprecated on 2026-07-28 (12-month window)?
Roots, sampling, and logging are deprecated with a 12-month removal window. Elicitation survives - which is why b7 built interactive UX on it. The server primitives (tools, resources, prompts) are untouched.
Whole-course capstone cheat sheet · pin this
Next course: learn-ai-agents-with-phoebe - your Daybreak server becomes an agent's toolbox (coming soon)