Loading ToolBench
MCP server for executing code against APIs and GraphQL/SPARQL endpoints with sandboxed V8 isolates, auto-staging, and schema discovery
This server exposes 5 code-execution tools with detailed descriptions but critical schema and composition gaps. All tools accept JavaScript code as input with minimal parameter validation. Descriptions are verbose (200-400 chars) but lack actionable constraints. Input schemas are present but incomplete: 'code' parameters lack format/length constraints; 'workspace' is optional but undocumented for its impact on data isolation. No output schemas are documented. Error handling is absent, no guidance on recovery, retryability, or what happens on sandbox failures. Tools violate single-responsibility: execute, graphql_execute, and sparql_execute all run arbitrary code with different runtime contexts, creating cognitive load for LLM selection. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Composition is weak: no chaining IDs returned, no pagination for large results despite auto-staging mention.
Search the API catalog (legacy mode). Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling execute. Categories are listed. 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. 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.
Execute JavaScript code against an API catalog or OpenAPI spec in a sandboxed V8 isolate. Code runs with api.get/api.post wrappers, schema search helpers (searchSpec, listCategories, getEndpoint), console.log capture, and optional filesystem access. Large responses (>100KB) are auto-staged into SQLite. Returns result with optional staging metadata and citation information.
Execute JavaScript code against a GraphQL endpoint in a sandboxed V8 isolate. Code runs with gql.query(queryString, variables?) for GraphQL execution, schema.types()/schema.type()/schema.search() for introspection helpers, db.stage()/db.queryStaged() for staging, and optional REST api.get/api.post when a second upstream is configured. Large responses are auto-staged into SQLite. Returns result with optional staging metadata and citation information.
Search the OpenAPI spec or API catalog. Write JavaScript code to search the spec using helper functions (searchPaths, listTags, getOperation, describeOperation) or use legacy query/category arguments for keyword search. Returns matching operations with full documentation.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract structured data. catalog_search, execute, search, graphql_execute, sparql_execute all return untyped results.
Code parameter lacks constraints: no max length, no format validation, no guidance on sandbox limits. LLMs can pass arbitrarily large or malformed code, causing sandbox failures with no recovery path.
Three separate code-execution tools (execute, graphql_execute, sparql_execute) with overlapping semantics. LLMs must reason about which runtime to use; no clear guidance on when to pick each. Violates single-responsibility principle.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Execute JavaScript code against a SPARQL endpoint in a sandboxed V8 isolate. Code runs with sparql.query(queryString, opts?) for SELECT/CONSTRUCT/DESCRIBE, sparql.ask(queryString) for ASK queries, sparql.raw(queryString, opts?) for unparsed envelopes, prefixes object with common ontology prefixes, prefixHeader pre-built PREFIX block, and optional filesystem access. Large responses (>30KB) are auto-staged into SQLite. Returns result with optional staging metadata and citation information.
No error handling guidance. Descriptions mention 'auto-staging' and 'sandbox' but do not explain what happens on failure, whether calls are retryable, or how to recover from sandbox timeouts or quota exhaustion.
workspace parameter is optional and undocumented for its side effects. Descriptions do not explain whether omitting it creates isolation, whether data persists across calls, or how it affects subsequent queries.