Loading ToolBench
Multi-catalog MCP server system with pluggable tool extensions and weather/horoscope integrations
This MCP server has critical structural issues that severely limit production readiness. The server exposes 6 tools, but there is significant evidence of duplication, incomplete schemas, and vague descriptions. Tool naming follows action-verb convention adequately (record_*, deliver, next_pending), but descriptions are extremely sparse and many lack actionable context. Most critically: (1) `record_plug_attempt` appears TWICE with identical names but different descriptions/files, indicating either a cataloging error or unresolved tool duplication, agents cannot disambiguate duplicate names. (2) Three tools (record_plug_attempt x2, record_plug_success, record_plug_failure) appear to serve internal state-tracking rather than user-facing operations, suggesting this server may be an internal utility rather than a proper MCP interface. (3) Only 2 of 6 tools have input schemas visible; the other 4 lack documented schemas entirely. (4) Descriptions are uniformly terse (12-80 chars), below the 50-200 char baseline for LLM optimization. (5) No output schemas documented. (6) No error handling guidance. (7) No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite the Risk field being provided. The codebase appears to be a monorepo for a Cloudflare Workers-based application (wrangler, vitest, tsx), not a polished MCP server. The STDIO transport constraint further limits deployment.
Deliver horoscope result idempotently to the block by order_id
Drain the queue and retrieve the next pending horoscope order from the block
Record the attempt timestamp before any owner-config or upstream read in the horoscope plug
Record the attempt timestamp before weather data fetch
Record weather plug failure with error message and details
Record successful weather data push to the block with current, daily, timeseries, and config state
Duplicate tool names: 'record_plug_attempt' registered twice with different descriptions and file paths. Agents cannot differentiate between the horoscope and weather variants. This violates single-responsibility principle and creates ambiguity in tool selection.
Missing input schemas: next_pending has no documented input schema visible in source. Tools with undocumented inputs prevent LLMs from understanding required/optional parameters and expected types.
Descriptions universally terse and generic: All 6 tools have descriptions under 90 characters, well below the 50-200 char baseline for LLM optimization. Examples: 'Drain the queue and retrieve the next pending horoscope order from the block' (80 chars) lacks context on when to call it, what 'block' means, or prerequisites. Descriptions must answer WHAT, WHEN, and WHY.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
No output schemas documented: Tools return structured data (e.g., deliver accepts order_id + result; record_plug_success returns snapshot objects) but output schemas are not visible in the server definition. LLMs cannot plan downstream calls without knowing return field names and types.
No tool annotations despite Risk markings: The server metadata lists Risk (READ_ONLY, WRITE) for each tool, but no readOnlyHint, destructiveHint, or idempotentHint annotations appear in the source. Agents cannot determine whether calls are safe to retry without explicit annotations.
Internal-facing utility tools masquerading as user-facing MCP interface: Tools like record_plug_attempt, record_plug_success, record_plug_failure appear to be internal state-tracking callbacks for a horoscope/weather system, not user-initiated operations. An MCP server should expose composable, user-facing actions. These tools suggest the server is a callback handler, not a proper agent interface.
Parameter descriptions incomplete or missing: Several parameters (e.g., 'timestamp' in record_plug_attempt, 'snapshot' in record_plug_success) lack actionable context. 'Unix timestamp in milliseconds' is present but does not explain the business meaning. LLMs need to know WHAT the field controls, not just the format.
No error handling guidance: No error responses documented. Tools do not indicate what errors can occur, how to recover, or whether calls are retryable. Agents will be left guessing if a timeout is transient or fatal.