scanned May 24, 2026

MPP

mpp.dev

financeVisit site →

MPP is an open protocol for machine-to-machine payments, allowing for charging per request in the same HTTP call.

68/100

Tier 4 · Agent-Ready

Content answers62/100
Protocol plumbing81/10013 of 16 checks pass
Re-audit3355h ago· 1 credit

Scored by asking 15 questions a buyer of a finance product asks, then grading this site’s own pages: answered, hedged (partial or vague), or silent (no page answers it). How scoring works

15 buyer questions · graded against the site’s own pages

1 of 15 come back answered. 12 get a hedge. 2 meet silence.

1 answerable12 half-answers2 silent

Goes silent · security · medium importance

My compliance team needs to know — does MPP hold any SOC 2, PCI DSS, or ISO 27001 certifications, and can we get the reports under NDA?

Goes silent · technical · low importance

For Lightning payments, who pays the routing fees — are they deducted from the recipient amount or added to the payer's charge?

This report is public. Own mpp.dev? Claiming is free: crawl every page, re-audit as you fix, and track your score over time.

Sign in to claim

The fix queue

32 points sit between mpp.dev and 100: 14 open questions and 3 missing protocol checks, ordered by estimated payoff.

Point estimates are per fix under scoring v2. They are not additive to a promised total.

01security · importance mediumGoes silent+7 content pts est.

My compliance team needs to know — does MPP hold any SOC 2, PCI DSS, or ISO 27001 certifications, and can we get the reports under NDA?

What the pages say

No page on the site addresses this.

The fix

Add a dedicated security/compliance page or FAQ entry that lists current certifications (SOC 2, PCI DSS, ISO 27001) and explains how prospects can request reports under NDA.

Where we looked: /llms-full.txt, /faq, /advanced/security

confidence high · grounding synthesized · weight 0.00 · Absent

02technical · importance lowGoes silent+7 content pts est.

For Lightning payments, who pays the routing fees — are they deducted from the recipient amount or added to the payer's charge?

What the pages say

No page on the site addresses this.

The fix

Add documentation to the Lightning payment method pages explaining whether routing fees are deducted from the recipient's amount or added to the payer's charge.

confidence high · grounding world-knowledge · weight 0.00 · Absent

Hedged · 12 of 15 questions

A buyer gets something, then has to guess the rest. Expand any row for the evidence and the fix.

03We're launching a high-frequency trading bot — what are the default rate limits for charge requests per second, and can we request increases?limitsHedges+2 pts est.

We're launching a high-frequency trading bot — what are the default rate limits for charge requests per second, and can we request increases?

What the pages say

The site does not state default platform API rate limits for charge requests per second or explain how to request limit increases. It does describe payment-method throughput characteristics: Stellar's Charge pattern handles 'One transaction per request' with ~5s on-chain latency, while its Channel pattern enables 'many commitments per second per channel' for high-frequency metered billing with near-zero latency after channel open. Lightning's Session pattern supports 'Hundreds of requests per session' with near-zero latency after deposit.

The fix

Add a dedicated 'Rate Limits' or 'Quotas' documentation page that lists the default requests-per-second cap for charge API calls and describes how customers can request a limit increase for high-frequency trading use cases.

Where we looked: /payment-methods/stellar, /payment-methods/lightning

confidence high · grounding synthesized · weight 0.70 · Vague

04For card payments specifically, how long until funds settle to my account — is it T+2, instant, or does it vary by processor?operationsHedges+2 pts est.

For card payments specifically, how long until funds settle to my account — is it T+2, instant, or does it vary by processor?

What the pages say

The retrieved chunks do not specify the settlement timing for card payments (whether T+2, instant, or processor-specific). Chunks [4] and [8] indicate that card payments are processed via Stripe using encrypted network tokens, while chunks [10], [15], and [18] describe settlement timing for other payment methods—Tempo charges settle in ~500ms with instant finality, Lightning charge settlements are immediate per-request via HTLC, and Tempo sessions settle periodically on-chain—but no chunk states how long card payment funds take to reach your account.

