Loading ToolBench
Jev-powered MCP tool router for Codex that routes agent requests to external MCP tools using AI-driven semantic matching
Strong tool naming and descriptions across all 9 tools. All tools have explicit input schemas with Zod validation and type constraints. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present and correct. However, several parameter descriptions are minimal or missing entirely (e.g., 'server' and 'tool' in get_tool_schema lack descriptions), and output schemas are not formally documented, responses return structuredContent but the shape is not declared. Error handling is present but recovery guidance is sparse. Composition is excellent: tools are single-responsibility and chain well (find_tool → get_tool_schema → call_tool). Naming follows verb_noun convention consistently.
Execute a routed external MCP tool that is explicitly annotated read-only. Prefer this after find_tool for read-only tools because it does not request mutation approval. The router refuses to run a tool here unless its upstream readOnlyHint is true.
Execute a routed external MCP tool after find_tool/get_tool_schema. If the upstream call fails, this returns fallbackRequired=true with a compact alternative shortlist and search guidance. If the call succeeds but the result is semantically wrong for the task, use search_tools or list_tools before list_all_tools.
Evaluate completed or in-progress work with Jev. Use when the user says "valuta con Jev", "fai valutare il lavoro a Jev", or asks Jev to judge whether work matches the brief.
Use this FIRST whenever you need an external MCP capability and do not already have the exact routed tool. Jev compares the agent request against every routed tool name + description. If the winning probability reaches the configured threshold, only that tool and its full input schema are returned. Otherwise the router returns a compact ranked shortlist and discovery guidance instead of dumping the full inventory.
Get the full input schema for one routed tool after find_tool/search_tools/list_tools or when the exact tool is already known.
Parameter descriptions missing or minimal in get_tool_schema, list_servers, list_tools, list_all_tools. 'server' and 'tool' params lack descriptions explaining what they accept or how to obtain them.
Output schemas not formally documented. Tools return structuredContent but the shape, field types, and required fields are not declared. LLMs cannot plan downstream calls without knowing response structure.
Error recovery guidance sparse. Tools like call_tool mention 'fallbackRequired=true' and 'alternative shortlist' but do not document error categories (retryable vs user-fixable vs fatal) or explicit next-step instructions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Explicit last-resort full routed-tool inventory. Prefer find_tool, search_tools, list_servers, and paginated list_tools first. This can be large.
List routed MCP server names in bounded pages with compact tool counts and availability. Use this to narrow discovery before listing tools from one server.
List routed tools in bounded pages, optionally restricted to one MCP server. Prefer this over list_all_tools when search_tools is insufficient.
Search routed external tools with a compact deterministic lexical/BM25 ranking. Use this after a fallback_shortlist when the first shortlist is unclear, or whenever you want targeted discovery without exposing the full inventory.
evaluate_work_with_jev description references Italian phrases ('valuta con Jev', 'fai valutare il lavoro a Jev') without explaining the tool's purpose in English or clarifying when to use it vs other discovery tools.
Pagination tools (list_servers, list_tools) do not document total count or next_cursor in response. LLMs cannot determine if more results exist or how to fetch them without seeing the actual response structure.