Loading ToolBench
MCP server for executing code against APIs with support for REST, GraphQL, and SPARQL endpoints. Provides Code Mode execution with sandboxed V8 isolates, auto-staging of large responses, and schema discovery.
Five tools with generally clear naming and descriptions, but significant gaps in schema visibility and parameter documentation. Tool names follow verb_noun pattern (catalog_search, execute, search, graphql_execute, sparql_execute). Descriptions are substantial (150-300+ chars) and explain purpose and usage context. However, input schemas are partially visible in source, only catalog_search shows complete Zod schema with typed parameters and descriptions. Other tools (execute, search, graphql_execute, sparql_execute) have descriptions but their actual schema definitions are not shown in the provided code excerpt. Output schemas are undocumented across all tools. Error handling guidance is absent. The codebase appears to be a shared library with tool implementations split across files, but critical schema registration code is not visible.
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. Code runs in a sandboxed V8 isolate with: - api.get(path, params) / api.post(path, body, params) — HTTP calls routed through host - searchSpec(query) — search the API catalog - listCategories() — list endpoint categories - getEndpoint(path) — get full endpoint docs - console.log() capture - Auto-staging of large responses (>30KB) into SQLite with db.queryStaged() access - Optional workspace parameter for shared cross-server staging (ADR-006 Phase 0)
Execute JavaScript code against a GraphQL endpoint. Code runs in a sandboxed V8 isolate with: - gql.query(queryString, variables?) — GraphQL execution through host - schema.types(), schema.type(), schema.search() etc. — introspection helpers - db.stage(), db.queryStaged(), api.query() — staging helpers - console.log() capture - Optional REST API capability (api.get/api.post) when restApiFetch is configured - Auto-staging of large responses (>30KB) into SQLite
Search the API spec (OpenAPI mode). Write JavaScript code to search the OpenAPI spec, or use the legacy query/category arguments for keyword search. Available functions: - searchPaths(query, maxResults=10) — keyword search across paths, summaries, tags, parameters - listTags() — list all tags with operation counts - getOperation(idOrPath) — get full operation by operationId or path - describeOperation(idOrPath) — formatted documentation for an operation - searchSpec/query helpers are also available for backward compatibility inside execute() - spec — the full frozen OpenAPI spec object (spec.paths, spec.info, etc.) Use search to discover endpoints, then write code in execute to call them.
Input schemas not visible for 4 of 5 tools (execute, search, graphql_execute, sparql_execute). Only catalog_search shows complete Zod schema with typed parameters. Cannot verify parameter types, constraints, or descriptions for majority of tools.
Output schemas completely undocumented across all tools. Tool descriptions mention return behavior (e.g., 'returns array of plain { variable: value } rows' for sparql_execute) but no formal schema definition provided. LLMs cannot reliably parse or chain results.
No error handling guidance in any tool description. Tools accept arbitrary JavaScript code (execute, graphql_execute, sparql_execute) but provide no recovery hints for common failures (syntax errors, timeout, API unavailable, invalid query).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
Execute JavaScript code against a SPARQL endpoint. Code runs in a sandboxed V8 isolate with: - sparql.query(queryString, opts?) — run SELECT/CONSTRUCT/DESCRIBE; returns array of plain { variable: value } rows - sparql.ask(queryString) — run ASK; returns boolean - sparql.raw(queryString, opts?) — return unparsed { head, results } envelope - prefixes — object of common ontology prefixes (rdfs, owl, xsd, skos, dcterms, void, obo, uberon, go, ncbigene, efo, obi, sio, up, ensembl, bgee) - prefixHeader — pre-built `PREFIX …` block to prepend to your queries - console logging (log, warn, error, info) — captured output - Auto-staging of large responses (>30KB) into SQLite - Optional virtual filesystem (fs.readFile / fs.writeFile / fs.glob) when fsDoNamespace is configured
Code execution tools (execute, graphql_execute, sparql_execute) accept arbitrary JavaScript without documented sandbox constraints, timeout limits, or resource quotas. Security model and failure modes are opaque.
Parameter descriptions in tool descriptions are narrative rather than formal constraints. E.g., 'JavaScript code to execute' lacks type, length limits, or syntax validation rules. Descriptions should state format, range, and constraints explicitly.