TECHNOLOGY EXPLAINER
Model Context Protocol and Agent Interoperability
- A common socket between AI and external tools and data: how to read the specification, its versions and its authorization rules
When an AI application needs to reach a company database, a measuring instrument or a business system, building a dedicated connector for every pairing quickly gets out of hand. The Model Context Protocol (MCP) is an open protocol that standardizes those connections. But the specification changes substantially between versions: the 2026-07-28 revision removes the initial handshake (initialize) and the session, and moves to requests that each carry everything the server needs. This article covers the structure of MCP (host, client, server), the three building blocks a server exposes (tools, resources, prompts), how to read the versions, how MCP relates to other protocols such as A2A, and how authorization and permissions work, within what could be confirmed on the official pages.
- What is MCP? (in three points)
- Why a shared convention is needed
- Structure: host, client, server
- The three server primitives and the client features
- Reading the versions: what changed from 2025-11-25 to 2026-07-28
- Relationship to other protocols: A2A and AGENTS.md
- Authorization and permissions
- How to think about operational risk
- A materials engineer's view: instruments, data and cost
- Limits, and what could not be confirmed
- How to read evaluations and standards
- Glossary
- References (primary sources)
- Claim-to-source audit
Sourced = stated in an official specification, announcement or paper (with a link)
Our calculation = a value this article derived from stated assumptions
Not yet confirmed = drafts, plans or work in progress that are not final
Interpretation is marked as commentary. Inference appears in bold.
This field moves fast, and MCP revisions contain backward-incompatible changes. This article reads the 2026-07-28 revision of the specification. As of the confirmation date (15 October 2026), the official versioning page lists this revision as Current Sourced [Ref. 5]. A newer revision may have appeared since. Before adopting or implementing anything, check the latest revision on the official specification site. The values and requirements below do not guarantee how any particular implementation behaves.
1. What is MCP? (in three points)
The Model Context Protocol (MCP) is an open protocol that connects AI applications to external data and tools. The specification uses JSON-RPC 2.0 messages and defines three parties: a host (the AI application), clients (connectors inside the host) and servers (the side that provides capabilities) Sourced [Ref. 1].
- What it does: a server exposes "tools" the AI can call, "resources" (data to hand to the AI) and "prompts" (templates a person picks) in a common form, so that a client can discover and use them Sourced [Ref. 9].
- Who made it: Anthropic open-sourced it on 25 November 2024 Sourced [Ref. 20]. On 9 December 2025 the Linux Foundation announced the Agentic AI Foundation (AAIF), with MCP as one of its founding contributed projects (alongside Block's goose and OpenAI's AGENTS.md) Sourced [Ref. 21].
- How it is governed: the specification is versioned with "YYYY-MM-DD" revisions, and the current revision as of the confirmation date is 2026-07-28 Sourced [Ref. 5]. The project operates as "Model Context Protocol a Series of LF Projects, LLC", and its governance document describes a hierarchy of maintainers in which membership belongs to individuals rather than to companies Sourced [Ref. 18].
MCP is an agreement about communication. It is not a model, not an agent, and not a mechanism that guarantees the correctness or safety of data. What to expose, whom to allow what, and how to verify results are decided by the design and operation of the servers and hosts. The specification itself says that the protocol cannot enforce its security principles Sourced [Ref. 1].
2. Why a shared convention is needed
For an AI application to use a database, files or a business system, something has to tell the AI what operations exist, what arguments they take and what comes back, and something has to execute the calls. As applications and targets both multiply, the number of connectors grows with every pairing. When Anthropic released MCP it explained that a separate implementation for every data source makes connected systems hard to scale, and presented a shared convention as the remedy Sourced [Ref. 20].
Expressed as a formula: with N AI applications and M external systems, connecting each pair separately takes N x M connectors, while going through a shared protocol takes N on the application side plus M on the server side, or N + M Our calculation. For 5 applications and 8 systems that is 40 versus 13; for 10 and 20 it is 200 versus 30.
This simply counts connectors. Even with MCP, each system still needs server design: how finely to cut tools, how to separate permissions, and how to convey units and conditions of data. Not every pair of application and system is used in practice. The figures are neither an effort estimate nor a comparison of products (commentary).
3. Structure: host, client, server
View original SVG, values and source annotations
The official specification divides the roles as follows Sourced [Ref. 6].
| Role | What it does (as the specification describes it) | Note for readers |
|---|---|---|
| Host | The AI application itself. It creates clients, manages connection permissions and lifecycle, enforces security policy and user consent, coordinates AI/LLM integration, and aggregates context across clients | The host holds the whole conversation. Servers are designed so that they cannot read all of it |
| Client | A connector created by the host that talks to exactly one server. In revision 2026-07-28 it attaches the protocol version and its capabilities to every request | A component inside the host product; not necessarily a screen the user touches |
| Server | Exposes resources, tools and prompts. It can be a local process or a remote service | Whether a server is "safe" is not determined by the protocol (Chapter 8) |
All Sourced (architecture chapter [Ref. 6]).
There are two standard transports. stdio exchanges newline-delimited messages over the standard streams of a subprocess the client launches. Streamable HTTP sends each message as an HTTP POST to a single MCP endpoint, and replies come back as a JSON object or as a request-scoped SSE (server-sent events) stream Sourced [Ref. 7]. The older "HTTP+SSE" transport is classified as deprecated Sourced [Ref. 3]. A Streamable HTTP server must validate the Origin header to guard against DNS rebinding (MUST), and when run locally it should bind only to localhost (127.0.0.1) rather than all interfaces (0.0.0.0) (SHOULD) Sourced [Ref. 16].
Revision 2026-07-28 states that MCP is stateless. A server must not infer capabilities, protocol version or client identity from earlier requests on the same connection; state that spans several requests is carried by an explicit identifier (a handle) that the server mints and the client passes back on each request Sourced [Ref. 7]. This makes it easier to run several server instances side by side (commentary; the official explanation of the multi round-trip pattern says it avoids a shared storage layer and stateful load balancing) [Ref. 8].
4. The three server primitives and the client features
The specification organizes the three server primitives by "who decides when each is used" Sourced [Ref. 9].
| Primitive | Controlled by | What it is | What the specification asks for |
|---|---|---|---|
| Tools | The model | Functions the model can call. Each has a name, a description, an input JSON Schema (inputSchema), optionally an output schema, and annotations [Ref. 10] | A human should always be able to deny invocations (SHOULD). Annotations must be treated as untrusted unless they come from a trusted server (MUST) |
| Resources | The application | Context data such as files or database schemas, identified by URI (RFC 3986) [Ref. 11] | The host decides how to attach them. Hosts must not transmit resource data elsewhere without user consent (a host principle) [Ref. 1] |
| Prompts | The user | Instruction or workflow templates a server publishes, chosen by the user like slash commands [Ref. 32] | "User-controlled" describes who picks the moment of use; it does not mean the content, which the server defines, can be trusted |
All Sourced (server-features chapter [Refs. 9, 10, 11, 32]). The last sentence of the right-hand column is commentary.
What the specification fixes about tool definitions
- Schema dialect: JSON Schema 2020-12 is the default dialect and implementations must support at least that. Revision 2026-07-28 loosens inputSchema and outputSchema to allow any 2020-12 keywords Sourced [Refs. 2, 7].
- The list does not vary per connection: the tools/list result must not vary per connection or as a side effect of other requests. It may, however, vary with the authorization presented on the request, such as the scopes granted Sourced [Ref. 10].
- Order and caching: servers should return tools in a deterministic order when the underlying set is unchanged, and results carry a freshness hint (ttlMs) and a cache scope (cacheScope). The specification says a stable order helps client-side caching and LLM prompt-cache hit rates Sourced [Refs. 2, 10].
- Server-side safety requirements (MUST): validate all inputs, implement access controls, rate-limit invocations, sanitize outputs. Client-side (SHOULD): confirm sensitive operations with the user, show inputs to the user before calling (to avoid accidental or malicious exfiltration), validate results before passing them to the LLM, apply timeouts, and log tool usage for audit Sourced [Ref. 10].
Client features and extensions
The remaining client-side feature is elicitation, in which a server asks the user for more input. It has two modes, form and URL, and the specification says secrets such as passwords, API keys, access tokens and payment credentials must not be requested through a form (MUST NOT) and must use URL mode Sourced [Ref. 15]. Roots, sampling and logging were deprecated in revision 2026-07-28 (Chapter 5).
Beyond the core there is an optional mechanism called extensions. Extensions are always opt-in and work only when both sides declare support. The specification names three notable ones: Tasks for long-running operations, Skills over MCP for discovering and consuming agent workflows, and MCP Apps for interactive UI elements rendered inline in a conversation Sourced [Ref. 1]. With Tasks, a server returns a durable task handle instead of a result; the client checks status (working, input_required, completed, failed, cancelled) with tasks/get and can collect the result even after reconnecting Sourced [Ref. 19].
5. Reading the versions: what changed from 2025-11-25 to 2026-07-28
A revision is named "YYYY-MM-DD" and denotes the last date on which backward-incompatible changes were made; changes that keep compatibility do not bump the version. A revision can be Draft, Current or Final Sourced [Ref. 5]. The official site has specification pages for revisions 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28 Sourced [Refs. 1, 5; the site's page index].
Among the changes in revision 2026-07-28, the "major changes" that most affect implementers are the following Sourced [Ref. 2].
| Change | Content | Implication for implementation and operation (commentary) |
|---|---|---|
| No session or handshake | Protocol-level sessions and Mcp-Session-Id are removed, and so is the initialize / initialized exchange. Every request carries the protocol version (protocolVersion) and capabilities (clientCapabilities) in _meta. A version mismatch returns UnsupportedProtocolVersionError | Easier to run several server instances. Conversely, a legacy client cannot talk to a new-only server (an implementation speaking both eras is needed) |
| server/discover added | Servers must implement server/discover, which returns supported versions, capabilities and identity (MUST). Clients may call it first, but are not required to | Useful for checking features before connecting and for telling old from new on stdio |
| New subscription model | The HTTP GET endpoint and resources/subscribe are replaced by subscriptions/listen, one long-lived response stream. ping and logging/setLevel are removed | How change notifications are received must be reimplemented |
| MRTR introduced | When a server needs user input or the like, it returns input_required, and the client retries the original request with inputResponses | Server-initiated requests can no longer be used (a breaking change) |
| Tasks moved to an extension | The experimental tasks feature leaves the core and becomes an extension (io.modelcontextprotocol/tasks). Status is polled with tasks/get instead of the blocking tasks/result | Long-running work is available only with implementations that support the extension |
| resultType on results | Every result carries a required resultType (complete or input_required). Results from older servers that omit it are treated as complete | Build clients so that results from older servers can still be read |
| SSE resumability removed | Resumption and redelivery with Last-Event-ID are removed. A broken stream loses the in-flight request, and the client re-issues it as a new request | Retried operations must not double their side effects (idempotency). Inference: avoiding duplicate execution on retry becomes a server-side design problem |
The "Content" column is Sourced (key changes [Ref. 2], MRTR [Ref. 8]). The right-hand column is commentary.
Deprecated features and the earliest possible removal
The project manages feature states as Active, Deprecated and Removed. Deprecated features stay in the specification for at least twelve months (at least ninety days under an expedited exception) Sourced [Ref. 5]. Revision 2026-07-28 lists these as Deprecated Sourced [Ref. 3].
| Feature | Migration path (as stated officially) | Earliest point at which removal becomes possible |
|---|---|---|
| Roots | Pass directories or files via tool parameters, resource URIs or server configuration | The first revision released on or after 2027-07-28 |
| Sampling | Integrate directly with LLM provider APIs | Same as above |
| Logging | Log to stderr for stdio; use OpenTelemetry for observability | Same as above |
| Dynamic Client Registration (DCR, RFC 7591) | Client ID Metadata Documents (CIMD) | Same as above |
| HTTP+SSE transport | Streamable HTTP | Three months after SEP-2596 reaches Final |
All Sourced (deprecated-features registry [Ref. 3]). The "earliest point" is when a feature becomes eligible for removal; the registry states that actual removal may come later.
In the official compatibility matrix, a legacy-only client cannot connect to a modern-only server, and a modern-only client cannot talk to a legacy-only server either. Only implementations that speak both eras (dual-era) work with both Sourced [Ref. 4]. Before adoption, check which revisions the client product and the server support, using each product's official documentation. This article did not check the support status of individual products (Chapter 10).
6. Relationship to other protocols: A2A and AGENTS.md
The Agent2Agent (A2A) protocol is an open protocol for independent agents to discover each other's capabilities, delegate tasks and exchange information. The A2A documentation describes MCP as connecting an agent to tools and resources and A2A as connecting an agent to other agents, and calls the two complementary rather than competing Sourced [Refs. 22, 23].
| Aspect | MCP | A2A |
|---|---|---|
| What it connects | An agent (its host) and servers that expose tools, data and prompts | Independent agents that do not expose their internals to each other |
| Discovery | server/discover and listings such as tools/list | The Agent Card (a JSON document describing identity, capabilities, skills, endpoint and authentication requirements) |
| Long-running work | The Tasks extension | Tasks, streaming and push notifications are central to the specification |
| Version and state | 2026-07-28 is current (as of the confirmation date). Stateless | The specification page shows the latest released version as 1.0.0, and the GitHub releases include v1.0.1 (2026-05-26). Requests carry A2A-Version |
| Stewardship | A Series of LF Projects; its contribution to the AAIF was announced on 2025-12-09 | Developed by Google and donated to the Linux Foundation. The A2A blog says it was accepted as a Growth Stage project at the AAIF on 27 August 2026 |
All Sourced (MCP: Refs. 1, 5, 18, 21; A2A: Refs. 22-25). Adoption figures such as "backed by over 150 organizations" come from the A2A blog and were not independently verified here.
AGENTS.md is a different kind of thing. It is a Markdown convention, released by OpenAI in August 2025, for giving coding agents project-specific guidance; it is not a communication protocol like MCP or A2A. It is, with MCP and goose, one of the AAIF's founding contributed projects Sourced [Ref. 21]. The function-calling mechanisms that model vendors provide in their own APIs are outside the scope of this article. An MCP tool is described, like those, by a name, a description and an input type, so the practical split is that the client translates it into whatever form the model side expects (commentary).
The official documents of both MCP and A2A call themselves open standards, but neither is a standard of an international standards body such as ISO/IEC or IEEE. They are open-source specifications run under LF Projects and similar bodies. "Industry standard" can be a claim by the developer or related parties; for example, an Anthropic executive said in the Linux Foundation announcement that MCP has become the industry standard [Ref. 21], which is the developer's own wording. This investigation could not confirm that MCP or A2A has been issued as an ISO/IEC or IEEE standard.
7. Authorization and permissions
Authorization in MCP is OPTIONAL. Implementations that use authorization over HTTP-based transports should follow the specification (SHOULD), whereas stdio implementations should not follow it and should instead retrieve credentials from the environment (SHOULD NOT) Sourced [Ref. 12]. The mechanism builds on OAuth 2.1. The MCP server is an OAuth 2.1 resource server, the MCP client is an OAuth 2.1 client, and the authorization server issues the tokens; the authorization server may be hosted with the MCP server or be a separate party Sourced [Ref. 12].
| Requirement | Content (summary of the specification) | Level in the specification |
|---|---|---|
| Discovering the authorization server | The MCP server implements OAuth 2.0 Protected Resource Metadata (RFC 9728), and the client uses it to find the authorization server. The authorization server publishes its metadata through either RFC 8414 or OpenID Connect Discovery | MUST (servers and clients) |
| Client registration | Client ID Metadata Documents (CIMD) are preferred. Pre-registration is also possible. Dynamic Client Registration (RFC 7591) is deprecated and kept for compatibility with authorization servers that lack CIMD | CIMD: SHOULD; DCR: MAY (deprecated) |
| PKCE | To prevent authorization-code interception, use the S256 method, and do not proceed if the authorization server's metadata does not show support | MUST |
| The resource parameter | Following RFC 8707, include the canonical URI of the target MCP server in both the authorization request and the token request, even if the authorization server does not support it | MUST |
| Audience validation | An MCP server accepts only tokens issued for itself, and neither accepts nor passes on any other tokens | MUST / MUST NOT |
| Sending the token | Put it in the Authorization: Bearer header on every HTTP request. Never put it in the URI query string | MUST / MUST NOT |
| Validating the issuer (iss) | Authorization servers should include iss in authorization responses. A client compares a present iss with the recorded issuer before using the code (RFC 9207) | Server: SHOULD; client: MUST |
| Scope (the range of permission) | Servers should state the required scope in WWW-Authenticate. Clients request the minimum and ask for additional consent (step-up) when more is needed | SHOULD |
| Token lifetime | Authorization servers should issue short-lived access tokens. For public clients, refresh tokens must be rotated | SHOULD / MUST |
| Redirect URIs | localhost or HTTPS only. The authorization server validates an exact match against registered values | MUST |
All Sourced (authorization and authorization-security chapters [Refs. 12, 13]). The table is a summary, not the full text. OAuth 2.1 is itself an IETF draft: a newer revision than the one the MCP specification cites (draft-ietf-oauth-v2-1-13) exists (revision 16 as of the confirmation date), and it is not yet an RFC [Ref. 33].
The specification's idea of "permissions" can be split into three layers (our organization of it).
- Permission to connect (who can reach the server): OAuth authorization and scopes. With stdio it is decided by operating-system permissions and environment variables.
- Per-tool permission (what can be executed): a server may vary the content of tools/list according to the granted scopes Sourced [Ref. 10]. How fine-grained permissions are depends on server design.
- Human involvement (who approves in the end): the specification recommends that a human can deny tool invocations, and asks hosts to obtain explicit user consent Sourced [Refs. 1, 10]. However, how consent is collected (the screen) is not specified and differs between implementations.
The MUST and SHOULD levels in the table are what the specification asks of implementations. Whether a given client or server actually complies has to be checked product by product. The specification itself says the protocol cannot enforce security principles and that implementors should build robust consent and authorization flows Sourced [Ref. 1].
8. How to think about operational risk
The official security best-practices page names the problems that tend to arise in MCP implementations [Ref. 14]. Here, without going into attack procedures, we list only the name of each problem and the direction of the countermeasures the official page gives.
| Name of the problem | What the problem is (summary) | Direction of the official countermeasure |
|---|---|---|
| Confused deputy | When an MCP proxy server connects to a third-party API, some configurations let authorization proceed while skipping the user's consent | Obtain consent per client, validate redirect URIs strictly, and so on |
| Token passthrough | A server accepts tokens not issued for it and hands them straight to a downstream API, which makes audit trails and downstream controls hard to maintain | Never accept tokens not explicitly issued for the server (MUST NOT) |
| SSRF (server-side request forgery) | During authorization discovery, URLs a client fetches can be steered by a malicious server toward unintended destinations such as internal networks | Enforce HTTPS, restrict destinations and apply other measures suited to the network environment (MUST consider) |
| State handle hijacking | Revision 2026-07-28 keeps cross-request state in identifiers (handles) minted by the server. If one is obtained or guessed, another user's state could be operated on | Never treat possession of a handle as authentication (MUST NOT). Make handles hard to guess, bind them to the authenticated user and verify |
| Local MCP server compromise | A server on a user's machine sits close to local files and privileges. A configuration could carry a malicious startup command | For one-click installs, show the exact command without truncation and obtain explicit consent (MUST). Run servers sandboxed with minimal privileges |
| Over-broad scope requests | Requesting broad permissions up front increases the damage if a token leaks and makes consent screens go unread | Start from a minimal scope and escalate when needed |
All Sourced (security best practices [Ref. 14], authorization security [Ref. 13]). The wording is this article's summary.
These problems mostly concern communication and authorization. There is another problem that is not specific to MCP but tends to appear through MCP servers. Tool descriptions and the text tools return become input to the AI, so instructions hidden in them can be followed by the AI (prompt injection). The specification requires that tool annotations be treated as untrusted unless they come from a trusted server (MUST) Sourced [Ref. 10]. The OWASP Top 10 for Agentic Applications (2026 edition) lists the tampering of MCP tool descriptors and schemas as an example under tool misuse and exploitation (ASI02) [Ref. 26]. Evaluation and safety are covered in more depth in our explainer on evaluating and securing AI agents.
9. A materials engineer's view: instruments, data and cost
An MCP server can also be the doorway through which an AI sees instrument data, an electronic lab notebook (ELN) or manufacturing records. In materials R&D and on the factory floor, settling the following points first reduces rework later (this is commentary by this article, not something the MCP specification requires).
- Start read-only: keep reading measurements and records separate from writes that change instrument conditions, in both servers and scopes. The mechanism the specification allows, varying tools/list with the granted scopes [Ref. 10], can serve this separation.
- Never return a bare number: results given to the AI should carry units, measurement conditions, sample ID, time and the instrument's calibration state. A bare number cannot reveal a later mix-up of conditions, for the same reason that in materials evaluation a number without its conditions cannot be compared.
- Manage tool descriptions as input too: a description is text the AI reads, so descriptions from third-party servers are to be treated as untrusted, as the specification says [Ref. 10]. For servers built in-house, make description changes subject to review.
- Record for reproducibility: log which protocol revision, which server and tool versions and which arguments were used. The specification recommends that clients keep usage logs for audit [Ref. 10].
- Treat physical actions as a special case: operations tied directly to safety, such as heating, charging, gases or pressure, are best placed behind the existing control system's safety mechanisms and a human approval, rather than exposed as tools the AI calls directly. This article did not check conformance to any particular safety standard.
In MCP, the names, descriptions and input types of the available tools are passed to the model. The official client guidance says that when a host connects to dozens of servers and hundreds of tools, the tool definitions alone can consume most of the context window, and it recommends "progressive tool discovery", loading definitions only when needed. As an example it suggests switching once tool definitions exceed roughly 1% to 5% of the context window Sourced [Ref. 17].
The specification also says that returning tools in a fixed order and attaching a freshness hint (ttlMs) can raise client-side cache and LLM prompt-cache hit rates [Refs. 2, 10]. That longer context increases compute and memory (the KV cache) at inference time is covered in our explainers on retrieval-augmented generation and context windows and on inference optimization and serving. So how many tools you connect, and with what descriptions, is a design item that indirectly affects the compute and power of AI data centers (commentary; actual token counts and costs depend on the model and the client implementation and are not given here).
10. Limits, and what could not be confirmed
(1) Support in individual products
We did not check which revisions particular client products or servers (including SDKs) support, or how well they follow the specification's requirements. We do not rank products.
(2) The full text of the specification
This article selects and summarizes the main requirements. It does not cover the full specification (schemas, error handling, pagination, cancellation, progress and so on). For the places it does cover, the MUST / SHOULD levels were transcribed from the official wording.
(3) Status as an international standard
We could not confirm that MCP or A2A has been issued as an ISO/IEC or IEEE standard. Both are open specifications run under LF Projects / the Linux Foundation.
(4) Scale of adoption
Figures such as the number of organizations using MCP or A2A, or the number of servers, appear in announcements by the developers and related bodies, but we could not verify them from independent primary sources, so this article does not use them.
(5) Currency of versions
A newer revision may have appeared after the confirmation date (15 October 2026). Of the authorization-related documents referenced here, OAuth 2.1 and CIMD are IETF drafts, and newer revisions than those the specification cites now exist [Refs. 33, 37].
(6) Security
We do not cover actual vulnerabilities or attack cases, or safety assessments of individual tools and servers. No attack procedures are given.
- MCP is an open communication convention between AI applications and external tools and data. In its host-client-server structure, a server exposes tools, resources and prompts Sourced
- Always check the revision. The current one on the confirmation date is 2026-07-28, which dropped the handshake and the session and moved to self-contained requests. Roots, sampling and logging are deprecated Sourced
- A2A has a different role. MCP links an agent to tools; A2A links agents to each other. Neither is a standard of an international standards body Sourced
- Authorization is optional, but when used it builds on OAuth 2.1 and calls for PKCE, the resource parameter, audience validation and least privilege. What the specification requires and what an implementation does are different things Sourced
- Tool descriptions are also input to the AI. The basics are to distrust them unless they come from a trusted server, to keep a human able to refuse, and to keep records Sourced
11. How to read evaluations and standards
The "performance" and "safety" of MCP are evaluated in three layers: (1) whether the protocol works as specified (conformance), (2) whether an AI can use the tools correctly (tool-use competence), and (3) whether the AI refuses to follow instructions hidden in tool descriptions or results (resilience). Layer 1 relies on the specification and inspection tools; layers 2 and 3 rely mostly on benchmarks from academic papers. In none of the layers could we confirm, as of the confirmation date (15 October 2026), a standard from an international standards body (ISO/IEC, IEEE) that targets MCP itself. Instead, authorization draws on IETF RFCs, the framing of safety on OWASP and NIST guidance, and organizational management on the ISO/IEC AI standards.
| What is evaluated | Representative benchmarks and methods (name, source) | Standards and guidance (ISO/IEC, IEEE, NIST, IETF, OWASP, etc.) | Notes on reading |
|---|---|---|---|
| Protocol conformance Sourced | MCP Inspector (the official developer and debugging tool, with web, CLI and TUI clients) [Ref. 44]. An official repository, modelcontextprotocol/conformance ("Conformance Tests for MCP"), exists [Ref. 43]; we could not confirm the test contents or which revisions and features they cover | MCP specification 2026-07-28 (an open specification under LF Projects) [Ref. 1]. No ISO/IEC or IEEE standard could be confirmed | Passing a check is not the same as being safe. Check which revision and which features the check covers |
| Tool-use competence Sourced | MCP-Atlas (arXiv 2602.00933): 1,000 expert-written tasks over 36 real servers and 220 tools, claim-level scoring, split into 500 public and 500 private [Ref. 39]. MCPMark (arXiv 2509.24002): 127 tasks including create, read, update and delete operations, reported as pass@1 and pass^4 [Ref. 40]. MCP-Universe (arXiv 2508.14704): 6 domains and 11 servers, execution-based scoring [Ref. 49] | No applicable ISO/IEC, IEEE or NIST standard could be confirmed | Results are for the models and settings at the time of each paper. The evaluator is the paper's authors, not necessarily an independent third party. Results do not reproduce when server versions change. We do not rank and give no scores |
| Resilience to tool descriptions and results Sourced | MCPTox (arXiv 2508.14925): 45 real servers, 353 tools and 1,348 test cases [Ref. 41]. AgentDojo (arXiv 2406.13352): 97 tasks and 629 security test cases [Ref. 42]. Section 3.6 of NIST AI 100-2e2025 gives AgentDojo and others as examples of evaluation resources [Ref. 50] | OWASP Top 10 for Agentic Applications for 2026 (ASI01 to ASI10, December 2025) [Ref. 26]. OWASP Top 10 for LLM Applications 2026 (published August 2026): LLM01:2026 "Prompt Injection" and LLM03:2026 "Excessive Agency" [Ref. 27]; in the 2025 edition, Excessive Agency was LLM06:2025 [Ref. 28]. NIST AI 100-2e2025, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations" (March 2025) [Ref. 50] | OWASP and NIST documents are guidance with no legal force. Attack success rates change with how the attack is built, whether defenses exist, and the model; numbers under different settings must not be lined up to rank anything |
| Authorization and authentication SourcedNot yet confirmed | No MCP-specific certification scheme or official benchmark for authorization could be confirmed | RFC 9728 (April 2025), RFC 8707 (February 2020), RFC 7636 (September 2015), RFC 8414 (June 2018), RFC 9207 (March 2022) [Refs. 34-36, 38, 51]. OAuth 2.1 (IETF draft, revision 16) and CIMD (IETF draft, revision 02) are still in development [Refs. 33, 37]. NIST NCCoE concept paper "Accelerating the Adoption of Software and AI Agent Identity and Authorization" (DRAFT, February 2026; comments 2026-02-05 to 04-02) [Ref. 31] | Which parts of the RFCs are mandatory is decided by the MCP specification. Drafts and concept papers can change, so check the revision and date |
| Organizational management and risk management SourcedNot yet confirmed | No MCP-specific evaluation method could be confirmed | ISO/IEC 42001:2023 "Information technology — Artificial intelligence — Management system" (Edition 1, 2023-12) [Ref. 45]. ISO/IEC 23894:2023 "Guidance on risk management" (Edition 1, 2023-02) [Ref. 46]. NIST AI RMF 1.0 (NIST AI 100-1, January 2023) [Ref. 47]. NIST AI 600-1, Generative AI Profile (July 2024) [Ref. 48]. NIST's AI Agent Standards Initiative (page created 2026-02-17, updated 2026-08-14) and the CAISI request for information (Federal Register, 2026-01-08; responses due 2026-03-09) are ongoing efforts [Refs. 29, 30]. NIST's site now names this evaluation unit the Center for Advancing Innovation and Standards for Super Intelligence (CAISSI) as of the confirmation date; the name at the time those documents were written was CAISI (Center for AI Standards and Innovation) [Ref. 52]. The background is Executive Order 14434 (signed 29 September 2026), which directs the executive branch to use "Super Intelligence" in place of "AI" in non-statutory documents [Ref. 53]; document titles are kept in their original form | ISO/IEC 42001 sets requirements for a management system; 23894 is guidance. Both texts are paid, so only titles and scope were checked. They are distinct from law (binding rules). NIST's efforts are standards in the making |
The arrangement of the table is Our calculation (editing by this article). The standards' texts were not checked, so no requirements are described.
Notes on reading
- Benchmark numbers change with settings and evaluator. Even under the same benchmark name, results differ with the agent framework, tool versions, server state and reasoning length. Numbers produced by a paper's authors or by the developer are not independent third-party numbers. This article does not rank anything and gives no specific scores.
- Watch for saturation and contamination. Published tasks can leak into training data and be memorized. MCP-Atlas keeps part of its evaluation private, which it describes as a way to preserve leaderboard integrity Sourced [Ref. 39]. Tasks that depend on external servers or on dates can also change their correct answers over time.
- "Level in a specification" is not "legal force". MUST and SHOULD in the MCP specification are the levels the MCP project asks of implementations. OWASP and NIST guidance is recommendation, ISO/IEC 42001 contains requirements an organization can be certified against, and RFCs are IETF technical standards. None of these is itself law (regulation is covered in our explainer on the EU AI Act and others).
- Declared versus measured. What a specification says is possible differs from what an implementation actually does; the latter is established through conformance checks and operational records.
12. Glossary
- MCP (Model Context Protocol)
- An open protocol connecting AI applications to external tools and data. Uses JSON-RPC 2.0.
- Host / client / server
- The AI application itself / a connector inside the host (one per server) / the side that exposes capabilities.
- Tools / resources / prompts
- The three server primitives, controlled by the model / the application / the user.
- stdio / Streamable HTTP
- The two standard transports: a subprocess's standard streams / a single HTTP endpoint.
- Elicitation
- A server asking the user for more input. Secrets go through URL mode.
- MRTR
- Multi round-trip requests: when more input is needed, return input_required and retry with the input attached.
- server/discover
- The mandatory call that returns a server's supported versions, capabilities and identity.
- Extensions
- Optional features outside the core, such as Tasks and MCP Apps. Used only when both sides declare them.
- A2A
- The Agent2Agent protocol, an open protocol for cooperation between independent agents.
- AAIF
- Agentic AI Foundation, under the Linux Foundation, which took in MCP and other projects.
- OAuth 2.1
- A framework for delegated authorization. An IETF draft and the basis of MCP authorization.
- PKCE
- A mechanism that prevents authorization-code interception (RFC 7636).
- CIMD / DCR
- Ways to obtain a client ID: metadata-document based / dynamic registration (deprecated).
- Scope / audience
- The range of permission a token grants / the party a token is meant for.
- Prompt injection
- A problem in which an AI follows instructions hidden in its input.
- SEP
- Specification Enhancement Proposal, the document form for MCP specification changes.
13. References (primary sources)
- MCP project "Specification (Version 2026-07-28)" — modelcontextprotocol.io/specification/2026-07-28
- MCP project "Key Changes" (list of changes in revision 2026-07-28) — modelcontextprotocol.io/specification/2026-07-28/changelog
- MCP project "Deprecated Features" — modelcontextprotocol.io/specification/2026-07-28/deprecated
- MCP project "Versioning and Compatibility" (specification) — modelcontextprotocol.io/specification/2026-07-28/basic/versioning
- MCP project "Versioning" (documentation) — modelcontextprotocol.io/docs/2026-07-28/learn/versioning
- MCP project "Architecture" — modelcontextprotocol.io/specification/2026-07-28/architecture
- MCP project "Base Protocol Overview" — modelcontextprotocol.io/specification/2026-07-28/basic
- MCP project "Multi Round-Trip Requests" — modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr
- MCP project "Server Features Overview" — modelcontextprotocol.io/specification/2026-07-28/server
- MCP project "Tools" — modelcontextprotocol.io/specification/2026-07-28/server/tools
- MCP project "Resources" — modelcontextprotocol.io/specification/2026-07-28/server/resources
- MCP project "Authorization" — modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- MCP project "Authorization Security Considerations" — modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
- MCP project "Security Best Practices" — modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices
- MCP project "Elicitation" — modelcontextprotocol.io/specification/2026-07-28/client/elicitation
- MCP project "Streamable HTTP" — modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
- MCP project "Client Best Practices" — modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices
- MCP project "Governance and Stewardship" — modelcontextprotocol.io/community/governance
- MCP project "Tasks" (extension) — modelcontextprotocol.io/extensions/tasks/overview
- Anthropic "Introducing the Model Context Protocol" (25 November 2024) — anthropic.com/news/model-context-protocol
- Linux Foundation "Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)" (9 December 2025) — linuxfoundation.org/press
- A2A project "Agent2Agent (A2A) Protocol Specification" — a2a-protocol.org/latest/specification/
- A2A project "A2A and MCP: Detailed Comparison" — a2a-protocol.org/latest/topics/a2a-and-mcp/
- A2A project "A New Chapter for A2A: Joining the Agentic AI Foundation" (27 August 2026) — a2a-protocol.org/latest/blog/2026/08/27/…
- A2A project GitHub "Release v1.0.1" (2026-05-26) — github.com/a2aproject/A2A/releases/tag/v1.0.1
- OWASP GenAI Security Project "OWASP Top 10 for Agentic Applications for 2026" (9 December 2025) — genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- OWASP GenAI Security Project "OWASP Top 10 for LLM Applications 2026" (resource page 3 August 2026; document Version 2026) — genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
- OWASP GenAI Security Project "LLM06:2025 Excessive Agency" (2025 edition) — genai.owasp.org/llmrisk/llm062025-excessive-agency/
- NIST "AI Agent Standards Initiative" — nist.gov/artificial-intelligence/ai-agent-standards-initiative
- NIST CAISI "Request for Information Regarding Security Considerations for Artificial Intelligence Agents", Federal Register 91(5), 8 January 2026 — govinfo.gov/content/pkg/FR-2026-01-08/html/2026-00206.htm
- NIST NCCoE "Accelerating the Adoption of Software and AI Agent Identity and Authorization" (concept paper, DRAFT, February 2026) — nccoe.nist.gov/…/concept-paper.pdf
- MCP project "Prompts" — modelcontextprotocol.io/specification/2026-07-28/server/prompts
- IETF "The OAuth 2.1 Authorization Framework" (Internet-Draft draft-ietf-oauth-v2-1) — datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
- IETF RFC 9728 "OAuth 2.0 Protected Resource Metadata" (April 2025) — rfc-editor.org/rfc/rfc9728
- IETF RFC 8707 "Resource Indicators for OAuth 2.0" (February 2020) — rfc-editor.org/rfc/rfc8707
- IETF RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients" (September 2015) — rfc-editor.org/rfc/rfc7636
- IETF "OAuth Client ID Metadata Document" (Internet-Draft draft-ietf-oauth-client-id-metadata-document) — datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/
- IETF RFC 9207 "OAuth 2.0 Authorization Server Issuer Identification" (March 2022) — rfc-editor.org/rfc/rfc9207
- Bandi C. et al. "MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers", arXiv:2602.00933 — arxiv.org/abs/2602.00933
- Wu Z. et al. "MCPMark: A Benchmark for Stress-Testing Realistic and Comprehensive MCP Use", arXiv:2509.24002 — arxiv.org/abs/2509.24002
- Wang Z. et al. "MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers", arXiv:2508.14925 — arxiv.org/abs/2508.14925
- Debenedetti E. et al. "AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents", arXiv:2406.13352 — arxiv.org/abs/2406.13352
- MCP project GitHub "modelcontextprotocol/conformance" (Conformance Tests for MCP) — github.com/modelcontextprotocol/conformance
- MCP project "MCP Inspector" — modelcontextprotocol.io/docs/2026-07-28/tools/inspector
- ISO/IEC "ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system" (ISO standard page) — iso.org/standard/42001
- ISO/IEC "ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management" (ISO standard page) — iso.org/standard/77304.html
- NIST "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", NIST AI 100-1 (January 2023) — doi.org/10.6028/NIST.AI.100-1
- NIST "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", NIST AI 600-1 (July 2024) — doi.org/10.6028/NIST.AI.600-1
- Luo Z. et al. "MCP-Universe: Benchmarking Large Language Models with Real-World Model Context Protocol Servers", arXiv:2508.14704 — arxiv.org/abs/2508.14704
- NIST "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", NIST AI 100-2e2025 (March 2025) — doi.org/10.6028/NIST.AI.100-2e2025
- IETF RFC 8414 "OAuth 2.0 Authorization Server Metadata" (June 2018) — rfc-editor.org/rfc/rfc8414
- NIST "Center for Advancing Innovation and Standards for Super Intelligence (CAISSI)" (NIST page, confirmed 15 October 2026) — nist.gov/caissi
- The White House Executive Order 14434 "Inaugurating the Era of Super Intelligence", Federal Register 91(190) (signed 29 September 2026; published 2 October 2026) — federalregister.gov/documents/2026/10/02/2026-20321/…
14. Claim-to-source audit
| Claim in the text | Basis | Category |
|---|---|---|
| Definition of MCP (JSON-RPC 2.0; host, client, server; resources, prompts, tools; Tasks, Skills over MCP and MCP Apps as extensions), statelessness, the user-consent and tool-safety principles, the statement that the protocol cannot enforce security, and the current revision 2026-07-28 | MCP specification (2026-07-28) and versioning page Reference 1 https://modelcontextprotocol.io/specification/2026-07-28 Reference 5 https://modelcontextprotocol.io/docs/2026-07-28/learn/versioning | Sourced |
| Major changes in revision 2026-07-28 (no sessions or handshake, server/discover, subscriptions/listen, MRTR, Tasks as an extension, resultType, removal of SSE resumability) and minor changes (ttlMs and cacheScope, deterministic order, iss validation, DCR to CIMD) | Key Changes Reference 2 https://modelcontextprotocol.io/specification/2026-07-28/changelog | Sourced |
| Deprecated features (roots, sampling, logging, DCR, HTTP+SSE), the earliest possible removal, and the deprecation policy (twelve months or more, ninety days in an expedited exception) | Deprecated-features registry and versioning page Reference 3 https://modelcontextprotocol.io/specification/2026-07-28/deprecated Reference 5 https://modelcontextprotocol.io/docs/2026-07-28/learn/versioning | Sourced |
| Versions and compatibility (a version on every request, UnsupportedProtocolVersionError, dual-era, the compatibility matrix) | Versioning and Compatibility Reference 4 https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning | Sourced |
| Roles of host, client and server; design principles; capability declaration | Architecture Reference 6 https://modelcontextprotocol.io/specification/2026-07-28/architecture | Sourced |
| The statelessness rule, resultType, required _meta fields, treatment of JSON Schema 2020-12, and the two standard transports | Base Protocol Overview Reference 7 https://modelcontextprotocol.io/specification/2026-07-28/basic | Sourced |
| Position of MRTR (replacing server-initiated requests; no shared storage or stateful load balancing needed) | Multi Round-Trip Requests Reference 8 https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr | Sourced |
| The three primitives and their control categories; tool definitions, listing, order, caching and safety requirements; resource URIs; user-controlled prompts | Server-features chapter Reference 9 https://modelcontextprotocol.io/specification/2026-07-28/server Reference 10 https://modelcontextprotocol.io/specification/2026-07-28/server/tools Reference 11 https://modelcontextprotocol.io/specification/2026-07-28/server/resources Reference 32 https://modelcontextprotocol.io/specification/2026-07-28/server/prompts | Sourced |
| Elicitation (form and URL modes; secrets only in URL mode) | Elicitation Reference 15 https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation | Sourced |
| Origin validation and localhost binding for Streamable HTTP | Streamable HTTP Reference 16 https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http | Sourced |
| Authorization requirements (OPTIONAL; SHOULD for HTTP; SHOULD NOT for stdio; PKCE, resource, audience, iss, scope, token transport, redirect URIs, short-lived tokens) | Authorization and Authorization Security Considerations Reference 12 https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization Reference 13 https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations | Sourced |
| Names of operational problems and the direction of countermeasures (confused deputy, token passthrough, SSRF, state handle hijacking, local servers, over-broad scopes) | Security Best Practices Reference 14 https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices | Sourced |
| Tool definitions can occupy the context; progressive tool discovery (example threshold of 1% to 5%) | Client Best Practices Reference 17 https://modelcontextprotocol.io/docs/2026-07-28/develop/clients/client-best-practices | Sourced |
| Stewardship (LF Projects, hierarchy of maintainers, individual-based membership) and the state of the Tasks extension | Governance and Tasks Reference 18 https://modelcontextprotocol.io/community/governance Reference 19 https://modelcontextprotocol.io/extensions/tasks/overview | Sourced |
| Release of MCP (25 November 2024, Anthropic), the AAIF formation announcement (9 December 2025) and the founding contributions (MCP, goose, AGENTS.md), and when AGENTS.md was released | Anthropic announcement and Linux Foundation announcement Reference 20 https://www.anthropic.com/news/model-context-protocol Reference 21 https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation | Sourced |
| A2A's role, the Agent Card, versions (latest released version 1.0.0; the v1.0.1 release), A2A-Version, development by Google and donation to the Linux Foundation, acceptance at the AAIF (as stated in the A2A blog of 27 August 2026), and complementarity with MCP | A2A specification, comparison page, blog and release Reference 22 https://a2a-protocol.org/latest/specification/ Reference 23 https://a2a-protocol.org/latest/topics/a2a-and-mcp/ Reference 24 https://a2a-protocol.org/latest/blog/2026/08/27/a-new-chapter-for-a2a-joining-the-agentic-ai-foundation/ Reference 25 https://github.com/a2aproject/A2A/releases/tag/v1.0.1 | Sourced |
| OWASP ASI01 to ASI10 (December 2025, 2026 edition), the description of tampering with MCP tool descriptors as an example under ASI02, and the titles of LLM01 and LLM03 in the LLM Top 10 2026 and of LLM06 Excessive Agency in the 2025 edition | OWASP GenAI Security Project Reference 26 https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ Reference 27 https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ Reference 28 https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ | Sourced |
| The current name of the NIST evaluation unit (CAISSI) and its name at the time (CAISI), the terminology provision of Executive Order 14434, NIST's AI Agent Standards Initiative (created 2026-02-17, updated 2026-08-14), the CAISI request for information (2026-01-08, responses due 2026-03-09), and the NCCoE concept paper (DRAFT, February 2026, comments 2026-02-05 to 04-02). All are work in progress, not final standards | NIST, Federal Register and NCCoE Reference 29 https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative Reference 30 https://www.govinfo.gov/content/pkg/FR-2026-01-08/html/2026-00206.htm Reference 31 https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf Reference 52 https://www.nist.gov/caissi Reference 53 https://www.federalregister.gov/documents/2026/10/02/2026-20321/inaugurating-the-era-of-super-intelligence | Not yet confirmed |
| OAuth 2.1 is an IETF draft (revision 16), CIMD is also an IETF draft (revision 02), and the titles and publication dates of the RFCs (9728, 8707, 7636, 9207, 8414) | IETF Datatracker and RFC Editor Reference 33 https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ Reference 37 https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/ Reference 34 https://www.rfc-editor.org/rfc/rfc9728 Reference 35 https://www.rfc-editor.org/rfc/rfc8707 Reference 36 https://www.rfc-editor.org/rfc/rfc7636 Reference 38 https://www.rfc-editor.org/rfc/rfc9207 Reference 51 https://www.rfc-editor.org/rfc/rfc8414 | Not yet confirmed |
| Benchmark contents (MCP-Atlas: 1,000 tasks, 36 servers, 220 tools, 500 public and 500 private; MCPMark: 127 tasks, pass@1 and pass^4; MCP-Universe: 6 domains, 11 servers; MCPTox: 45 servers, 353 tools, 1,348 cases; AgentDojo: 97 tasks, 629 cases) | Abstracts of each paper Reference 39 https://arxiv.org/abs/2602.00933 Reference 40 https://arxiv.org/abs/2509.24002 Reference 49 https://arxiv.org/abs/2508.14704 Reference 41 https://arxiv.org/abs/2508.14925 Reference 42 https://arxiv.org/abs/2406.13352 | Sourced |
| The role of MCP Inspector and the existence of the conformance repository (contents not checked) | Official MCP page and GitHub Reference 44 https://modelcontextprotocol.io/docs/2026-07-28/tools/inspector Reference 43 https://github.com/modelcontextprotocol/conformance | Sourced |
| Number, title and edition of ISO/IEC 42001:2023 (Edition 1, 2023-12) and ISO/IEC 23894:2023 (Edition 1, 2023-02); NIST AI 100-1 (January 2023), AI 600-1 (July 2024), AI 100-2e2025 (March 2025; Section 3.5 on agent security and Section 3.6 on evaluation resources) | ISO standard pages and NIST publications (the ISO texts themselves were not checked) Reference 45 https://www.iso.org/standard/42001 Reference 46 https://www.iso.org/standard/77304.html Reference 47 https://doi.org/10.6028/NIST.AI.100-1 Reference 48 https://doi.org/10.6028/NIST.AI.600-1 Reference 50 https://doi.org/10.6028/NIST.AI.100-2e2025 | Sourced |
| Counting of connections (N x M versus N + M; 3 x 3 = 9 and 6, 5 x 8 = 40 and 13, 10 x 20 = 200 and 30) | Our calculation. A simplification that only counts connectors; not an effort estimate | Our calculation |
| Whether MCP or A2A has been issued as an ISO/IEC or IEEE standard, the supported revisions of individual client and server products, the contents of conformance tests, and adoption-scale figures | Not confirmed from the primary sources this article could reach, and therefore not stated | Commentary |
| The readings that "decide before connecting instruments and data to an AI", "tool definitions are input and affect compute", and the three-layer view of permissions (connection, tool, human); the organization of the figures and cautions | This article's organization and commentary based on published material; not views stated by any organization | Commentary |
| That Figs. 2 to 7 are explanatory drawings, not real product structures or data, and that Figs. 1 and 8 are AI-generated images | Note by this article | Commentary |
Last updated: 15 October 2026 / Sources are limited to primary material (the official MCP and A2A specifications, announcements by the Linux Foundation and Anthropic, official OWASP, NIST, IETF and ISO pages, and arXiv papers). The texts of the ISO/IEC standards are paid and were not checked. This field moves fast, and versions and statuses are those of the confirmation date (15 October 2026). The status of MCP and A2A as international standards, the revisions supported by individual products, the contents of conformance tests and adoption-scale figures could not be confirmed and are therefore not stated. Figs. 2 to 7 are vector drawings and Figs. 1 and 8 are AI-generated images; none of them depicts a real facility, product or measurement result.