Loading ToolBench
Configurable MCPorter bridge extension for pi and Model Context Protocol (MCP) servers.
The mcporter tool is a proxy/gateway tool that forwards calls to downstream MCP servers. While the input schema is well-structured with proper types and enums, the tool itself has fundamental design issues. The description is adequate (137 chars) but doesn't follow LLM-optimized guidance. Critically, this is a meta-tool that wraps other tools rather than implementing domain-specific capabilities. The schema is visible and typed, but the composition pattern (a single tool with action enum) violates the single-responsibility principle. The tool lacks clear error recovery guidance, timeout management details, and security considerations around parameter passing to untrusted downstream servers.
Discover and call MCP tools through MCPorter using one stable proxy tool. When a selector is unknown, use action='search' with an MCP server name or a capability phrase; known server names remain discoverable when authentication or connectivity prevents tool listing. Server names are not callable selectors: choose a returned server.tool value, use action='describe' for its schema, then action='call'. If you already know the selector and arguments, use action='call' directly. Output is truncated to 100 lines or 8.0 KB and saved to a temp file when truncated.
Tool naming violates verb_noun convention. 'mcporter' is a product name, not an action verb. Naming should reflect the primary action: 'call_mcp_tool', 'search_mcp_tools', or 'proxy_mcp_call'. LLMs cannot infer intent from 'mcporter' alone.
Single tool with action enum combining search, describe, and call violates single-responsibility principle (pattern:tool). This forces the LLM to reason about three distinct operations within one tool invocation. Should be split into search_mcp_tools, describe_mcp_tool, and call_mcp_tool.
Parameter descriptions are minimal and lack format constraints. 'selector' description is 'The MCP tool selector in format 'server.tool'' but provides no guidance on discovering valid selectors, what happens if the format is wrong, or examples. 'query' lacks guidance on search syntax. Violates pattern:tool-description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No documented output schema. The description mentions 'Output is truncated to 100 lines or 8.0 KB and saved to a temp file when truncated' but the actual response structure (field names, types, pagination) is not specified. LLMs cannot plan downstream operations without knowing the output schema.
Error handling provides no recovery guidance. No documentation of what errors are retryable, what indicates user input is needed (e.g., invalid selector format), or what to do if a downstream server is unreachable. Violates pattern:recovery-guide.
Security risk: 'args' parameter is an untyped object that gets passed directly to downstream MCP tools. No validation, sanitization, or injection prevention documented. This is a tool-gateway vulnerability, all downstream parameters flow through unvetted. Violates pattern:tool-gateway.
timeoutMs parameter lacks constraints. No min/max bounds, no guidance on reasonable values, no documentation of what happens on timeout (retry-safe? partial results?). Unbounded numbers allow LLMs to pass absurd values (e.g., 999999999ms).
limit parameter for search action is a bare number with no min/max bounds. No guidance on impact of large limits (token cost, API load, timeout risk). Should have explicit constraints (1-100) and describe trade-offs.
Tool composition is backwards. Instead of one proxy tool, design a discovery mechanism (list available servers) and let agents directly call downstream MCP tools via standard tool registration. The current pattern adds an indirection layer that wastes tokens and increases error surface area.