Loading ToolBench
MCP server for biological data APIs with Code Mode execution, GraphQL/SPARQL support, and auto-staging of large responses into SQLite
BioGrid MCP exposes 5 code-execution tools with detailed descriptions (150-300 chars each) and well-structured Zod schemas. Naming is clear and verb-driven (catalog_search, execute, graphql_execute, search, sparql_execute). However, parameter descriptions lack specificity on constraints (e.g., 'code' params do not specify max length, timeout, or sandbox limits). Output schemas are not documented, callers cannot predict the structure of result.__staged or understand when auto-staging triggers. Error handling is mentioned in descriptions but not formalized with recovery guidance. The 'workspace' parameter appears in execute/graphql_execute but lacks clarity on its lifecycle and validation rules.
Search the API catalog (legacy mode). Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling execute. Categories are dynamically populated from the 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. 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 the API with sandboxed V8 isolate. Code runs with: searchSpec(query) / listCategories() / getEndpoint(path) — API discovery helpers; api.get(path, params) / api.post(path, body, params) — HTTP calls through host proxy; db.stage() / db.queryStaged() — auto-staging into SQLite; fs.* — virtual filesystem (when enabled); console.log() capture. Large responses (>100KB) auto-stage; check result.__staged and use query_data to explore. The last expression or return value is the result.
Execute JavaScript code against a GraphQL API with sandboxed V8 isolate. Code runs with: gql.query(queryString, variables?) — GraphQL execution; schema.types() / schema.type(name) / schema.search(query) — introspection helpers; db.stage() / db.queryStaged() — auto-staging into SQLite; api.get/api.post — optional REST capability (when restApiFetch configured); fs.* — virtual filesystem (when enabled); console.log() capture. Large responses (>30KB) auto-stage; check result.__staged and use query_data to explore. The last expression or return value is the result.
Search the API spec (OpenAPI mode). Write JavaScript code to search the OpenAPI spec, or use 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; spec — the full frozen OpenAPI spec object. Use search to discover endpoints, then write code in execute to call them.
Output schemas not documented. Tools return result.__staged and auto-stage large responses, but callers cannot predict the structure or when staging occurs. LLMs cannot plan downstream calls without knowing response shape.
'code' parameter lacks constraints: no max length, timeout duration, or sandbox resource limits documented. LLMs may pass arbitrarily large or expensive code, risking timeouts or resource exhaustion.
'workspace' parameter (execute, graphql_execute) lacks validation rules, lifecycle documentation, or examples. Unclear whether it is a UUID, slug, or opaque token, and what happens if it does not exist.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Execute JavaScript code against a SPARQL endpoint with 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 to prepend to queries; fs.* — virtual filesystem (when enabled); console logging. Large SPARQL responses (>30KB) auto-stage into SQLite. The last expression or return value is the result.
Error handling is mentioned in descriptions but not formalized. No guidance on retryability, user-fixable vs. fatal errors, or recovery steps. LLMs cannot distinguish between transient failures and unrecoverable states.
catalog_search and search both perform keyword search but with different modes (static catalog vs. OpenAPI spec). Naming does not distinguish them; LLMs may conflate or misselect.