The fix

Add a section to the 'Accept card payments' guide or the 'Payment methods' page that explicitly states the settlement timeline for card payments (e.g., 'Funds settle according to Stripe’s standard schedule, typically T+2 business days').

Where we looked: /payment-methods, /llms-full.txt, /payment-methods/tempo, /payment-methods/lightning, /payment-methods/tempo

confidence high · grounding synthesized · weight 0.70 · Vague

05I'm comparing MPP to Stripe for microtransactions — what's the exact percentage fee per transaction, and does it change based on volume or payment method?pricingHedges+2 pts est.

I'm comparing MPP to Stripe for microtransactions — what's the exact percentage fee per transaction, and does it change based on volume or payment method?

What the pages say

MPP does not publish an exact percentage fee per transaction. The protocol itself is free and open with no licensing fees, and individual services set their own pricing (typically $0.01–$0.10 per request for charges). For the Tempo rail, on-chain transaction fees are described as “sub-cent,” while session-based (off-chain) payments have “near-zero per-request fees” because only net settlement hits the chain. The site notes that traditional credit card processing typically costs $0.30 plus 2.9%, but it does not specify exact MPP fees for Stripe or other rails, nor does it mention volume-based discounts or payment-method-based fee schedules.

The fix

Add a pricing page or table that lists exact transaction fees (percentage or fixed) for each payment rail (Tempo, Stripe, Lightning, etc.) and clarifies whether fees vary by volume, payment method, or transaction mechanism.

Where we looked: /faq, /use-cases/micropayments, /use-cases/micropayments

confidence high · grounding synthesized · weight 0.70 · Vague

06We're currently on x402 — what are the exact breaking changes in request/response formats when upgrading to MPP, and is there an automated migration tool?migrationThin on specifics+2 pts est.

We're currently on x402 — what are the exact breaking changes in request/response formats when upgrading to MPP, and is there an automated migration tool?

What the pages say

The site documents several breaking changes in request/response formats when upgrading from x402 to MPP, but does not mention an automated migration tool. **Breaking changes in request/response formats:** - **HTTP headers:** x402's `PAYMENT-REQUIRED` becomes `WWW-Authenticate: Payment`; `PAYMENT-SIGNATURE` becomes `Authorization: Payment`; `PAYMENT-RESPONSE` becomes `Payment-Receipt`. - **Amount format:** MPP uses dollars (e.g., `'0.01'`) instead of atomic units (e.g., `'10000'`). - **Pricing configuration:** MPP uses per-route pricing via `mppx.charge` middleware instead of a global config map. - **Header parsing:** MPP handles `WWW-Authenticate`, `Authorization`, and `Payment-Receipt` automatically; x402 required manual parsing. - **Verification/settlement:** x402 typically calls an external facilitator for `POST /verify` and `POST /settle`; MPP handles this internally in the SDK. - **Error format:** x402 uses custom errors; MPP uses RFC 9457 Problem Details. - **Idempotency:** Not built into x402; built into MPP via Challenge binding. **Automated migration tool:** None is mentioned. The documented upgrade path is manual: install the `mppx` SDK, swap the payment middleware, and add `mppx.charge` to each paid endpoint.

The fix

Add a section to the migration guide explicitly stating whether an automated migration tool exists (e.g., a CLI codemod) or confirming that migration is manual. If manual is the only path, a checklist or step-by-step wizard in the docs would help set expectations.

Where we looked: /llms-full.txt, /guides/upgrade-x402, /guides/upgrade-x402, /guides/upgrade-x402, /llms-full.txt, /llms-full.txt

confidence high · grounding synthesized · weight 0.70 · Absent

07I need to integrate a corporate ledger system that's not listed — does the extensions framework require implementing a specific interface, and where's the full spec?integrationHedges+2 pts est.

