Editorial policy
How we research and update articles
Published 25 August 2026 · Updated 8 October 2026 · Applies to every guide on MCP Blog
Evidence hierarchy
Normative protocol claims should come from the applicable version of the MCP specification or an incorporated standard. Historical claims favor repository history, dated specifications, governance records, and first-party announcements. Product behavior favors current first-party documentation. Security coverage distinguishes the protocol’s trust model from vulnerabilities in an SDK, Inspector, server, Registry, host, package, deployment, authorization layer, or model/data boundary.
The source library links the specifications, product documentation and other references used in the articles. A vendor's support statement describes what it offers; tests are needed to establish how a particular implementation behaves.
Version before generalization
MCP changed from a session-oriented core to a stateless core in the 2026-07-28 revision. A statement about initialization, capability negotiation, server-initiated core requests, or transport sessions can be correct for an older revision and incorrect for the current one.
The protocol-version cornerstone compares five principal public revisions beginning with 2024-11-05. The official releases page also contains a pre-launch 2024-10-07 tag, which is disclosed separately rather than silently forced into that five-row comparison. Technical guides show an “applies to” version, label legacy behavior, and identify dual-era compatibility where relevant. Pages that depend on live documentation carry a visible review date and should be rechecked more often than durable history pages.
Confidence and durability are separate
Claims in the research registers are marked verified when a direct source establishes them, strongly supported when several sources support a careful synthesis, or inferred when the conclusion is useful but cannot be proven directly from the public record.
Durability describes maintenance risk: durable history or normative text is unlikely to change; periodically review material can drift; and live-check required facts—such as affected and patched versions, current SDK state, product plans, Registry or extension status, roadmap claims, ecosystem counts, and the latest released revision—must be rechecked before reuse.
Current product support is a snapshot
Vendor support is classified by role and capability rather than by the vague phrase “supports MCP.” We record local and remote paths, transport notes, product surfaces, plan limitations, and documented capabilities. A community wrapper for a vendor’s API is not treated as official vendor adoption.
The host compatibility matrix is a first-party documentation review, not an independently executed interoperability test. Every row carries an exact check date and a live-check classification. The protocol-version package’s SDK normalization publishes Rust as Tier 1 from the official page checked August 26, 2026 while retaining the package’s Tier 2 snapshot. The MCP-versus-A2A package likewise date-stamps SDK and vendor implementation records, distinguishes the negotiated A2A stable 1.0 line from specification patch tags, and does not infer interoperability from documentation alone. The MCP Apps review corrects the archive’s stale Cursor status, separates VS Code’s launch record from its current Experimental setting label, and updates OpenAI’s historical Apps SDK framing to current MCP Apps-first UI and Plugins Directory guidance. The local/remote review records Zed's documented local and remote paths, distinguishes Cursor Cloud Agents from the Cursor IDE, scopes ChatGPT's private-endpoint path to Secure MCP Tunnel guidance, uses Cloudflare's current stateless handler instead of its deprecated stateful API, and retains service-specific version and availability caveats for AWS, Azure, and Google Cloud. SDK tiers, package versions, host behavior, the latest specifications, extensions, authorization, Registry behavior, governance, roadmaps, release candidates, and current deprecation state all remain live-check required.
Fact, observation, and inference
We write normative requirements as requirements only when a specification does. We describe observed implementation behavior as observation, with a test date where possible. We label inference when a conclusion combines multiple sources rather than appearing directly in one of them.
We do not turn roadmap priorities into shipped features, announcements into market-share claims, or repository popularity into a security endorsement. Security findings are attributed to the affected protocol, SDK, host, server, package, deployment, authorization layer, or model/data boundary rather than to “MCP” generically.
Review cycle and update triggers
Monthly: recheck vendor support, Registry status, SDK tiers, and security advisories. Quarterly: repeat the search-result gap review and internal-link audit. At every protocol release: refreeze current architecture, FAQs, matrices, and migration guidance. Annually: audit outbound links, redirects, structured data, deprecated terms, and visuals.
An earlier review is triggered by a new specification or release candidate, a feature changing lifecycle state, an extension or Registry status change, a material host update, an official SDK tier change, a security advisory, a governance change, or a search structured-data policy change.
Corrections preserve the record
Corrections should be specific, linked to evidence, and sent to editor@mcpblog.org. When a current claim becomes obsolete, we update the current section, retain the former behavior in its historical context, identify the date and revision that changed it, and update the evidence and claim registers. Material article changes appear in a visible update log and modified date.
Automation and AI assistance
AI tools assist with research, drafting and editing. Automated checks validate links, code and the website. We cite the underlying sources and identify which examples were actually tested. Generated summaries are not primary evidence.
Research limitations
Public repositories cannot prove when private design work began or establish one definitive first internal MCP server. Product documentation may describe staged rollouts incompletely. Registry entries, package downloads, GitHub stars, and directory counts are not reliable proxies for active adoption, unique users, security, or production quality. Protocol compatibility likewise does not guarantee identical host behavior.
The 48-record security timeline is a package inventory, not a prevalence measure and not a count of universal MCP protocol flaws. A listed advisory applies to the named component and recorded range; fields marked live-check required must be reopened against the primary advisory before publication or reuse.
The current keyword and result-gap review is qualitative and does not use a paid search-volume dataset. We do not represent it as one.
Public data and package integrity
Articles link to source records and downloadable comparison data. Where an example has been run, we state the versions, commands, outcomes and limits of the test.
Research-file provenance and known gaps
The server cornerstone publishes a normalized 81-claim register, 551-source evidence manifest, host snapshot, and 61-record content plan. The function-calling cornerstone separately publishes its 109 claims, 29 comparison dimensions, 36 myth corrections, 61 briefs, and other normalized research tables. The security cornerstone publishes 98 claims, a 48-record vulnerability timeline, 50 FAQ answers, 15 visual briefs, and a 71-brief ranked content plan. The architecture cornerstone publishes 122 claims, a 30-row role matrix, 16 product classifications, 59 FAQ answers, and eleven other normalized research surfaces. The primitive cornerstone publishes 120 claims, a 25-row comparison, an 11-surface host snapshot, 50 FAQ answers, and twelve additional normalized surfaces.
The protocol-version cornerstone publishes 127 claims, a 5-revision matrix, a 12-scenario interoperability matrix, 30 breaking changes, 8 public deprecation or lifecycle rows, a 10-SDK audit, an 11-product disclosure audit, 51 FAQs, 35 myth corrections, and the 72-brief guarded plan. The deprecation endpoint distinguishes 7 raw package rows from one current-registry supplemental row covering the two deprecated Sampling includeContext values. Package-local IDs remain alongside canonical site IDs.
The MCP-versus-A2A cornerstone publishes a 125-claim register, a 28-row master comparison, 12 tools-versus-skills rows, 17 Task-model rows, a 12-row discovery matrix, a protocol-selection framework, combined reference architectures and security controls, 50 FAQs, 35 myth corrections, and a 60-brief guarded plan. Across all seven plans, 477 raw briefs reconcile to 414 unique roadmap URLs. The existing MCP-versus-A2A canonical is upgraded; 0 proposed child pages are published.
The MCP Apps cornerstone publishes a 136-claim register, an App–Host method register, a 11-host support snapshot, a 20-row security threat register, 53 FAQ answers, and 26 paired public data surfaces. Across all eight plans, 543 raw briefs reconcile to 479 unique roadmap URLs. The /mcp-apps/ intent is published as one canonical cornerstone; all 66 supporting proposals remain roadmap-only.
The local-versus-remote cornerstone publishes a 137-claim archive register, a master comparison, a deployment decision framework, a date-stamped host audit, 51 FAQ answers, and 30 paired public data surfaces. Across all nine plans, 613 raw briefs reconcile to 538 unique roadmap URLs; 11 package-10 proposals overlap earlier intents. The deployment-choice canonical is published, while all 70 supporting proposals remain roadmap-only.
The earlier package omitted file_manifest.json; its host-support JSON was deterministically recovered and checksum-verified. In the comparison package, 6 omitted artifacts were recovered byte-for-byte and 5 archive originals remain unavailable. Semantically complete normalized myth and visual datasets are labeled as derivatives rather than presented as checksum matches. The server package manifest and comparison package manifest disclose every alias, recovery, use, correction, and gap.
Research package 4 was supplied as 13 artifacts with no checksums. Methodology, quality-audit, and generation files referenced by its README were absent, so we can validate the received files and normalized outputs but cannot assert byte-for-byte upstream provenance or independently reproduce package generation. Integration does not satisfy the package’s live-check warning: affected and patched versions and other current-state fields still require publication-time review. The security package manifest records every supplied artifact, use, and limitation.
Research package 5 contains 57 flat archive entries: 56 are covered by SHA256SUMS.txt, which correctly excludes itself, and 55 payload files appear in package_manifest.csv, which excludes both bookkeeping files. Every listed size and hash validates, and all paired CSV/JSON datasets agree after normalizing numeric CSV fields. The archive remains unchanged. Current product sources were separately reopened against official first-party documentation on August 25, 2026; normalized records preserve package URLs alongside moved canonicals and explicit editorial corrections. Its architecture package manifest publishes the artifact, citation, product-source review, visual, dataset, and canonical decisions.
Research package 6 contains 69 flat archive entries and 68 checksum-listed payloads; every listed hash matches and every paired JSON/CSV dataset parses. The raw archive remains unchanged. The public layer reconciles aliases, corrects current first-party product URLs and capability scope, labels every host row live-check required, and normalizes one disclosed cross-format tool-result inconsistency conservatively. Its primitive package manifest publishes all artifact, source, correction, visual, dataset, and canonical decisions.
Research package 7 contains 73 flat archive entries: 72 are covered by SHA256SUMS.txt, and 71 payload files appear in package_manifest.csv. Every listed size and hash validates, and the raw archive remains unchanged. Its 87 package sources reconcile to 24 new canonical records. The public normalization preserves the package’s Rust Tier 2 snapshot while using the official Tier 1 assignment checked August 26, 2026, discloses the official pre-launch 2024-10-07 release tag outside the five-principal-revision matrix, and treats the JSON-only Tasks and batching rows as a rework-to-extension and a removal rather than ordinary deprecations. The seven package deprecation rows remain identifiable; the current registry corrects HTTP+SSE’s deprecation revision to 2025-03-26, supplies exact official removal windows, and contributes one clearly labeled supplemental row for the two deprecated Sampling includeContext values. Every current field remains live-check required. The protocol-version package manifest publishes the archive, source, correction, visual, release-scope, lifecycle, dataset, and canonical decisions.
Research package 8 contains 91 flat archive entries: 90 are covered by SHA256SUMS.txt, and 89 payload files appear in package_manifest.csv. Every listed size and hash validates, and the raw archive remains unchanged. Its 74 package sources reconcile to 50 new canonical records, with 1 separately labeled Skills Over MCP editorial supplemental. The public normalization corrects A2A wire-version semantics, the English launch-announcement URL, the official Rust SDK repository, the retired MCP extensions slug, optional server/discover wording, contextId scope, and the difference between local A2A use and MCP’s standardized subprocess binding. Current SDK, vendor-support, governance, roadmap, and latest-release fields remain live-check required. The MCP-versus-A2A package manifest publishes the archive, source map, current-source review, corrections, datasets, visuals, publication decisions, and canonical guards.
Research package 9 contains 95 safe flat archive entries and preserves their archived bytes unchanged. Both internal bookkeeping files list all 95 entries, but their final self/cross-reference sizes and hashes are stale; the other 93 ordinary payloads verify exactly. The data dictionary also understates its own row count and repeats the package-manifest’s stale 93-row count. We therefore do not describe all internal hashes as verified. The public layer corrects the duplicate prompt citation, current Cursor support, current OpenAI UI and Plugins Directory guidance, version-scoped core capability negotiation, the stable-spec lifecycle sample erratum, and VS Code’s current setting label. Its MCP Apps package manifest publishes the archive findings, source map, current-source corrections, datasets, visuals, and canonical guards.
Research package 10 contains 110 safe flat archive entries and preserves their archived bytes unchanged. Its SHA-256 is 57f2442509fd30a070db515a94140e10ae2a8b2e1747c0196063b1c88c276b49; both inventory files intentionally sit outside the 108 ordinary payloads, whose listed sizes and hashes all verify. The 80-source build_context.sources publication catalog and separate 78-source evidence_manifest use incompatible numeric namespaces. We preserve both raw families, expose the secondary manifest as archive-only data, map no article or claim tokens across them, and attach public citations only through an explicit URL-keyed rebuild. The current review corrects Zed support, separates Cursor Cloud Agents from the IDE, documents ChatGPT's tunnel path, follows Cloudflare's current handler guidance, and date-scopes cloud-platform claims. Its local/remote package manifest publishes the archive findings, source policy, current-source corrections, datasets, visuals, and canonical guards.
Research package 11 contains 85 safe flat archive entries: 84 files are SHA-256 verified, while the 83-row payload manifest omits itself. Its 80 source rows reconcile to 52 new canonical records, plus 3 new current-review supplementals for SDK behavior and Docker-specific security boundaries; the publication also reuses the existing official roadmap record. The gateway cornerstone publishes six selected noindex dataset pairs, including the 24-test design-time plan and 25-row threat register. The test plan is not represented as executed, the product audit remains a dated documentation snapshot rather than a ranking, and all 76 proposed child URLs remain merged sections or roadmap-only records. The gateway package manifest discloses the archive, source mapping, dataset selection, and canonical guards.
Independence
MCP Blog is independent and is not an official Model Context Protocol publication. We do not accept payment for favorable technical conclusions. If commercial relationships, sponsorships, or affiliate links are introduced later, they will be disclosed on the affected page and will not determine editorial rankings.