Loading ToolBench
A Model Context Protocol meta-server for TypeScript scripting across multiple MCPs
Two tools are defined with explicit schemas and descriptions, but both have significant quality gaps. Tool naming is non-standard (hyphenated, not verb_noun convention). Descriptions are minimal and lack actionable guidance. Parameter descriptions are absent or trivial. Output schemas are completely undocumented. Error handling provides some guidance but lacks structured categorization. The tool design conflates multiple responsibilities (spec generation and script execution) rather than following single-responsibility patterns. No input validation or constraint enforcement visible. Security concerns: run-script accepts arbitrary TypeScript code without sandboxing, audit logging, or permission gates, a critical vulnerability in a production MCP server.
Get TypeScript definitions for all available tools from configured MCP servers
Execute a TypeScript script with access to all configured MCP tools
Non-standard tool naming: 'get-spec' and 'run-script' use hyphens instead of underscores (get_spec, run_script). Worse, 'run-script' does not follow verb_noun convention, 'execute_script' or 'evaluate_typescript' would be clearer. LLMs parse tool names before descriptions to infer intent; hyphenated names are harder to parse and non-idiomatic in agent tool patterns.
Missing parameter descriptions. The 'script' parameter in run-script has only a brief type description ('TypeScript code that...') but lacks critical guidance: What runtime environment? What global functions/objects are available? How are errors reported? What is the timeout? LLMs cannot infer these from the type alone.
Output schemas completely undocumented. Neither tool documents what fields or structure it returns. get-spec returns 'TypeScript definitions' (unstructured text?). run-script returns 'JSON.stringify(result)' (what structure?). Without output schema documentation, LLMs cannot plan downstream operations or extract data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Critical security vulnerability: run-script accepts and executes arbitrary TypeScript code with no sandboxing, permission gates, audit logging, or confirmation. This allows any LLM or user to execute arbitrary code on the server with no controls. Production MCP servers must gate destructive/sensitive operations behind permission checks and audit trails.
Overly broad tool responsibility: run-script combines code execution, MCP client invocation, and result serialization in one tool. This violates single-responsibility principle. Users cannot call tools directly without embedding them in TypeScript. Better design: expose underlying MCP tools directly to the LLM, and provide run-script only for complex multi-step workflows.
No input validation or constraint documentation. run-script accepts any string and attempts to compile/execute it. No timeout specification, no memory limit, no allowlist/denylist of dangerous APIs. Error messages are generic ('Script execution failed') rather than actionable. Should validate syntax early and return clear diagnostics.
get-spec tool description is vague about its output format and use case. 'Get TypeScript definitions' does not explain: Are these type definitions, function signatures, or full interface docs? Should the LLM parse this output and call tools, or just display it to the user? Ambiguous descriptions cause wrong tool selection.
Error handling lacks structured recovery guidance. Errors describe what went wrong but not what to do next. For run-script, 'TypeScript compilation errors' should suggest 'Check syntax using get-spec' or 'Validate tool argument types against the generated spec'. For get-spec, 'configured MCP servers are running' should suggest how to debug connection issues.
No support for confirmation or dry-run patterns. run-script executes code immediately with no option to preview or approve. LLMs make mistakes, a confirm_before_execute pattern would prevent catastrophic errors like accidental deletion or side effects.
Incomplete error categorization. Errors are returned as isError=true with unstructured text. No distinction between retryable (network timeouts), user-fixable (bad TypeScript syntax), or fatal errors (permission denied). LLMs should know what to do next; raw error text leaves them guessing.