Loading ToolBench
MCP server for generating Coinbase Commerce payment links
This server defines 2 tools with explicit schemas and descriptions. Both tools are properly named with action verbs (create-, get-), and descriptions are present but somewhat generic. Schemas use Zod validation which is visible in the code, but output schemas are not formally documented. Error handling returns structured responses but lacks actionable recovery guidance. Parameters have type constraints and descriptions, which is a strength. However, the server lacks critical context about when to use each tool, prerequisites, and field-level documentation is minimal. The average of the two tools (create-charge: 62, get-charge: 54) yields ~58.
Generate a Coinbase Commerce payment link
Retrieve details of an existing Coinbase Commerce charge
Output schemas not formally documented. Tool descriptions state what the tools return, but no structured schema definition exists for the response objects returned by create-charge and get-charge. LLMs cannot plan downstream operations without knowing the exact fields and types in responses.
Descriptions lack actionable context. Both tools have 1-2 sentence descriptions that state WHAT the tool does but not WHEN to use it or any prerequisites. Description for create-charge should note that a Coinbase Commerce API key is required and should hint at when get-charge would be used to check payment status. Current descriptions are 35-40 chars, below the 10-1024 guideline baseline.
Error responses lack recovery guidance. Both tools catch errors and return isError:true with a message string, but do not guide the LLM on next steps. 'Error creating payment link: ...' tells the agent nothing, should specify whether to retry, check API key, validate inputs, etc. Current error handling is generic catch-all without categorization (retryable vs fatal vs user-fixable).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 14 | - | v1 |
Parameter descriptions are minimal and lack format/constraint details. 'amount' parameter has description 'Payment amount (e.g., "10.00")' which includes an example value that LLMs may reuse literally. Should use formal constraints (e.g., 'numeric string matching pattern /^\d+(\.\d{2})?$/, range 0.01 - 1000000, in the currency's smallest unit'). 'redirectUrl' is optional but no guidance on when to include it.
No pagination or result limiting documented. Neither tool explicitly documents limits on returned data (e.g., get-charge response structure, fields returned). While these are single-object returns, larger future tools should cap results and offer pagination.