Loading ToolBench
Code Mode MCP server for the UK Parliament APIs
Both tools have severe definition gaps. The 'search' tool description is extremely long (500+ chars) and reads as API documentation rather than LLM-optimized guidance. The 'execute' tool description is vague (23 chars). Neither tool has visible input parameter schemas with type definitions in the source code, only a code string parameter is mentioned. No output schemas are documented. The server accepts arbitrary JavaScript code execution, which is a fundamental security and composability issue. Tool names lack verb clarity ('search' and 'execute' are generic). No error handling guidance is visible.
Execute code against UK Parliament APIs with dynamic worker evaluation
Search the pre-resolved OpenAPI catalog for every public UK Parliament API. APIs: members (Members v1), interests (Register of Interests v2), commons_votes (Commons Votes v1), lords_votes (Lords Votes v1), oral_questions_and_motions (Oral Questions and Motions v1), statutory_instruments (Statutory Instruments v2), treaties (Treaties v1), erskine_may (Erskine May v1), parliament_now (Parliament Now v1), bills (Bills v1), questions_and_statements (Written Questions and Statements v1), committees (Committees v1) Available in generated code: interface ParliamentOperation { operationId?: string; summary?: string; description?: string; tags?: string[]; parameters?: Array<{ name: string; in: string; required?: boolean; description?: string; schema?: unknown; type?: string }>; responses?: Record<string, unknown>; } interface ParliamentApi { key: string; name: string; version: string; baseUrl: string; paths: Record<string, Partial<Record<"get" | "post" | "put" | "patch" | "delete", ParliamentOperation>>>; } declare const catalog: { generatedAt: string; apis: Record<string, ParliamentApi> }; Return only the operations or schema fragments needed for the task. Results use JSON serialization semantics: undefined object properties are omitted and undefined array entries become null. Example: async () => Object.entries(catalog.apis.members.paths) .filter(([path]) => path.toLowerCase().includes('contact')) .map(([path, methods]) => ({ path, methods: Object.keys(methods), get: methods.get?.summary }))
No input schemas visible in source code. Both tools accept only a 'code' string parameter with no type validation, constraints, or format documentation.
Tool descriptions are not LLM-optimized. 'search' description is 500+ chars (exceeds 1024 baseline max but reads as raw API docs). 'execute' is only 23 chars. Descriptions should be 50-200 chars, action-oriented, and explain WHEN to use the tool.
No output schemas documented. Callers cannot predict what 'search' or 'execute' return. LLMs cannot plan downstream tool calls or extract structured data without knowing response shape.
Generic tool names lack action clarity. 'search' and 'execute' do not convey intent. 'search' could mean search APIs, search documentation, or search results. 'execute' is dangerously vague, execute what? Baseline: 90% of A+ tools start with specific action verbs (get_, create_, update_, delete_, search_).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | 2026-07-28+ | v2 |
Code execution model is a security and composability anti-pattern. Accepting arbitrary JavaScript strings bypasses schema validation, makes error handling opaque, and prevents LLMs from reasoning about tool contracts. This violates the single-responsibility principle and pattern:tool-chain.