I need to integrate a corporate ledger system that's not listed — does the extensions framework require implementing a specific interface, and where's the full spec?

What the pages say

The Extensions page mentions that users can build custom integrations and points to a “Custom payment methods” page at https://mpp.dev/extensions/payment-methods/custom, but the retrieved chunks do not specify whether an extensions framework requires implementing a specific interface, nor do they contain the full spec for integrating a corporate ledger system.

The fix

Publish the interface requirements and full specification for building custom payment-method integrations on the Custom payment methods page so buyers can evaluate integration effort without leaving the docs.

Where we looked: /extensions, /llms-full.txt

confidence medium · grounding synthesized · weight 0.65 · Vague

08For the identity verification flow, what specific wallet signatures or attestations are required — is EIP-712 mandatory or do you support SIWE?technicalHedges+2 pts est.

For the identity verification flow, what specific wallet signatures or attestations are required — is EIP-712 mandatory or do you support SIWE?

What the pages say

For identity verification (zero-dollar auth), the client must sign a proof message over the Challenge ID. The Credential payload is `{"type":"proof","signature":"0x..."}` and the server verifies that signature against the `source` DID. For paid Tempo requests, the client submits a transaction signature instead. The retrieved chunks do not specify whether EIP-712 structured signing is mandatory, and they do not mention support for SIWE (Sign-In with Ethereum).

The fix

Add explicit documentation on the signature schemes required for identity verification, stating whether EIP-712 is mandatory and whether SIWE (Sign-In with Ethereum) is supported.

Where we looked: /llms-full.txt, /advanced/identity, /llms-full.txt, /advanced/identity, /llms-full.txt

confidence medium · grounding synthesized · weight 0.65 · Vague

09When using discovery to find MPP-enabled services, what fields are required in the service metadata — is there a JSON Schema or OpenAPI spec I can validate against?technicalHedges+2 pts est.

When using discovery to find MPP-enabled services, what fields are required in the service metadata — is there a JSON Schema or OpenAPI spec I can validate against?

What the pages say

The chunks show that MPP discovery uses a standard OpenAPI 3.1 document served at `/openapi.json` with an `x-payment-info` extension containing an `offers` array. Each offer entry includes `amount`, `currency`, `intent`, and `method` fields. However, the chunks do not explicitly document which fields are required versus optional, and they do not provide a dedicated JSON Schema or OpenAPI extension spec for validating the `x-payment-info` structure.

The fix

Publish a formal JSON Schema or OpenAPI extension specification for `x-payment-info` that explicitly lists required and optional fields, and link to it from the discovery documentation.

Where we looked: /blog/multi-method-discovery, /advanced/discovery, /quickstart/server

confidence medium · grounding synthesized · weight 0.65 · Vague

10For the MCP server monetization guide, does MPP take a platform fee on top of transaction fees, and is there a revenue share for the protocol itself?pricingHedges+2 pts est.

For the MCP server monetization guide, does MPP take a platform fee on top of transaction fees, and is there a revenue share for the protocol itself?

What the pages say

The MCP server monetization guide does not state whether MPP charges a platform fee or takes a protocol revenue share. The guide shows payments settling directly to the developer-configured recipient address (e.g., `recipient: '0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266'`), with no mention of an MPP platform fee or protocol revenue share. MPP's split-payments feature supports routing platform fees and revenue shares generally, but the guide does not indicate that MPP itself charges these.

The fix

Add a clear statement in the MCP monetization guide about whether MPP charges any platform or protocol fees, or explicitly state that developers keep the full payment minus network transaction fees.

Where we looked: /llms-full.txt, /llms-full.txt, /guides/monetize-mcp-server, /llms-full.txt

confidence medium · grounding synthesized · weight 0.65 · Vague

11When proxying an existing service with MPP, what happens if the upstream times out after payment authorization but before response — is the payment auto-captured or held?technicalHedges+2 pts est.

When proxying an existing service with MPP, what happens if the upstream times out after payment authorization but before response — is the payment auto-captured or held?

