Loading ToolBench
MCP server for Code Mode execution with API catalog search, GraphQL, SPARQL, and REST API integration
Four tools with detailed descriptions and complex parameter schemas. All tools have descriptions (50-300+ chars) and input schemas with type definitions. However, schema completeness varies: search tool has explicit Zod schema visible; execute tools lack visible input schema definitions in provided source. Output schemas are undocumented across all tools. Error handling guidance is minimal. Tool naming follows verb_noun pattern (search, execute) but 'execute' is overloaded across three different API modes (REST, GraphQL, SPARQL), violating single-responsibility naming. Parameters are well-described but lack enum constraints for categorical values. No evidence of idempotency hints or destructive operation warnings.
Execute JavaScript code against the API. Code runs in a sandboxed V8 isolate with: searchSpec(query) / searchPaths(query) — search the API catalog or OpenAPI spec; listCategories() / listTags() — inspect tags/categories; getEndpoint(path) / getOperation(idOrPath) — get endpoint docs; describeEndpoint(path, method?) / describeOperation(idOrPath) — format endpoint docs; spec — full frozen OpenAPI spec object; api.get(path, params) for GET, api.post(path, body, params) for POST; api.getAll(path, params) for exhaustive fetch; db.stage(data, opts?) for manual staging; db.queryStaged(data_access_id, sql) for SQL queries; console logging (log, warn, error, info) — captured output. Large responses (>100KB) are auto-staged into SQLite. The last expression or return value is the result.
Execute JavaScript code against the GraphQL API. 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. Optionally also a SECOND, REST upstream (api.get/api.post) routed through the same host proxy + DO-SQLite staging (hybrid GraphQL+REST). API keys never enter the isolate — all HTTP goes through the host's gqlFetch.
Execute JavaScript code against the 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; fs.readFile / fs.writeFile / fs.glob ... — persistent virtual filesystem (when enabled). Large SPARQL responses (>30KB) are auto-staged into SQLite. The last expression or return value is the result.
Three tools named '{prefix}_execute' violate single-responsibility principle. LLMs cannot distinguish between REST, GraphQL, and SPARQL execution modes from the name alone. Should be named execute_rest, execute_graphql, execute_sparql.
Input schemas for three execute tools not visible in provided source code. Only catalog-search-tool.ts shows explicit Zod schema definition. Cannot verify parameter types, constraints, or descriptions for execute variants.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., staging IDs, pagination cursors) without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2026-07-28+ | v2 |
Search the API catalog (catalog mode) or OpenAPI spec (OpenAPI mode). Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling {prefix}_execute. Categories are listed. USAGE IN {prefix}_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 {prefix}_query_data to explore. Use limit/pagination params to control response size.
No error handling guidance in tool descriptions. Descriptions do not explain what errors are retryable, what user-fixable errors look like, or how to recover from staging/SQL failures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. All tools appear read-only but this is not formally declared, limiting agent safety reasoning.