Loading ToolBench
MCP server for querying and analyzing GWAS (Genome-Wide Association Studies) catalog data with Code Mode execution, API discovery, and data staging capabilities
Three tools with partial schemas and descriptions. search and execute have reasonable descriptions (150-250 chars), but query_data is minimal (80 chars). All three tools have input schemas with type definitions and descriptions, meeting baseline requirements. However, output schemas are completely undocumented, LLMs cannot predict what fields to expect or chain results to downstream tools. The execute tool accepts arbitrary JavaScript code, creating a high-risk surface with minimal guardrails. No error handling guidance, no recovery patterns, no output field documentation. Naming is verb-forward (search, execute, query_data) but descriptions lack dependency hints and chaining context.
Execute JavaScript code against the API with sandboxed V8 isolate. Code runs with: searchSpec(query) / searchPaths(query) — search the API catalog/spec; listCategories() / listTags() — inspect tags/categories; getEndpoint(path) / getOperation(idOrPath) — get endpoint docs; 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; console.log() capture; Optional filesystem access (fs.readFile, fs.writeFile, fs.glob) when configured
Query staged data using SQL. Available when large responses have been auto-staged into SQLite. Accepts a data_access_id from a previous staged result and executes SQL queries against the staged tables.
Search the API catalog (endpoints). Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling execute. Categories are listed. 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. Large datasets auto-stage for SQL queries.
No output schemas documented for any tool. LLMs cannot predict response structure, field names, or types. Breaks tool chaining and forces agents to guess at downstream parameter mappings.
execute tool accepts arbitrary JavaScript code with minimal input validation or sandboxing guarantees documented. No error handling guidance for runtime failures, syntax errors, or timeout scenarios.
query_data description is only 80 characters and lacks context: when to call it, what data_access_id format is expected, what SQL dialect is supported, result limits, or error cases.
No pagination or result-limiting guidance in search tool. Catalog may return hundreds of endpoints; no max_results enforcement or next_cursor pattern documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
execute tool description mentions optional filesystem access (fs.readFile, fs.writeFile, fs.glob) but does not document when it is enabled, what paths are accessible, or security constraints.