Loading ToolBench
MCP bridge that connects to upstream MCP servers and exposes tools via a single codemode tool for orchestration
The server demonstrates strong naming conventions with verb-prefixed tools (sandbox_get_*, sandbox_search_*, sandbox_eval_*) and clear semantic intent. Descriptions are comprehensive and context-aware, especially for discovery and orchestration tools. However, there are notable gaps: sandbox_eval_js lacks explicit documentation of its return type schema and error cases; the sandbox_get_functions pagination model is well-described but output schema is not formally documented; and error handling guidance is minimal across all tools. Tool composition is excellent, the bridge pattern cleanly separates discovery (bridge_status, sandbox_get_functions, sandbox_search_functions), introspection (sandbox_get_function_schema), and execution (sandbox_eval_js) concerns. All tools have input schemas with type constraints and descriptions. The IRREVERSIBLE risk classification on sandbox_eval_js is appropriate but lacks corresponding error recovery guidance in the description.
Return the current status of the codemode bridge, including connected server names and the number of functions each server provides. Use this to see which servers are available before calling sandbox_get_functions.
Execute JavaScript code in a sandbox with access to upstream MCP server tools. Write code that calls upstream tools via the codemode object and returns the result.
Return the TypeScript type definition for a specific function. The output includes the input parameter types, the return type, and JSDoc comments describing each parameter. Use this to determine the exact parameter names, types, and which parameters are required before writing code for sandbox_eval_js. Pass the function name exactly as returned by sandbox_get_functions or sandbox_search_functions (for example, server_name__function_name).
List available functions grouped by server. Each entry includes the function name and its description. Use the returned name value as the property name on the codemode object when writing code for sandbox_eval_js, and as the tool_name argument when calling sandbox_get_function_schema. Function names follow the pattern serverName__functionName, where a double underscore separates the server namespace from the original function name. For example, a function called list_items on a server named inventory becomes inventory__list_items. Results are paginated. The first call returns the first page. If the response includes a nextCursor value, pass it as the cursor parameter to retrieve the next page.
sandbox_eval_js lacks documented output schema. Description states 'returns the result' but does not specify whether result is JSON, raw JavaScript value, serialized string, or wrapped object. LLMs cannot plan downstream tool calls without knowing the return type structure.
sandbox_eval_js description does not explain error modes or recovery paths. A tool classified as IRREVERSIBLE but with vague error handling (no mention of rollback, compensation, or retry guidance) violates the error-handling pattern. LLMs need guidance: if execution fails, what can they do?
sandbox_get_functions pagination output schema not formally documented. The description mentions 'nextCursor value' but does not document the full response structure (field names, types, example cursor format). Without this, LLMs cannot confidently construct follow-up cursor queries.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Keyword-search the tool index to find functions matching a query. Returns a list of matching functions sorted by relevance, with their TypeScript type definitions included.
No input validation or constraint violations are documented. The schema for sandbox_get_functions specifies 'pageSize must be between 1 and 200' but does not describe what error LLMs should expect if they violate this constraint, or how to recover. Schema alone is insufficient for LLM guidance.
sandbox_eval_js accepts raw JavaScript code with implicit access to 'codemode' object but does not document sandboxing boundaries, timeout limits, or memory constraints. An LLM could accidentally write infinite loops or memory-exhausting code without knowing the execution environment limits.