Loading ToolBench

Reading the current corpus…

x402-mcp-commerce MCP server · D · ToolBench

x402-mcp-commerce

MCP server that gives Claude/GPT agents commerce tools — each tool call pays an upstream x402 endpoint and returns its artifact

2025-06-18+STDIO4 tools

50/100

Definition Quality50

Protocol Readiness50

SupportabilityNot measured-

Spec posture

Inferred effective spec 2025-06-18+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: structured output

No deprecated protocol patterns detected

Summary

Server exposes 4 tools with mixed quality. Three tools (list_commerce_tools, spending_report, discover_service) have good descriptions but ZERO input schemas visible in source. dynamic_commerce_tools has a schema but vague description. No parameter descriptions provided for any tool. Tool names are reasonable but lack verb-noun clarity. Output schemas undocumented. Error handling present in HTTP layer (src/server.ts) but not reflected in tool definitions.

Tools (4)

discover_serviceread onlysource verified55/100

Read any x402 service's /.well-known/x402 manifest to learn its routes, prices, payment rails, and response schemas. Free — no payment is made.

dynamic_commerce_toolswrite50/100

Dynamically registered tools from config/tools.json. Each tool calls an upstream x402 endpoint, pays for it, and returns the artifact with payment receipt.

list_commerce_toolsread onlysource verified48/100

List every commerce tool this server exposes, with its upstream service, price, and configured payment rail. Free — no payment is made.

spending_reportread onlysource verified48/100

Show this agent's spending caps, how much it has spent so far, and every payment it has made in this session. Free — no payment is made.

Issues (5)

CRITICALtool ↗

Three tools (list_commerce_tools, spending_report, discover_service) have NO visible input schemas in source code.

list_commerce_toolsspending_reportdiscover_service

CRITICALtool-description ↗

No parameter descriptions provided for any tool. The 'rail' parameter in dynamic_commerce_tools has enum values but no description explaining what 'auto' means or when to override the default.

dynamic_commerce_tools

HIGHresponse-shaper ↗

Output schemas are not documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., payment receipt structure, tool registry format) without knowing response shape.

list_commerce_toolsspending_reportdiscover_servicedynamic_commerce_tools

MEDIUMtool ↗

Tool name 'dynamic_commerce_tools' is vague and does not follow verb_noun convention. Does it list, create, call, or register tools? Rename to 'call_commerce_tool' or 'invoke_upstream_service' for clarity.

Recommendations

Add explicit JSON Schema input definitions for list_commerce_tools and spending_report (both accept empty objects {}; formalize this in schema).
Document output schemas for all tools. Example: list_commerce_tools returns {tools: [{name, upstream, price, rail, description}], total_count}. Agents need this to extract tool names and prices.
Add descriptions to the 'baseUrl' parameter in discover_service: 'Origin of the x402 service (e.g., https://tablebook.example.com). Must be HTTPS.'
Add descriptions to the 'rail' parameter in dynamic_commerce_tools: 'Payment rail for this call. auto = use the first available key (base or solana). Overrides the configured default rail.'
Rename 'dynamic_commerce_tools' to 'call_upstream_service' or 'invoke_commerce_tool' to clarify that it invokes a single upstream endpoint, not manages multiple tools.

Score history

Overall score trend

First recorded score · v2 rubric

50/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	50	2025-06-18+	v2