Loading ToolBench
MCP server providing tools for API discovery, execution, and data staging across multiple API types (REST, GraphQL, SPARQL). Supports Code Mode execution with sandboxed V8 isolates, auto-staging of large responses, and citation/provenance tracking.
This server has severe definition quality issues. Only 1 of 4 tools has a visible, complete input schema in the provided source. Tool naming uses a generic placeholder pattern ({prefix}_search, {prefix}_execute) that obscures actual tool names and violates verb_noun conventions. Descriptions are verbose (200-400+ chars) but lack clarity on WHEN to use each tool vs. alternatives. Three tools share the name '{prefix}_execute' with different purposes (REST API, GraphQL, SPARQL), creating dangerous ambiguity, LLMs cannot distinguish them. Parameter descriptions exist but lack format constraints, ranges, and validation rules. No output schemas are documented. Error handling is absent from descriptions. The server appears to be a framework/template rather than a concrete, deployable MCP server with real tool names.
Execute JavaScript code against the API in a sandboxed V8 isolate. Code runs with: searchSpec(query) / searchPaths(query) — search the API catalog or OpenAPI spec; listCategories() / listTags() — inspect categories/tags; getEndpoint(path) / getOperation(idOrPath) — get endpoint docs; api.get(path, params) for GET, api.post(path, body, params) for POST; Large responses (>100KB) are auto-staged into SQLite; Use limit/pagination params to control response size. Remaining params become query string. Path params like /lookup/{id} are auto-interpolated from params.
Execute JavaScript code against a GraphQL API in a sandboxed V8 isolate. Code runs with: gql.query(queryString, variables?) — execute GraphQL queries; schema.types(), schema.type(), schema.search() — GraphQL introspection helpers; db.stage(), db.queryStaged() — staging helpers; Optional REST capability: api.get(path, params) for GET, api.post(path, body, params) for POST when restApiFetch is configured; console.log() capture; Large responses (>30KB) are auto-staged into SQLite.
Execute JavaScript code against a SPARQL endpoint in a sandboxed V8 isolate. Code runs 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; console logging capture; Optional filesystem: fs.readFile / fs.writeFile / fs.glob when fsDoNamespace configured; Large SPARQL responses (>30KB) are auto-staged into SQLite.
Search the API catalog (catalog mode) or OpenAPI spec (OpenAPI mode). Returns matching endpoints with full parameter documentation. Use this to discover API capabilities before calling {prefix}_execute. In catalog mode: accepts query/category/max_results parameters and performs keyword-based search over static ApiCatalog. In OpenAPI mode: accepts code parameter for agent-written JavaScript with full resolved OpenAPI spec and helper functions available.
Three tools share identical name '{prefix}_execute' with completely different purposes (REST API execution, GraphQL execution, SPARQL execution). LLMs cannot distinguish them and will select randomly. This violates the single-responsibility principle and creates silent failures.
Tool names use placeholder '{prefix}_' pattern instead of concrete names. This indicates the source is a template/framework, not a deployable MCP server. Actual tool names cannot be evaluated. Per HARD SCORING RULES, inferred tool definitions cap at 50 overall.
Only {prefix}_search has a visible input schema in the provided source code. The three {prefix}_execute variants show descriptions but NO input schema definitions in the code excerpt. Per HARD SCORING RULES, tools without visible schemas score 0 on schema dimension.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 24 | 2026-07-28+ | v2 |
No output schemas documented for any tool. Descriptions mention return types (e.g., 'Large responses auto-staged into SQLite') but do not specify the structure of successful responses, error responses, or pagination. LLMs cannot plan downstream tool calls without knowing output fields.
Descriptions are 200-400+ characters, exceeding the 10-1024 baseline and burying key details. The {prefix}_execute descriptions are dense walls of text listing available functions (searchSpec, listCategories, api.get, etc.) without explaining WHEN to use this tool vs. alternatives or what the LLM should expect to receive back.