m2m-monster
Official# m2m.monster
Non-custodial infrastructure for AI agents to pay each other: discovery over MCP, settlement over x402 v2 with the `m2m-split` scheme on Solana.
> **Mainnet:** API https://api.m2m.monster · Agent docs: https://m2m.monster/llms.txt · Free Devnet sandbox: https://sandbox.m2m.monster
- Agents generate and keep their own keys and sign locally. m2m.monster holds no agents' keys or funds and never signs or pays payment transactions; payers pay their own gas. Quotes and receipts are signed by a service key that holds no funds.
- One atomic transaction, signed only by the payer: amount − fee to the payee in the payment token, and the fee in USDC to the treasury, with the memo `settled via m2m.monster <quote id>`.
- Fee: `min(max(0.25% × amount, $0.001), $0.5)`, borne by the payee. Published at `/pricing.json`.
- Every endpoint and MCP tool that moves funds returns an unsigned transaction.
## Packages
| Package | |
|---|---|
| [`@m2m-monster/sdk`](packages/sdk-ts) | TypeScript SDK: pay 402s, paywall, quotes, receipts |
| [`@m2m-monster/mcp`](apps/mcp) | MCP server (stdio); hosted at `https://api.m2m.monster/mcp` (Devnet: `https://sandbox.m2m.monster/mcp`) |
| [`@m2m-monster/core`](packages/core) | Fees, quotes and `m2m-split` building and verification |
| [`m2m-monster`](sdk-python) (PyPI) | Python SDK, byte-identical transactions |
| [`apps/api`](apps/api) | `/v1` API, relay, receipts and public files |
Contract: [`spec/openapi.json`](spec/openapi.json). Shared test vectors: [`spec/test-vectors`](spec/test-vectors).
## Development
```sh
corepack pnpm install
corepack pnpm build && corepack pnpm test && corepack pnpm lint
cd sdk-python && uv run pytest
```
## License
Apache-2.0
TDQS
Scored across 10 tools
The tools map cleanly to distinct payment lifecycle stages: pricing, quoting, building, verifying, submitting, receipt verification, and refunds. The main possible confusion is between verify_payment and verify_receipt, but their contexts (pre-submit transaction vs confirmed receipt) are adequately differentiated.
All tool names use consistent snake_case with a clear verb_noun pattern such as get_pricing, quote_payment, build_payment, verify_payment, and submit_payment. The minor use of quote_ as a verb is still readable and consistent with the overall convention.
Ten tools are well-scoped for an agent payment server, with each tool covering a meaningful step in the quote-build-verify-submit-receipt-refund flow. Supporting tools for pricing, registration/referrals, and status are also justified without bloating the surface.
The core payment lifecycle is well covered, including fee discovery, quote creation, transaction building, verification, submission, receipt verification, and refunds. Minor gaps remain around retrieving receipt history or listing past payments, despite registration being described as unlocking receipt history.