Skip to main content
Glama
Evozim

m2mcent-sdk

Official
by Evozim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

🛰️ M2MCent SDK — x402 Payment Wrapper for AI Agents

npm version License: MIT Base Mainnet

Ultra-lightweight x402 payment interceptor for AI Agents and MCP Servers. Monetize any API in 3 lines of code.

🚀 Quick Start

npm install m2mcent-sdk
import { X402Handler } from 'm2mcent-sdk';

const x402 = new X402Handler({
  rpcUrl: 'https://mainnet.base.org',
  privateKey: process.env.RELAYER_PRIVATE_KEY!,
  recipient: process.env.TREASURY_ADDRESS!
});

// Protect any Express endpoint with a USDC paywall
app.post('/api/analyze', x402.requirePayment("100000"), (req, res) => {
  res.json({ result: "Premium analysis complete", receipt: req.paymentTx });
});

Related MCP server: @arispay/payagent-mcp

📐 How It Works

M2MCent implements the x402 Payment Protocol — a machine-native payment standard inspired by HTTP 402:

  1. Agent requests a protected endpoint

  2. Server responds with 402 Payment Required + payment metadata (Base64 encoded)

  3. Agent signs an EIP-712 typed data authorization (gasless for the payer)

  4. Server settles atomically on-chain via the M2MCent Escrow contract

  5. Agent receives the premium response + transaction receipt

Agent ──► API Server ──► 402 + metadata
Agent ◄── signs EIP-712 authorization
Agent ──► API Server + Payment-Signature header
          └──► Escrow.settle() on Base L2
Agent ◄── Premium Response + tx hash

⚙️ Configuration

Parameter

Description

Required

rpcUrl

Base Mainnet RPC endpoint

✅

privateKey

Relayer wallet private key (for settlement)

✅

recipient

Treasury address to receive payments

✅

🔒 Security

  • Non-custodial: Funds flow directly from payer → treasury via on-chain escrow

  • Gasless for payers: Uses EIP-3009 transferWithAuthorization (USDC native)

  • Zero-Leak: No agent data is retained after settlement

  • Atomic: Payment and service delivery happen in a single request cycle

🌐 Network Details

Parameter

Value

Network

Base Mainnet (Chain ID: 8453)

USDC Contract

0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913

Escrow Contract

0xf3c3416A843d13C944554A54Ac274BB7fF264BcC

Settlement

Atomic, sub-second finality

🧩 MCP Server Integration

Perfect for Model Context Protocol servers:

import express from 'express';
import { X402Handler } from 'm2mcent-sdk';

const app = express();
const x402 = new X402Handler({
  rpcUrl: process.env.BASE_RPC_URL!,
  privateKey: process.env.RELAYER_PRIVATE_KEY!,
  recipient: process.env.TREASURY_ADDRESS!
});

// Any MCP tool endpoint becomes monetizable
app.post('/api/tools/analyze', x402.requirePayment("50000"), async (req, res) => {
  const result = await runMCPTool(req.body);
  res.json({ ...result, paymentTx: req.paymentTx });
});

📊 Ecosystem

M2MCent powers 100+ production MCP servers on Base Mainnet, processing real USDC micro-payments for AI-to-AI commerce.

📄 License

MIT © M2MCent

Available Tools

2 tools
execute_m2mcent_toolB

Execute any of the 1,004 M2MCent microservices. Fee varies per node (e.g. $0.01 - $0.50 USDC).

ParametersJSON Schema
NameRequiredDescriptionDefault
payloadYesJSON stringified payload or text query for the tool
toolNameYesThe exact name of the tool (e.g. 'defi-sentinel-mcp', '3d-meshweaver-mcp')

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It adds genuine value by disclosing the financial cost ($0.01-$0.50 USDC), which is a meaningful behavioral trait not inferable from the name. However, it omits other behavioral traits for a dispatcher tool: no mention of side effects, failure behavior for unknown toolNames, response format, or external network calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first front-loads the primary purpose, the second adds the essential cost caveat. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a high-complexity tool dispatching to 1,004 heterogeneous microservices, with no output schema and no annotations to lean on. The description does not address how an agent should discover the correct toolName, what errors occur on invalid input, or what the response looks like — leaving a large surface area under-documented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds marginal context for toolName by noting that each microservice/node carries a varying fee, which helps agents weigh cost when selecting parameters. It adds nothing for payload beyond what the schema already states ('JSON stringified payload or text query').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Execute') and resource ('1,004 M2MCent microservices'), making the dispatch role clear. It implicitly differentiates from the sibling search_m2mcent_catalog by framing this as the execution counterpart to discovery, though it never names the sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage guidance is the cost warning ('Fee varies per node'), which is a real consideration but not routing guidance. The description never tells the agent to use search_m2mcent_catalog first to identify a valid toolName, nor does it explain when to avoid execution or how to handle invalid tool names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_m2mcent_catalogB

Search the M2MCent Universal Catalog of 1,004+ Agentic Services

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesKeyword to search for in the catalog (e.g. 'pdf', 'crypto', 'vision')

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden of behavioral disclosure. It only says 'Search', which implies a read-only operation, but it does not state whether results are limited to the 1,004+ services, whether pagination exists, or what the response contains. Minimal behavioral context is added beyond the tool's name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action and resource, with no redundant words or filler. Every part of the sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter search tool, the description covers the invocation sufficiently: the agent knows what to search and where. However, there is no output schema and no mention of what the search returns, which creates a gap for an agent that needs to interpret results or select matching services to execute.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the query parameter already includes an explanatory description with examples ('pdf', 'crypto', 'vision'). The tool description itself adds no parameter detail beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Search') and a specific resource ('M2MCent Universal Catalog of 1,004+ Agentic Services'), making the tool's function immediately clear. It does not explicitly name the sibling execute_m2mcent_tool, but the search-vs-execute contrast is evident from the sibling's name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no direct comparison to execute_m2mcent_tool. The only usage signal is the phrase 'Search the... Catalog', which implies this tool is for discovery before execution, but that remains an inference rather than stated guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.5
    • First observedexecute_m2mcent_tool
    • First observedsearch_m2mcent_catalog
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one searches the catalog, the other executes a selected service. There is no overlap or ambiguity about which tool to use for a given task.

Naming Consistency5/5

Both tools follow a clear verb_noun pattern with the shared 'm2mcent' prefix (search_m2mcent_catalog, execute_m2mcent_tool). The naming is predictable and consistent despite the slightly different second nouns.

Tool Count5/5

For a gateway SDK exposing a catalog of 1,004+ services, two tools are exactly the right scope: search to discover and execute to invoke. Each tool earns its place, and adding more would overcomplicate the surface.

Completeness5/5

The core lifecycle of discover-then-execute is fully covered. Search returns catalog details, and execute runs the chosen microservice. No obvious gaps exist for the stated purpose of being a thin client to the M2MCent ecosystem.

Maintenance

ActivitySlowing
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers