Loading ToolBench
MCP server for PubChem API access with Code Mode execution, API catalog search, and data staging capabilities
Three tools with partial schemas and descriptions. pubchem_search has good description (250+ chars) and complete Zod schema with typed parameters. pubchem_execute has extensive description but no visible input schema in source, only code reference. pubchem_query_data has minimal description (80 chars, below 100-char baseline) and no schema visible. Tool names are verb-prefixed but descriptions lack actionable error guidance and recovery paths. No output schemas documented. No tool annotations (readOnlyHint, etc.) despite all being read-only operations.
Execute JavaScript code against the PubChem API. Code runs in a sandboxed V8 isolate with: - api.get(path, params) / api.post(path, body, params) — call API endpoints - api.getAll(path, params) — exhaustive fetch with automatic pagination - searchSpec(query) — search the API catalog - listCategories() — list endpoint categories - getEndpoint(path) — get full endpoint docs - console logging (log, warn, error, info) — captured output - db.stage(data, opts?) — stage large datasets into SQLite - db.queryStaged(dataAccessId, sql) — query staged data in-band - fs.readFile / fs.writeFile / fs.glob ... — persistent virtual filesystem (if enabled) The last expression or return value is the result. 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 pubchem_query_data. OPERATING RULES: - Start with small queries and add LIMIT early. - Use pagination params to control response size. - Re-run requests in long conversations instead of relying on older tool output.
Query staged datasets using SQL. Returns results from auto-staged large API responses or manually staged data.
Search the PubChem API catalog (endpoints). Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling pubchem_execute. USAGE IN pubchem_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 pubchem_query_data to explore - Use limit/pagination params to control response size. Large datasets auto-stage for SQL queries.
pubchem_execute and pubchem_query_data lack visible input schemas in source code. Only pubchem_search shows explicit Zod schema definition. Cannot verify parameter types, constraints, or descriptions for two of three tools.
pubchem_query_data description is 80 characters, below the 100-char minimum baseline. Lacks context on when to use it vs. inline db.queryStaged() in pubchem_execute. No guidance on expected output structure or error cases.
No output schemas documented for any tool. pubchem_search returns 'matching endpoints' but structure undefined. pubchem_execute returns 'last expression or return value', ambiguous. pubchem_query_data returns 'results' with no field specification. LLMs cannot plan downstream calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
No error handling guidance in any tool description. pubchem_execute mentions 'auto-staging' for large responses but does not explain what happens if staging fails, how to recover, or what error messages to expect. No recovery paths documented.
All three tools are read-only (Risk: READ_ONLY) but lack tool annotations (readOnlyHint). MCP spec 2026-07-28 supports tool annotations to signal safety properties. Agents cannot infer idempotency or safety without explicit hints.