Loading ToolBench

Reading the current corpus…

mcp-pay MCP server · F · ToolBench

mcp-pay

Payment awareness layer for MCP: reference server with payment-gated tools demonstrating HTTP 402 payment flow with x402 protocol

<=2025-11-25STREAMABLE_HTTP2 tools

46/100

Definition Quality38

Protocol Readiness59

Supportability49

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Critical gaps in tool definitions. Both tools have minimal descriptions (under 50 chars) and lack documented input/output schemas in the visible source. Tool names are verb-based (get_weather, get_forecast) but descriptions are trivial marketing copy ('Get current weather (FREE)', 'Get weather forecast (PAID) - 7-day weather forecast'). No parameter descriptions visible beyond bare type declarations. No output schema documentation. No error handling guidance. The codebase shows schema infrastructure (schemars, jsonschema) but tool definitions are not materialized in the provided source excerpts.

Tools (2)

get_forecastread onlyauthsource verified38/100

Get weather forecast (PAID) - 7-day weather forecast

get_weatherread onlysource verified38/100

Get current weather (FREE)

Issues (5)

CRITICALtool-description ↗

Tool descriptions are marketing copy, not LLM-optimized. 'Get current weather (FREE)' and 'Get weather forecast (PAID) - 7-day weather forecast' are under 50 chars and lack context for when/why to call them. Baseline: A+ tools average 194 chars with clear WHAT/WHEN/RETURN guidance.

get_weatherget_forecast

CRITICALtool-description ↗

No parameter descriptions visible. The 'city' parameter in both tools has only a type ('string') and a bare description ('City name for weather query'). Missing: expected format, examples of valid cities, whether it accepts coordinates, whether it's required, what happens if invalid.

get_weatherget_forecast

CRITICALtool ↗

No output schema documented. Tools return weather data but the response structure is not visible in source. LLMs cannot plan downstream calls or extract fields without knowing what fields exist, their types, and their meaning.

get_weatherget_forecast

Recommendations

Expand tool descriptions to 100-200 chars. Example for get_weather: 'Fetch current weather conditions for a city (temperature, humidity, wind, precipitation). Free tier: 100 calls/day. Returns structured weather object with current conditions and 3-hour forecast window.'
Add parameter descriptions with constraints. For 'city': 'City name (e.g. London, New York). Accepts city name or city,country code (e.g. London,UK). Required. If not found, returns available matches.'
Document output schema explicitly. Define fields returned: temperature (number, Celsius), humidity (0-100), wind_speed (m/s), condition (enum: sunny, cloudy, rainy, snowy), timestamp (ISO 8601).
Add error handling guidance in descriptions. E.g. 'If city not found, the tool returns a 404 with available alternatives. Retry with a different spelling or use search_cities() first.'
Implement tool annotations (readOnlyHint: true for both, idempotentHint: true for both) and cost metadata in the MCP tool registration to signal pricing and safety to agents.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

46/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	46	<=2025-11-25	v2