Loading ToolBench
CLI bridge that wraps MCP servers as bash-invokable commands, recovering ~11K tokens of context window per session
mcp2cli is a CLI bridge that wraps MCP servers as bash commands. The 5 test fixture tools have reasonable naming (verb-based: echo_env, json_tool, error_tool, create_item, slow_tool) and descriptions, but schema quality varies significantly. All tools have descriptions (10-80 chars, within acceptable range), but input schemas lack parameter descriptions in most cases, violating the critical rule that every parameter needs a description. The create_item tool has the most complete schema with typed enums and descriptions. Output schemas are not documented. Error handling is basic (error_tool exists for testing but no recovery guidance). No evidence of idempotency hints, permission gating, or audit trails. Security model unclear, unclear how credentials are handled for backend MCP servers.
Create a new item with the given name and type
Echoes back the server's env and argv
Always returns an error (for testing)
Returns a JSON object with status and data fields
A tool that takes a long time to respond
Parameter descriptions missing or insufficient. json_tool has 'filter' and 'limit' parameters with generic descriptions ('Optional filter expression', 'Maximum results to return') that do not explain constraints, format, or when to use them. slow_tool's 'delay_ms' lacks context on minimum/maximum delays or timeout expectations.
Output schemas not documented. None of the 5 tools declare what fields they return or what structure the LLM should expect. This violates the critical rule that 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' Without documented returns, agents cannot chain tools effectively.
No pagination support documented. json_tool accepts 'limit' but no 'offset', 'page', or 'cursor' parameters, and does not document return structure or total count. This risks context window exhaustion if results grow large.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
Error handling lacks recovery guidance. error_tool is defined but test fixtures show no context on what causes errors, what the error response structure is, or what the LLM should do next. Agents need 'try search_users() first' type hints, not raw error codes.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in schema. Risk levels are declared in the server metadata (READ_ONLY, WRITE) but not attached to the tool schemas themselves, limiting the MCP client's ability to warn agents about destructive operations.
Naming could be more specific. slow_tool is generic and does not convey purpose clearly. Better names: wait_for_delay, simulate_slow_response, or test_timeout_handling. Generic names force LLMs to read descriptions; specific verb_noun names let LLMs select by name alone.