How we decide what is true—and current.

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.

Our source library exposes 285 canonical evidence records. Research package 3 contributes 63 package-local records, reconciled into 29 genuinely new canonical sources; research package 4 contributes 96 package-local security records; and research package 5 contributes 68 architecture records, including 37 new canonical records after exact and documented URL aliases are reconciled. One first-party A2A specification remains an editorial supplemental freeze for its comparison page. A source can be durable, require a live check, or require periodic review. “Official support” is evidence of a vendor’s stated support—not proof of adoption, reliability, popularity, or security.

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.

Technical guides therefore 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.

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

Automation may help organize the evidence set, compare revisions, draft prose, check links, create metadata, or test the website. It does not create facts. Published claims are expected to have a traceable basis in the cited sources, and generated summaries are not accepted as 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

The server cornerstone publishes a normalized 81-claim register, 285-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. Across all four plans, 271 raw briefs reconcile to 226 unique roadmap URLs. Package-local IDs remain alongside canonical site IDs.

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.

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.