Built directly into the M2M control plane.
See how M2M works with the agent-commerce ecosystem.
This is a reviewed compatibility matrix for customers and developers. It is not a live operational status dashboard, and it does not publish internal infrastructure, security controls, acceptance logs or deployment details.
Reviewed: 2026-09-13Customer integration guide
How to read the matrix
Implementation and customer availability are shown separately.
Support describes how M2M integrates with a standard. Availability describes the customer-facing scope you can use today.
Integration level
Supported through an interoperability adapter, bridge or projection.
Implemented with intentionally limited release scope.
Tracked for ecosystem relevance; no runtime integration is claimed.
Planned for a future release; no current runtime support is claimed.
Customer availability
Generally available for the documented customer scope.
Available for the specific workflows described on this page.
Available for discovery and indexing.
Integration exists, but customer access is currently limited to the documented scope.
Validated for controlled preview; not generally available.
Standards and integrations
MCP, A2A, x402, MPP and AP2.
Protocol versions can advance independently of M2M. The table records the upstream version observed from official project sources alongside the M2M integration profile and customer-facing availability.
| Protocol | Upstream | M2M profile | Integration | Availability |
|---|---|---|---|---|
| Model Context Protocol (MCP)Tool and context interoperability, plus registry discovery. | 2026-07-28Published specificationModel Context Protocol project / Agentic AI Foundation | 2026-07-28 server profileAvailable for service discovery, inspection, quotes and lifecycle reads. Transactional purchasing is not part of the current public MCP scope. | Integration | Available — scoped |
| Agent2Agent Protocol (A2A)Agent capability discovery and agent-to-agent interoperability. | 1.0Stable 1.0 specification lineA2A project / Agentic AI Foundation | A2A 1.0 HTTP+JSONAvailable for Agent Card discovery and bounded inbound interoperability. Commercial execution remains subject to normal M2M eligibility and policy. | Integration | Available — scoped |
| x402Internet-native payment exchange and Bazaar discovery. | 2Protocol version 2x402 Foundation / open-source maintainers | x402 v2Discovery and protocol compatibility are supported. Live purchasing is currently limited rather than generally available. | Integration | Limited |
| Machine Payments Protocol (MPP)HTTP payment authentication and multi-rail machine-payment interoperability. | draft-httpauth-payment-01Evolving standards draftTempo Labs and Stripe | draft-httpauth-payment-01Adapter interoperability is implemented for the documented profile. Public payment execution is not generally available. | Integration | Limited |
| AP2Agent payment authorization, mandates, receipts and dispute evidence. | 0.2Version 0.2 protocol releaseGoogle Agentic Commerce open-source project; standards work continues through FIDO technical working groups | AP2 v0.2 authorization/evidence bridgeAuthorization and evidence interoperability are implemented for the documented profile. External transaction signing is not generally available. | Integration | Limited |
Model Context Protocol (MCP): why it matters and official sources
MCP provides tool and context interoperability around M2M's protocol-neutral procurement model.
Available for service discovery, inspection, quotes and lifecycle reads. Transactional purchasing is not part of the current public MCP scope.
References below are official sources maintained by the relevant protocol project.
Agent2Agent Protocol (A2A): why it matters and official sources
A2A provides agent interoperability around M2M while M2M retains commercial authority and policy.
Available for Agent Card discovery and bounded inbound interoperability. Commercial execution remains subject to normal M2M eligibility and policy.
References below are official sources maintained by the relevant protocol project.
x402: why it matters and official sources
x402 is a payment and discovery interoperability rail around the canonical M2M procurement lifecycle.
Discovery and protocol compatibility are supported. Live purchasing is currently limited rather than generally available.
References below are official sources maintained by the relevant protocol project.
Machine Payments Protocol (MPP): why it matters and official sources
MPP is a payment adapter around M2M's commercial authority, reconciliation, verification and receipt model.
Adapter interoperability is implemented for the documented profile. Public payment execution is not generally available.
References below are official sources maintained by the relevant protocol project.
AP2: why it matters and official sources
AP2 authorization evidence can interoperate with M2M without replacing M2M's protocol-neutral authority and settlement model.
Authorization and evidence interoperability are implemented for the documented profile. External transaction signing is not generally available.
References below are official sources maintained by the relevant protocol project.
M2M capabilities
A customer-facing integration view.
This matrix intentionally includes only information useful for evaluating or integrating M2M. Internal acceptance artifacts, security procedures, infrastructure topology, deployment controls and participant-specific operational details are excluded.
NativeAvailable
Procurement lifecycle
A canonical lifecycle for discovery, comparison, authorization, quotes, execution evidence, evaluation, reconciliation and portable receipts.
NativeAvailable
Federated discovery
Normalize supported external catalog evidence into comparable discovery results without treating discovery as execution authority.
BetaAvailable — scoped
MCP interoperability
Use supported discovery, inspection, quote and lifecycle-read tooling through MCP.
BetaAvailable — scoped
A2A interoperability
Use bounded inbound procurement interactions and capability discovery through A2A.
NativeAvailable
OpenAPI contract
Use the machine-readable HTTP API contract for supported public and authenticated surfaces.
BetaAvailable
Python SDK
Public m2m-market 2.0.0 package for connection, discovery, policy and lifecycle contracts; individual actions remain subject to server-side authorization and product availability.
BetaAvailable
Node.js / TypeScript SDK
Public m2m-market 2.0.0 package for connection and lifecycle contracts; individual actions remain subject to server-side authorization and product availability.
NativeAvailable
Outcome verification
Evaluate service results against capability-specific criteria when suitable evidence is available.
NativeAvailable
Portable receipts
Carry lifecycle, commercial, execution and verification references forward without treating a receipt as proof of correctness by itself.
NativeAvailable
Enterprise controls
Govern organizations, teams, budgets, approved Providers, private catalogs and approval policies at the product level.
BetaPreview
Provider distribution
Prepare supported ecosystem projections and selective publication workflows without implying universal third-party distribution.
NativeAvailable — scoped
Agent and administrator UX
Use discovery, comparison, policy explanations, quotes and lifecycle reads through the M2M Console experience.
Trust language
Discovery, execution, verification and receipts answer different questions.
Catalog evidence
Indexed means M2M has normalized discoverable source material. It does not mean M2M independently verified the service or made it executable.
Source identity / metadata
Source-verified means defined source evidence has been checked. It is not a guarantee that every future service outcome will be correct or useful.
Managed catalog relationship
M2M-managed means the listing or lifecycle is administered through M2M controls. It is not a universal warranty.
Execution asks whether the service ran.
Settlement / reconciliation asks whether the commercial obligation was reconciled.
Outcome verification asks whether available evidence satisfies service-specific verification criteria.
Portable receipt carries lifecycle and evidence references forward; the receipt alone does not prove outcome correctness.
Reputation is a separate evidence signal.
Public information boundary
Security principlesThis page is an integration guide, not an operations console.
Availability labels summarize customer-facing scope. Internal feature flags, deployment controls, security-test evidence, account identifiers and infrastructure details are intentionally not shown.