What the pages say

The proxy verifies the client's payment credential before forwarding the request to the origin, but the retrieved chunks do not specify what happens to the payment if the upstream times out after authorization — whether it is auto-captured or held.

The fix

Add a section to the 'Proxy an existing service' guide explaining timeout and error-handling behavior, specifically whether payments are captured or held when the upstream fails after authorization.

Where we looked: /guides/proxy-existing-service, /llms-full.txt

confidence high · grounding synthesized · weight 0.70 · Vague

12In a streamed payment scenario, how frequently are partial payments reconciled and committed — per second, per chunk, or configurable by the merchant?operationsHedges+2 pts est.

In a streamed payment scenario, how frequently are partial payments reconciled and committed — per second, per chunk, or configurable by the merchant?

What the pages say

For Tempo-based streamed payments (the default SSE method), partial payments are handled as off-chain vouchers that the server periodically settles on-chain; the chunks do not specify whether this period is per second, per chunk, or merchant-configurable. The code examples charge one tick per yielded SSE chunk, but the documentation clarifies that individual interactions bypass on-chain consensus and are settled in batches. For Lightning-based streaming, billing is an integer decrement per chunk handled locally during the session. The site does not document a merchant-configurable reconciliation interval.

The fix

Add explicit documentation on the settlement interval for Tempo streaming sessions—e.g., whether reconciliation is time-based (per second/minute), event-based (per chunk), or exposes a merchant configuration option.

Where we looked: /llms-full.txt, /llms-full.txt, /payment-methods/lightning/session

confidence medium · grounding synthesized · weight 0.65 · Vague

13The Go SDK announcement mentioned generics support — what's the minimum Go version required, and are there any CGO dependencies for the crypto operations?integrationHedges+1 pt est.

The Go SDK announcement mentioned generics support — what's the minimum Go version required, and are there any CGO dependencies for the crypto operations?

What the pages say

The minimum Go version required is Go 1.21+. The retrieved chunks do not mention CGO dependencies for crypto operations, nor do they reference a generics support announcement.

The fix

Clarify on the Go SDK Requirements page whether crypto operations require CGO, and document the generics support announcement if applicable.

Where we looked: /sdk/go, /llms-full.txt

confidence high · grounding stated · weight 0.80 · Vague

14For split payments, what's the hard limit on number of recipients per transaction — and does the protocol enforce this or is it implementation-specific?limitsHedges+1 pt est.

For split payments, what's the hard limit on number of recipients per transaction — and does the protocol enforce this or is it implementation-specific?

What the pages say

The hard limit is 10 splits per charge (documented as “1–10”). The retrieved chunks do not explicitly state whether this limit is enforced at the protocol level or is implementation-specific.

The fix

Clarify in the Split Payments Constraints section whether the 10-split limit is enforced by the protocol (e.g., via client or server validation) or is an implementation-specific recommendation.

Where we looked: /llms-full.txt, /llms-full.txt, /guides/split-payments

confidence high · grounding stated · weight 0.80 · Vague

What the pages already answer cleanly

1 of 15. Answered with enough specificity for a buyer to act on. This is the bar the queue above is chasing.

operationsAnswered

If a customer disputes part of a streamed payment, can I issue partial refunds or does it have to be all-or-nothing per charge intent?

What the pages say

Streamed payments in MPP use the session intent, and they support partial refunds by design. In the session flow, the server can claim a partial amount when closing the channel; the remaining unclaimed funds automatically return to the client. This gives sessions a built-in refund mechanism, so it is not all-or-nothing. If you use the charge intent instead, funds settle immediately and refunds are out-of-protocol, but the server can still return funds directly to the client's address at any time via a standard on-chain transfer.

Source: /llms-full.txt, /llms-full.txt, /payment-methods/lightning, /advanced/refunds

confidence high · grounding synthesized · weight 0.95 · Answered

Protocol plumbing · 81/10013 of 16 checks pass · each fix +6 protocol pts est.

