Loading ToolBench
126 MCP tools for UK government IPA Gate Review assurance. Connects Claude to schedule analysis, risk registers, Monte Carlo simulation, narrative divergence detection, lessons learned, gate readiness, calibration evaluation, and escalation routing. Implements the nine-layer Verified Autonomy framework end-to-end.
Six tools with reasonable naming (verb_noun pattern) and documented schemas, but descriptions lack LLM-optimization depth and parameter descriptions are sparse. load_project has the strongest description (120+ chars with format hints); others are generic (20-50 chars). All tools have input schemas with type definitions, but parameter descriptions are minimal or missing. No error handling guidance, no output schema documentation, and no tool annotations (readOnlyHint). Composition is sound (single responsibility per tool), but descriptions do not explain WHEN to use each tool or what downstream tools expect.
Calculate and return the critical path for a project.
Identify project risks using AI-powered risk engine.
Load project from file path or inline file content. Supports automatic format detection or explicit format specification. Handles all 8 pm-data-tools formats with comprehensive error handling. For remote MCP clients (claude.ai via SSE), use file_content + file_name instead of file_path — the content will be written to a temporary file before parsing.
Query tasks from a loaded project with filtering, pagination, and status/criticality checks.
Validate business rules and scheduling logic. Checks for negative float, overdue milestones, and other semantic constraints.
Validate project data structure and integrity. Checks for orphan tasks, circular dependencies, invalid references, duplicate IDs, and date consistency.
Parameter descriptions are minimal or absent. 'filters' in query_tasks, 'focus_areas' in identify_risks, and 'checks'/'rules' in validation tools lack detail on valid values, constraints, or format. LLMs cannot infer enum values from names alone.
No output schema documentation. Tools return results but LLMs do not know what fields to expect (e.g., does query_tasks return task_id, task_name, status, dates?). This breaks downstream tool chaining and forces agents to guess field names.
Tool descriptions are too brief (20-50 chars for most tools). 'Calculate and return the critical path for a project' does not explain WHEN to call this vs query_tasks, what the output structure is, or how to use it in planning. Descriptions should be 50-200 chars with context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
No error handling guidance. Tools do not document what happens on invalid project_id, malformed filters, or missing data. LLMs receive raw errors with no recovery path (e.g., 'Project not found' vs 'Project not found. Call load_project() first.').
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All six tools are read-only, but this is not declared in the schema. Clients cannot infer safety properties without explicit annotations.