# MCP 2026-07-28 the spec catches up with the static web > [!question] Lingering Questions > - What two tools would courtneyr.dev actually expose that scraping can't already reach? > - Does the Outpost plugin have a capability worth exposing over MCP, or is its surface entirely covered by feeds already? > - Do any of the vault's generated wiki indexes violate the "one source, many renderings" rule the post argues for? > [!tip] Article Ideas > - Audit courtneyr.dev for capabilities scraping can't reach, then decide whether standing up an MCP endpoint is warranted. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Canonical Sources Reduce Interface Drift]] — same "one source, many renderings" principle, already a Permanent note in the vault > - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] > [!quote] Vocabulary > - **SEP-2640** — the MCP proposal covering `skill://` resources, discussed as the mechanism by which one skill definition could drive multiple rendered surfaces. ## Bib capsule joost.blog analysis of the MCP protocol's 2026-07-28 revision, which makes statelessness canonical: removes the `initialize`/`initialized` handshake and the `Mcp-Session-Id` header, and publishes the spec's first formal deprecation policy. ## Author's thesis Making MCP stateless removes the last structural objection to running an MCP server on static or edge-hosted infrastructure, and the new twelve-month deprecation policy with a public registry makes the standard's churn something implementers can plan around. What the revision does not touch — deciding which capabilities a site should actually expose to agents — remains exactly as hard as before. ## Key arguments (≤3) 1. **The protocol simplification is real and structural**: a read-only MCP server shrinks to three methods and one POST call per request, with no session state to manage. 2. **The deprecation policy is the governance story**: breaking changes now ship with a dated offramp and public registry rather than either permanent backwards compatibility or surprise removal. 3. **The hard problem is unmoved**: lowering implementation cost doesn't reduce the editorial judgment of deciding what capabilities to expose. ## Claim atoms ### Protocol simplification leaves the editorial question untouched > [!quote] ID:rw_01kyq6n1n8ym926vtdfrsnr21v > The protocol got simpler. The editorial question is untouched, and it was always the real work. The most transferable claim in the piece: lowering implementation cost does not reduce the judgment work of deciding what to expose. Applies to any "we made it easier to publish X" release. ### Dated offramps make a churning standard buildable > [!quote] ID:rw_01kyq6n9qq21wvsgq043pcjehg > This is what responsible churn looks like: breaking changes with a dated offramp, not perpetual backwards compatibility and not surprise removals. A reusable governance criterion for evaluating any fast-moving dependency: does it publish a schedule for its own breaking changes? ### One source with many renderings prevents surface drift > [!quote] ID:rw_01kyq6nh6smmq2g03012w0z27m > The way out is one source of truth with multiple renderings. That holds for skills as much as for pages. Directly applicable to the vault: the same rule governs why generated wiki output and hand-maintained indexes drift apart. Already a Permanent note in the vault under different origin material. ### Stateless MCP carries identity per request in _meta > [!quote] ID:rw_01kyq6nsh66csh3qb70tt8w0qw > The initialize / initialized exchange is gone, and so is the Mcp-Session-Id header. Every request now travels on its own The concrete technical fact anyone migrating an MCP server needs; also the mechanism behind the improved cacheability and analytics the post credits to the revision. ## Permanent candidates - **Cheaper mechanics never substitute for editorial judgement** — promoted below. - **A published deprecation schedule is what makes a dependency safe to adopt** — promoted below. - The "one source, many renderings" atom duplicates [[3. Resources/Permanent Notes/Canonical Sources Reduce Interface Drift]] — connect rather than duplicate. ## Processing checklist - [x] Ported from existing deep-read (Refactor Appendix) - [x] Checked for duplicate Permanent notes — found one, linked instead of recreated; two others are fresh - [x] Connected into MOC — [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] - [ ] Read the MCP 2026-07-28 changelog directly and note which changes affect any endpoint I maintain ## Metadata - Source: [[3. Resources/Literature Notes/MCP 2026-07-28 the spec catches up with the static web]] ## Links - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — standards governance for the agent-facing web is squarely this MOC's territory - [[3. Resources/Permanent Notes/Canonical Sources Reduce Interface Drift]] — evidence-for; independent source for the same one-source-many-renderings claim