Loading ToolBench

Reading the current corpus…

bitrouter MCP server · D · ToolBench

bitrouter

An LLM API router with CLI and assembly library. Supports MCP (Model Context Protocol) and ACP (Agent Client Protocol) for routing requests to multiple LLM providers and MCP servers.

2026-07-28+STREAMABLE_HTTP2 tools

55/100

Definition Quality48

Protocol Readiness72

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

BitRouter exposes 2 tools with minimal documentation. tools/list has an empty input schema (no properties defined) and a generic description. tools/call has a basic schema with 2 required parameters (name, arguments) but lacks parameter descriptions and output schema documentation. Neither tool includes error handling guidance, recovery hints, or examples of expected responses. Descriptions are present but fall short of LLM-optimized guidance (10-20 chars vs. baseline 194 chars). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite tools/call being a WRITE operation. This is a proxy/gateway pattern, not a domain-specific tool suite, which limits the depth of guidance possible, but even gateway tools should document their contract clearly.

Tools (2)

tools/callwritesource verified52/100

Execute a tool call against an upstream MCP server

tools/listread onlysource verified43/100

Aggregate tools/list across every configured MCP server to discover available tools

Issues (5)

CRITICALconstrained-input ↗

tools/list input schema is empty (no properties). LLMs cannot infer whether parameters are required or optional.

tools/list

CRITICALtool-description ↗

tools/call parameters 'name' and 'arguments' lack descriptions. LLMs cannot determine what 'arguments' should contain (object shape, required keys, type constraints).

tools/call

HIGHresponse-shaper ↗

No output schema documented for either tool. LLMs cannot plan downstream calls or extract relevant fields. tools/list should document the structure of aggregated tool metadata; tools/call should document success/error response shapes.

tools/listtools/call

HIGHconfirmation-request ↗

tools/call is marked WRITE but has no error handling guidance, confirmation step, or recovery hints. Agents cannot distinguish retryable errors from fatal ones. No dry-run or confirmation pattern.

tools/call

Recommendations

Add parameter descriptions to tools/call: 'name' (string, required) should explain it is the upstream tool name; 'arguments' (object, required) should document expected structure and reference upstream tool schemas.
Document output schemas: tools/list should return {tools: [{name, description, inputSchema, ...}], total_count}; tools/call should return {result, error?, execution_time_ms}.
Add error handling guidance: 'If upstream tool not found, call tools/list first to discover available tools. If execution fails, error response includes upstream error details and retry guidance.'
Implement tool annotations: mark tools/call with destructiveHint=true and tools/list with readOnlyHint=true to guide agent safety policies.
Expand descriptions to 50-150 chars each: tools/list → 'Discover all tools available across configured MCP servers. Call this first to see what upstream tools can be invoked.'; tools/call → 'Execute a tool on an upstream MCP server. Requires tool name and arguments matching the upstream tool schema.'

Score history

Overall score trend

First recorded score · v2 rubric

55/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	55	2026-07-28+	v2