The other half of the score: 16 checks for the files and headers agents look for. The 3 below are installs, not judgment calls, and most are an afternoon. Expand any for the snippet and the standard it follows. They sit after the queue because none of them changes what your pages say.

Clean crawlAccess+6 pts est.

StandardSitedex metricSitedex metric

Server-rendered contentRendering+6 pts est.

StandardSitedex metricSitedex metric

WebMCP widgetInteraction+6 pts est.

Sitedex generates this file from your crawl. Grab it in Files from this audit below.

StandardW3C WebMCP draftW3C / WHATWG

Already passing 13 of 16: robots.txt, sitemap.xml, llms.txt, AI crawler access, Content signal, Markdown negotiation, MCP card, OpenAPI spec, Canonical URLs, Meta descriptions, HTML lang attribute, Organization schema, Sitemap lastmod.

Ask this site’s index

Sitedex already serves mpp.dev as an MCP endpoint. Ask mpp.dev anything an AI agent might ask, and see what its index returns. (To score your own site, use the form below.)

Snippets & configs

For developers and the engineer-on-call: copy these into your tools or your site.

Files from this audit

Built from this crawl. Download or copy each, then install it at the path noted.

llms.txt

Built from this crawl. Install at /llms.txt so agents start here.

organization.json

Organization JSON-LD, pre-filled from this crawl. Wrap in a ld+json script.

server-card.json

MCP server card built from this crawl. Host at /.well-known/mcp/server-card.json.

webmcp.json

WebMCP discovery manifest built from this crawl. Host at /.well-known/webmcp.json.

MCP endpoint

https://mcp.sitedex.dev/s/mpp-dev/mcp

The URL anyone's agent points at. Read-only; safe to share.

Claude Code

claude mcp add mpp --transport http https://mcp.sitedex.dev/s/mpp-dev/mcp

One command, then the agent has it.

Cursor / Continue

{
  "mcpServers": {
    "mpp": {
      "url": "https://mcp.sitedex.dev/s/mpp-dev/mcp"
    }
  }
}

Drop into mcp.json.

WebMCP: two parts

WebMCP-capable browsers run the widget at runtime. Crawlers without JS rendering need the discovery manifest to find your tool surface. Install both.

1 · Widget script

<script async src="https://sitedex.dev/widget.js"></script>

Drop in <head>. In browsers with WebMCP, this script registers your site's tools with navigator.modelContext.registerTool().

2 · Discovery manifest

{
  "schema_version": "2026-04",
  "name": "MPP",
  "description": "MPP is an open protocol for machine-to-machine payments, allowing for charging per request in the same HTTP call. WebMCP tools served by Sitedex.",
  "homepage": "https://mpp.dev",
  "documentation": "https://app.sitedex.dev/sites/mpp.dev",
  "source": "navigator.modelContext",
  "tools": [
    {
      "name": "search_site_content",
      "description": "Ask about this site in plain language and get the most relevant passages from its pages, each with the source URL and a relevance score. Searches the site's published text, not live inventory or accounts."
    },
    {
      "name": "get_site_info",
      "description": "This site's profile: name, description, category, who it is for, page count, and AI Visibility Score. Use it to learn what the site is before you search it."
    },
    {
      "name": "list_site_pages",
      "description": "The pages indexed on this site, with title, URL, and path. Use it to see what the site covers, or to find the path to pass to get_site_page."
    },
    {
      "name": "get_site_page",
      "description": "The full markdown of one page on this site, by path. Use it after search_site_content points you at a page and you want all of it."
    }
  ]
}

Host alongside the script at /.well-known/webmcp.json. Crawlers that don't render JS rely on this.

Your turn

See which of these questions your site goes silent on.

Free, about 5 minutes. We crawl your site, test it against the buyer questions your category asks, and name what’s vague, contradictory, or missing, plus the files AI agents look for.

ComingEmbeddable grade badgeScore history and deltasOpt-in public board