# SDK, MCP, and agent discovery

The agent interface contract exposes one shared verification model through SDK, CLI, HTTP, and MCP surfaces. [Implementation status](https://proof21.xyz/docs/start/status/) identifies which interfaces are available.

## One core, several interfaces

The TypeScript reference core owns interpretation. CLI, HTTP, MCP, and client-language bindings carry the same findings, limitations, and errors without implementing conflicting policy logic or reducing the result to a boolean.

## Producer and consumer tools

The interface specification defines `p21_verify_report`, `p21_check_payment`, `p21_resolve_element`, `p21_request_sample`, and `p21_get_job`. Read-only verification is separate from paid job creation and state-changing operations.

## Two onboarding buttons

**Install locally:** a pinned release, verification instructions, a no-wallet sample, and an invalid example that fails.

**Connect your agent:** a reviewed configuration, supported capabilities, required permissions, prices, and an explicit spending cap. A remote MCP connection must not silently request wallet keys.

A public skill or setup guide teaches an agent to use P21. Repository `AGENTS.md` instructs coding agents developing P21. Neither overrides the operator's permissions.

## Discovery is not authority

Service discovery publishes capability descriptions and schemas for released interfaces. An A2A Agent Card describes a conforming A2A service. GitBook’s documentation MCP provides document retrieval, separate from the P21 verification interface.

References: [MCP Registry](https://modelcontextprotocol.io/registry/about), [A2A discovery](https://a2a-protocol.org/latest/topics/agent-discovery/), [x402 Bazaar](https://docs.x402.org/extensions/bazaar).

<!-- p21-source-payment-v08 -->

## Commercial activation and implementation status

NAT and USDC are both required for the initial commercial-launch acceptance test. Public documentation, source code and policy fixtures are not live payment endpoints. The static payment-policy resource lists required launch methods with `enabled: false`, no recipient and no live endpoint until each rail passes end-to-end settlement, accounting, failure/reorganization, security and owner-approval gates. Do not advertise a USDC-only release as the completed initial payment scope.

No token has been issued, no source element is announced, and no mainnet inscription, customer charge, treasury swap or wallet authorization is performed by this release. Production service availability remains separate from website publication. No Trac partnership, hosted SLA or independent cryptographic audit is implied.


[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry

[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs

[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live

[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer

[5] https://docs.x402.org/core-concepts/network-and-token-support

[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md

[7] https://arxiv.org/abs/1605.04559

<!-- p21-enforcement-v10 -->

## Agent integration boundary

An agent may request verification, evaluate returned artifacts and propose a protected action, but untrusted model text never becomes wallet/API authority. Evidence mode ends at a report. Execution-gated mode passes a draft P21 authorization to a separately protected capability adapter, which recomputes the exact action digest and fails closed on mismatch, expiry, nonce replay or unresolved critical checks.

A receiving agent may also sign a consumer decision receipt. Other agents can verify that decision without granting it power to rewrite the underlying proof or settlement.