Start with the unit of work
The first production question is not what the tool costs. It is what the buyer is paying to receive. A summarizer, code auditor, data extractor and research agent all have different acceptance criteria. If the unit of work is vague, the payment flow will look clean while the product remains impossible to verify.
Define the task kind, input references, expected output format, deadline, refund or rejection policy and verifier. Put those terms in an Agreement Object before the tool runs.
Separate access pricing from outcome pricing
Some tools sell access. Others sell an outcome. Access pricing can be simple: pay for this API response. Outcome pricing needs richer semantics: pay if the output passes tests, refund on timeout, partially accept if a subset of tasks complete, or require a human verifier for high-value work.
Do not hide outcome rules in marketing copy or prompt text. They should be machine-readable enough for buyer policy and receipts to inspect.
Add buyer policy before signer access
Any paid MCP tool that can trigger a wallet, facilitator, credit account or settlement rail should meet a buyer-side policy first. Minimum controls include max single payment, max session spend, allowed sellers, allowed rails, approved verifiers and approval-required thresholds.
Policy should run before the signer sees the transaction or payment payload. Once an agent can reach a signer directly, the system has already lost one of its strongest safety boundaries.
Design the verifier like a product surface
A verifier is not an implementation detail. It is the thing buyers will trust when deciding whether work was accepted. For deterministic tasks, tests or schemas may be enough. For subjective tasks, use a human review, committee, rubric or model evaluator with clear limits.
The Verification Receipt should record the verdict and bind it to the agreement. It should not pretend to prove more than the verifier actually checked.
Protect against replay and receipt drift
Paid tools need stable agreement hashes, nonce or payment identifiers, replay storage and consistent canonicalization. The same payment should not authorize multiple executions unless the agreement explicitly allows that behavior.
Receipt drift is another risk. If the agreement, verifier output and settlement evidence are generated by different components, make sure they all reference the same canonical agreement hash.
Keep production claims audit-gated
A demo that works locally is not production-ready. A testnet rail that settles once is not mainnet-certified. A passing conformance suite is not an external audit. A professional paid MCP launch should state these boundaries clearly.
For Accord today, the correct public posture remains alpha / testnet-first and NOT CERTIFIED FOR MAINNET. The safest first path is the mock paid MCP repository audit demo.
FAQ
Can a paid MCP tool launch with only x402?
It can sell paid access, but outcome-oriented work still needs terms, verification and settlement records if the buyer cares about completion.
What should be logged for every paid tool call?
Agreement hash, payment or authority reference, replay identifier, handler output reference, verifier verdict and settlement evidence.
What is the safest first demo path?
Use the mock rail paid MCP repository audit demo before moving to testnet or facilitator-backed payment flows.
Sources and references
Model Context Protocol repository
Official MCP specification and documentation source.
Accord/MCP package
Reference Accord/MCP wrapper package for paid and verifiable MCP tool calls.
Paid MCP repository audit demo
Recommended local demo for the complete agreement, verification and settlement lifecycle.
Run the paid MCP demo
Exercise the lifecycle locally before adding a facilitator, testnet or real rail.