Loading ToolBench
MCP server for WHO ICD-11 API integration with Code Mode execution, GraphQL/SPARQL support, and API catalog search
This server exposes 5 tools with significant definition gaps. Tool names lack clear action verbs (catalog_search, execute, graphql_execute, sparql_execute, search are generic). Descriptions are present but verbose and lack LLM-optimized structure. Input schemas are visible but incomplete: parameters lack type constraints (enums, min/max), and output schemas are entirely undocumented. The execute/graphql_execute/sparql_execute tools accept arbitrary JavaScript code, which is a security red flag without clear sandboxing guarantees or error recovery guidance. No tool declares idempotency, destructiveness, or permission requirements. Error handling is absent from descriptions.
Search the API catalog (endpoints). Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling execute. Categories: (dynamic based on catalog) USAGE IN execute: - api.get(path, params) for GET, api.post(path, body, params) for POST - Path params like /lookup/{id} are auto-interpolated from params: api.get('/lookup/{id}', {id: 'ENSG...'}) - Remaining params become query string - Large responses (>100KB) are auto-staged: check result.__staged, return the staging info, use query_data to explore - Use limit/pagination params to control response size. Large datasets auto-stage for SQL queries.
Execute JavaScript code against the API with sandboxed V8 isolate. Code runs with api.get/api.post wrappers, catalog search helpers (searchSpec, listCategories, getEndpoint), and console.log() capture. Large responses (>100KB) are auto-staged into SQLite for querying.
Execute JavaScript code against a GraphQL endpoint with sandboxed V8 isolate. Code runs with gql.query(queryString, variables?), schema introspection helpers (schema.types(), schema.type(), schema.search()), and optional REST API support (api.get/api.post). Large responses are auto-staged into SQLite.
Search the OpenAPI spec (operations across paths). Write JavaScript code to search the OpenAPI spec, or use legacy query/category arguments for keyword search. Available functions: searchPaths(query, maxResults=10), listTags(), getOperation(idOrPath), describeOperation(idOrPath), spec object access.
Execute JavaScript code against a SPARQL endpoint with sandboxed V8 isolate. Code runs with sparql.query(queryString, opts?), sparql.ask(queryString), sparql.raw(queryString, opts?), common ontology prefixes, and optional filesystem access. Large responses are auto-staged into SQLite.
Tool names lack action verbs. 'execute', 'search', 'catalog_search' are generic and do not clearly signal intent. Should be 'execute_rest_api', 'search_catalog', 'search_openapi_spec' to disambiguate.
Input schemas lack type constraints. 'max_results' is a number with no min/max bounds; 'query' is a free-form string with no enum or pattern. LLMs will pass invalid values (negative limits, empty queries).
Output schemas are completely undocumented. Tools return results but descriptions do not specify field names, types, or structure. LLMs cannot plan downstream calls or extract data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | 2026-07-28+ | v2 |
Code execution tools (execute, graphql_execute, sparql_execute) accept arbitrary JavaScript without documented sandboxing guarantees, error recovery, or timeout behavior. Descriptions claim 'sandboxed V8 isolate' but provide no error handling guidance or limits.
No tool declares destructiveness, idempotency, or permission requirements. Agents cannot determine which calls are safe to retry or require confirmation. Missing tool annotations.