Loading ToolBench
The server defines 2 tools with significant quality gaps. The 'execute' tool has a CRITICAL SECURITY ISSUE (accepts and runs arbitrary code), lacks proper error guidance, and its description is overly verbose (500+ chars) with embedded code examples. The 'search_docs' tool is simpler but both tools have incomplete or missing output schema documentation. Parameter descriptions exist but are generic. Neither tool follows idempotent or clear naming conventions. The execute tool represents a WRITE risk that requires confirmation patterns and dry-run support, which are absent. Overall, this server would not pass production code review due to security and schema documentation gaps.
Runs JavaScript code to interact with the Scan Documents API. You are a skilled TypeScript programmer writing code to interface with the service. Define an async function named "run" that takes a single parameter of an initialized SDK client and it will be run. For example: ``` async function run(client) { const file = await client.files.upload({ file: fs.createReadStream('path/to/file'), name: 'REPLACE_ME' }); } ``` You will be returned anything that your function returns, plus the results of any console.log statements. Do not add try-catch blocks for single API calls. The tool will handle errors for you. Do not add comments unless necessary for generating better code. Code will run in a container, and cannot interact with the network outside of the given SDK client. Variables will not persist between calls, so make sure to return or log any data you might need later. Remember that you are writing TypeScript code, so you need to be careful with your types. Always type dynamic key-value stores explicitly as Record<string, YourValueType> instead of {}.
Search SDK documentation to find methods, parameters, and usage examples for interacting with the API. Use this before writing code when you need to discover the right approach.
CRITICAL SECURITY: 'execute' tool accepts and runs arbitrary JavaScript code without confirmation, dry-run, or sandboxing verification visible in schema. No confirmation_required pattern, no explicit output format validation, no rate limiting visible. This is a code-injection risk vector.
Tool 'execute' description is 500+ characters with embedded code examples. Rubric baseline is 194 chars; descriptions >1024 waste tokens and bury key details. Example values in descriptions (fs.createReadStream, file.upload) risk LLM literal reuse. Violates pattern:tool-description and mxe:response-field-naming.
No output schema documented for either tool. Rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' Pattern:tool and pattern:response-shaper require this. Without it, LLMs cannot predict what they'll receive or compose subsequent calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 58 | - | v1 |
'execute' tool naming lacks action verb clarity. 'execute' is generic; LLMs cannot distinguish it from 'run_code', 'eval_code', etc. Baseline: 90% of A+ tools start with specific action verb like 'run_', 'search_', 'get_'. Name should be 'run_code_against_api' or 'call_api_with_code' to make intent explicit.
Parameter 'intent' in 'execute' tool lacks validation constraints. Description says 'Used for improving the service' but does not specify format, length, enum, or whether it's required. No guidance on what constitutes a valid intent. Violates pattern:constrained-input.
Error handling for 'execute' tool undefined in visible schema. Code-execution tools MUST include explicit error categorization (retryable vs fatal) and recovery guidance. Rubric: 'Error responses must tell the LLM what to do next.' No visible timeout, sandbox-escape, or execution-failure handling.
No idempotency guarantees visible. 'execute' runs code each time called, if an LLM retries on ambiguous failure, code runs twice, risking duplicate side effects (duplicate API calls, duplicate resource creation). Violates pattern:idempotent-operation. Requires idempotentHint or explicit idempotency semantics.
search_docs 'language' parameter enum is large (9 values: http, python, go, typescript, javascript, terraform, ruby, java, kotlin) with no description of why these are the only options or what determines valid values. No guidance on default behavior if not specified.