Loading ToolBench
Local MCP gateway: manage all your MCP servers in one place, set up once and shared by every AI client, with ~90% fewer tokens per request
Toolport is a mock MCP server intended for testing and demonstration. While all 10 tools have names and brief descriptions, the definition quality is poor across most dimensions. Tool descriptions are extremely terse (6-56 characters), well below the 10-1024 character baseline. Input schemas are present but minimal, most tools lack parameter descriptions entirely. No output schemas are documented. Error handling is absent. The tool set mixes legitimate test utilities (echo, add, pwd, greet) with dangerous operations (die, grow) that would never pass security review in production. Tools like 'legacy_elicitation' and 'mrtr_confirm' test deprecated protocol features. The server appears designed for integration testing of MCP gateways rather than production agent use.
Add two numbers a and b.
Exit the process to simulate a mid-session crash.
Echo back the text argument.
Return the request's params._meta verbatim.
Greet someone by name.
Add a new tool and announce tools/list_changed.
Issue a legacy server-to-client elicitation request.
All tool descriptions are critically short (6-56 chars), far below the 10-1024 baseline. Descriptions like 'Return the process working directory.' and 'Exit the process to simulate a mid-session crash.' lack guidance on WHEN to use the tool or WHAT downstream actions depend on its output. LLMs cannot reliably select tools based on vague descriptions.
No input parameter descriptions. Tools 'echo', 'add', 'greet' have schema properties (text, a, b, name) with types but no descriptions explaining what value to pass or constraints on format/range. The 'name' parameter in 'greet' accepts any string with no guidance on expected format.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
Require one elicitation round before replying.
Emit notifications/progress, then reply.
Return the process working directory.
No output schemas documented for any tool. LLMs have no visibility into what fields are returned. This violates the baseline that 100% of A-grade tools have documented return types. Agent implementations must guess the shape of responses.
Tool 'die' is destructive (exits the process) and tool 'grow' modifies state, but neither is marked with destructiveHint or idempotentHint annotations. Agents have no signal that these operations are unsafe or require confirmation.
Tools 'mrtr_confirm' and 'legacy_elicitation' explicitly test deprecated protocol features. 'legacy_elicitation' appears to test server-initiated elicitation (deprecated/removed in current spec), and 'mrtr_confirm' tests Multi-Round-Trip Requests. These should not be advertised in production tool definitions.
No error handling guidance. Tools have no documented error cases, retryability hints, or recovery paths. If a tool fails, an agent has no actionable direction on what to try next.
Naming inconsistency: 'echo_meta' uses snake_case, but 'mrtr_confirm' and 'legacy_elicitation' use full words instead of verb_noun pattern. 'mrtr_confirm' should be 'confirm_mrtr' or 'request_confirmation'. Inconsistent naming increases agent confusion when selecting tools.