Loading ToolBench

Reading the current corpus…

x402-shipping MCP server · F · ToolBench

← Browse

x402-shipping

github.com/donnaraising222/x402-shipping

Rate shopping and label generation via Shippo/EasyPost test mode — agents ship things, label returned in-response

2025-06-18+STREAMABLE_HTTP4 tools

47/100

Definition Quality43

Protocol Readiness65

Supportability42

Spec posture

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

Static source inference · medium confidence · evidence: structured output, Streamable HTTP

No deprecated protocol patterns detected

Summary

Server exposes 4 tools via HTTP with mostly complete schemas and descriptions. POST /rates and POST /label have well-structured input schemas with nested objects and proper field descriptions. However, GET /health and GET /.well-known/x402 lack input schemas entirely (GET endpoints with no parameters), and output schemas are not documented for any tool. Descriptions are present but brief (10-50 chars for some). Parameter descriptions are generally good but inconsistent across tools. No error handling guidance, no tool annotations (readOnlyHint/destructiveHint), and no idempotency hints despite POST /label being a destructive write operation.

Tools (4)

GET /.well-known/x402read only33/100

x402 manifest endpoint for payment protocol discovery

GET /healthread only43/100

Health check endpoint returning service status, active provider, test mode status, and payment rails

POST /labelwriteauth50/100

Purchase a shipping label — PDF returned base64 in the response body

POST /ratesread onlyauth50/100

Carrier rate table for a shipment: every service, price and transit time

Issues (5)

HIGHtool ↗

GET /health and GET /.well-known/x402 have no input schemas. GET endpoints should declare empty object schemas or explicitly document that they accept no parameters.

GET /healthGET /.well-known/x402

HIGHtool ↗

No output schemas documented for any tool. LLMs cannot plan downstream calls or extract fields without knowing response structure. POST /rates and POST /label should document their response objects.

POST /ratesPOST /labelGET /healthGET /.well-known/x402

HIGHcommand-tool ↗

POST /label is a destructive write (purchases a label, charges money) but lacks destructiveHint annotation and no confirmation/dry-run pattern. Agents cannot distinguish safe reads from irreversible operations.

POST /label

MEDIUMrecovery-guide ↗

No error handling guidance. Errors return JSON with 'error' and 'message' fields, but LLMs receive no recovery hints (e.g., 'Invalid address format. Ensure street1, city, state, zip, country are provided.').

Recommendations

Add output schemas to all tools. Document POST /rates response (e.g., array of rate objects with rateId, carrier, service, price, transitDays). Document POST /label response (e.g., { labelId, trackingNumber, pdfBase64, payment }).
Add tool annotations: mark POST /rates with readOnlyHint=true; mark POST /label with destructiveHint=true and idempotentHint=false (or add a confirm_purchase parameter for dry-run).
Enhance POST /label description: 'Purchase a shipping label for a quoted rate. Requires a rateId from POST /rates. Charges the specified amount in USDC. Returns a PDF label (base64) and tracking number. This operation is irreversible.'
Add error recovery guidance in tool descriptions or via structured error responses. E.g., 'Invalid address: missing required field. Ensure from.street1, from.city, from.state, from.zip, from.country are provided.'
Document GET /health and GET /.well-known/x402 response schemas. E.g., GET /health returns { ok: boolean, service: string, source: string, testMode: boolean, rails: Array<{rail, network}> }.

Score history

Overall score trend

First recorded score · v2 rubric

47/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	47	2025-06-18+	v2