Loading ToolBench
MCP server for ChEBI (Chemical Entities of Biological Interest) API access with code execution, API discovery, and data staging capabilities
Three tools with significant definition gaps. chebi_search has a reasonable description (194 chars) and typed schema with descriptions, but chebi_execute and chebi_query_data lack proper input schema documentation in the visible source. The descriptions are verbose but lack actionable guidance on when to use each tool vs. alternatives. No output schemas documented. Error handling and recovery guidance absent. Tool composition is reasonable (search → execute → query), but parameter relationships underdocumented.
Execute JavaScript code against the ChEBI API. Code runs in a sandboxed V8 isolate with: - searchSpec(query) — search the API catalog - listCategories() — list endpoint categories - getEndpoint(path) — get full endpoint docs - api.get(path, params) / api.post(path, body, params) — make HTTP requests - api.getAll(path, params) — exhaustive fetch with auto-pagination - db.stage(data, opts?) — stage large datasets into SQLite - db.queryStaged(dataAccessId, sql) — query staged data - console logging (log, warn, error, info) — captured output - fs.readFile / fs.writeFile / fs.glob ... — persistent virtual filesystem (if enabled) The last expression or return value is the result. API REFERENCE: (No endpoints configured) STAGING: Large responses (>30KB) are auto-staged into SQLite. When this happens, api.get returns {__staged: true, data_access_id, schema, tables_created, total_rows, message}. Use db.queryStaged(data_access_id, sql) in-band, or return the staging object so the caller can use chebi_query_data. OPERATING RULES: - Use searchSpec() to discover endpoints before calling them. - Prefer specific queries over broad fetches. - Use limit/pagination params to control response size. - Re-run requests in long conversations instead of relying on older tool output.
Query staged datasets using SQL. Available when auto-staging has created tables from large API responses.
Search the ChEBI API catalog. Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling chebi_execute. Categories: (0) USAGE IN chebi_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 chebi_query_data to explore - Use limit/pagination params to control response size. Large datasets auto-stage for SQL queries.
chebi_execute and chebi_query_data lack visible input schema definitions in source code. Only descriptions provided; no Zod schema or JSON Schema with typed parameters visible.
No output schemas documented for any tool. LLMs cannot predict return structure, forcing them to guess field names and types for downstream tool calls.
chebi_query_data description (40 chars) is too brief. Does not explain when to call it, what SQL dialect is supported, or how to reference staged data.
No error handling guidance. Descriptions do not explain what happens on invalid queries, missing data_access_id, or SQL errors. LLMs have no recovery path.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
chebi_execute description mentions 'workspace' parameter but does not explain when it is required, what happens if omitted, or how shared staging works.