Loading ToolBench
MCP server providing tools for searching and executing code against the Federal Register API and other data sources. Supports Code Mode execution with sandboxed V8 isolates, API catalog search, and data staging.
This server has severe definition quality issues. Tool names lack clear action verbs (e.g., '<prefix>_search' appears twice with different modes, '<prefix>_execute' appears three times). Descriptions are verbose (500+ chars) and bury key information. Input schemas are partially visible but lack proper type constraints and validation rules. No output schemas documented. Error handling guidance is absent. The server conflates multiple concerns into single tools (search + execute + staging logic), violating single-responsibility principle. Transport is unknown, blocking remote accessibility.
Execute JavaScript code in a sandboxed V8 isolate with access to API proxy helpers, catalog search functions, and optional filesystem access. Code runs with: searchSpec(query) / listCategories() / getEndpoint(path) for API discovery; api.get(path, params) / api.post(path, body, params) for HTTP calls; optional fs.* for filesystem operations; console.log() capture. Large responses (>100KB) are auto-staged into SQLite. Returns result with optional staging metadata.
Execute JavaScript code against a GraphQL endpoint in a sandboxed V8 isolate. Code runs with: gql.query(queryString, variables?) — GraphQL execution; schema.types(), schema.type(), schema.search() — introspection helpers; db.stage(), db.queryStaged() — staging helpers; optional api.get/api.post for REST calls (hybrid mode); optional fs.* for filesystem; console.log() capture. Large responses 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; prefixHeader — pre-built PREFIX block; optional fs.* for filesystem; console logging capture. Large responses (>30KB) are auto-staged into SQLite.
Search the API catalog (legacy catalog mode). Returns matching endpoints with full parameter docs. Use this to discover API capabilities before calling <prefix>_execute. Categories are listed. USAGE IN <prefix>_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 <prefix>_query_data to explore. Use limit/pagination params to control response size.
Tool name collision: '<prefix>_search' and '<prefix>_execute' used for multiple modes (catalog, OpenAPI, GraphQL, SPARQL). LLMs cannot distinguish between them. Each mode should have a distinct verb_noun name (e.g., search_catalog, search_openapi, execute_rest, execute_graphql, execute_sparql).
No output schemas documented. Descriptions mention '__staged' metadata and 'result' objects but do not specify field names, types, or structure. LLMs cannot plan downstream calls or extract data reliably.
Descriptions are 500+ characters and verbose. They mix usage instructions, parameter details, and implementation notes. Descriptions should be 50-200 chars explaining WHAT the tool does and WHEN to use it; usage details belong in parameter descriptions or separate documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 28 | 2026-07-28+ | v2 |
Search the OpenAPI spec (new mode). Write JavaScript code to search the spec, or use legacy query/category arguments. 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 <prefix>_search to discover endpoints, then write code in <prefix>_execute to call them.
No error handling guidance. Descriptions do not explain what errors can occur, how to recover, or what the LLM should do next. E.g., 'Large responses auto-staged', but what if staging fails? What if the API is unreachable?
Single tools combine multiple responsibilities: search + discovery + execution + staging. '<prefix>_execute' accepts arbitrary JavaScript code, making it a meta-tool rather than a focused action. This violates single-responsibility and makes it impossible for LLMs to reason about side effects or idempotency.