Loading ToolBench
MCP server for Mercury — 17 keyless, signed-provenance web-data tools your AI agent can pay for itself over x402 (Base mainnet, USDC). No API key, no account.
Mercury x402 MCP has two explicitly registered tools with visible schemas in index.mjs. mercury_catalog has an empty input schema (no parameters) and a generic 20-char description. mercury_verify has a minimal schema with only 'attestation' required and 'text' optional, but lacks parameter descriptions entirely. Neither tool description explains WHEN to use them, WHAT they return, or dependencies. No output schemas documented. Error handling is minimal (generic catch blocks). Overall definition quality is poor: descriptions are too short, parameter docs are absent, and output structure is undocumented.
List every Mercury service + price (free, no payment).
Verify a Mercury signed provenance receipt offline (free).
Parameter descriptions completely missing. mercury_verify has 'text' and 'attestation' parameters with no descriptions explaining what they are, their format, or constraints. LLMs cannot infer parameter meaning from names alone.
Tool descriptions are too short (20 chars for mercury_catalog, ~15 for mercury_verify) and lack context. They do not explain WHEN to use each tool, WHAT it returns, or dependencies. Descriptions should be 50-200 chars and answer: what does it do, when should I call it, what does it return?
No output schemas documented. LLMs need to know what fields to expect from tool responses so they can plan downstream calls and extract data. mercury_catalog returns a JSON object of services; mercury_verify returns a verification result, neither is formally documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Error handling is generic and non-actionable. Catch blocks return 'Mercury tool error: <message>' without guidance on what the LLM should do next (retry, ask user, abort). Errors should categorize as retryable/user-fixable/fatal and suggest recovery steps.
Dynamically built paid tools (from /catalog) are inferred, not explicitly visible in source code. These tools lack explicit schema registration and descriptions in the codebase.