mpp 1.0.0

MPP Check v1.0.0

Status

• Version: 1.0.0
• Check identifier: mpp
• Input contract: [email protected]
• Output contract: [email protected]
• Scope: site-level HTTP/OpenAPI evidence for mpp.dev-style Machine Payments Protocol support

Abstract

This check validates mpp.dev-style MPP discovery and safe runtime payment challenges for origins that expose machine-payable API resources. It does not execute payments, generate credentials, or submit Authorization: Payment.

Motivation

Agents need a deterministic way to discover paid resources before calling them. mpp.dev presents OpenAPI discovery at /openapi.json plus runtime 402 payment challenges as the HTTP path for that discovery. Without canonical discovery or explicitly documented paid routes, a checker cannot safely know which paths to probe.

Normative Model

The check uses mpp.dev as its protocol source. MPP is modeled as a Challenge-Credential-Receipt lifecycle:

• Challenge: a paid resource returns HTTP 402 with WWW-Authenticate: Payment.
• Credential: a client retries with Authorization: Payment.
• Receipt: a successful paid response can include Payment-Receipt.

For HTTP APIs, mpp.dev-documented discovery uses GET /openapi.json, operation-level x-payment-info, and payment offers. Payable operations should declare a 402 response.

Applicability

The check applies when public evidence suggests mpp.dev-style MPP support:

• /openapi.json contains operation-level x-payment-info.
• a safe route returns 402 with WWW-Authenticate: Payment.
• public docs or agent metadata mention Machine Payments Protocol, MPP, mpp.dev, mppx, Challenge-Credential-Receipt, Authorization: Payment, or Payment-Receipt.
• llms.txt or llms-full.txt identifies MPP support.

The check is not applicable when there is no public MPP signal, or when the site only exposes ordinary human checkout.

Pass Criteria

The check passes when it finds valid MPP discovery or a valid safe runtime challenge:

• /openapi.json is reachable and parseable.
• at least one OpenAPI operation has x-payment-info.
• each payable operation declares a 402 response.
• each offer includes method, intent, and amount.
• offer amounts are null or non-negative integer strings.
• a safe documented route returns 402 with WWW-Authenticate: Payment.
• runtime Payment challenges include id, realm, method, intent, and request.

Warning Criteria

The check warns when MPP evidence is partial or ambiguous:

• MPP is claimed, but /openapi.json is missing.
• MPP routes are documented only outside canonical discovery.
• no explicit safe GET route is available to probe.
• a body-bearing payable operation omits requestBody.
• a 402 challenge is not safely observable.
• MPP and x402 compatibility are both present, but the MPP surface is unclear.

Missing /openapi.json is a real discovery defect. The check does not guess arbitrary paid paths when canonical discovery is absent.

Failure Criteria

The check fails when MPP is claimed but the visible MPP surface is malformed or unsafe:

• /openapi.json is present but cannot be parsed.
• /openapi.json is not shaped like OpenAPI.
• x-payment-info is malformed.
• a payable operation omits a 402 response.
• an offer omits method, intent, or amount.
• an amount is not null or a non-negative integer string.
• a documented payable route returns 402 without WWW-Authenticate: Payment.
• a Payment challenge omits id, realm, method, intent, or request.
• public metadata exposes credentials, private keys, private hosts, or unsafe payment endpoints.
• only x402-style PAYMENT-* evidence is present and no mpp.dev-style MPP evidence is found.

Evidence Model

Evidence includes:

• applicability signals
• /openapi.json status, content type, and parse state
• payable operation path and method
• offer count, method, intent, and amount shape
• 402 response declaration presence
• explicit safe runtime probe candidates
• runtime status code and selected payment headers
• Payment challenge required parameter presence
• metadata findings from llms.txt and llms-full.txt
• x402-only evidence as adjacent evidence
• secret or unsafe endpoint flags

Evidence must not include full credentials, full payment authorization payloads, cookies, bearer tokens, private keys, wallet secrets, or full receipt payloads.

Validation And Scoring Steps

• applicability (0.10): identify mpp.dev-style MPP signals.
• canonical-discovery (0.20): fetch /openapi.json.
• payment-discovery (0.25): validate OpenAPI x-payment-info, offers, amount format, and 402 responses.
• documented-routes (0.10): find only explicit safe payable GET routes.
• runtime-challenge (0.20): probe documented candidates for 402 plus WWW-Authenticate: Payment.
• protocol-distinction (0.05): keep x402-only evidence from passing as MPP.
• security-review (0.10): flag credentials, secrets, private endpoints, and unsafe public metadata.

Standard Behavior

If no MPP signal is visible, the result is not_applicable.

If valid canonical discovery is present, the result can pass without executing payment.

If canonical discovery is missing but a documented safe route returns a valid Payment challenge, the result can pass runtime validation while warning that discovery is missing.

If MPP is claimed and neither canonical discovery nor explicit safe runtime evidence is available, the result warns or fails based on the strength and quality of the claim.

Non-Standard And Real-World Behavior

Some services may document paid routes in public docs, llms.txt, or llms-full.txt before publishing canonical discovery. The check can use those explicit routes as safe candidates, but it does not crawl or guess paid endpoints.

Some services may support x402 compatibility alongside MPP. x402-only headers are adjacent evidence, not MPP pass evidence.

Non-Goals And Limitations

This check does not:

• execute payments
• send Authorization: Payment
• generate credentials
• verify settlement
• validate provider-specific payment proofs
• validate every OpenAPI rule
• crawl arbitrary API paths
• probe unsafe, authenticated, state-changing, or body-bearing operations
• validate MCP, JSON-RPC, or WebSocket MPP transports

References

• mpp.dev/
• mpp.dev/llms.txt
• mpp.dev/llms-full.txt

mpp v1.0.0 Changelog

• Validates canonical /openapi.json discovery, operation-level x-payment-info, payment offers, and 402 response declarations.
• Treats missing canonical discovery as a discovery defect and probes only explicitly documented safe GET routes.
• Recognizes 402 plus WWW-Authenticate: Payment as runtime MPP evidence without executing payments.
• Distinguishes mpp.dev-style MPP evidence from x402-only PAYMENT-* headers.