Loading ToolBench
MCP server implementation for executing Enact capabilities dynamically
Server has 4 tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error guidance. Tool names contain conjunctions ('search-and-register') violating single-responsibility principle. Descriptions are present but generic (avg ~80 chars, below 194-char baseline). Parameters lack type specificity, 'args' is z.record(z.any()), accepting any object with no validation. No output schemas documented. Error handling returns text but lacks recovery guidance or categorization. No tool annotations (readOnlyHint/destructiveHint). Logging capability declared but not leveraged for audit trails.
Register a capability as a tool
Search capabilities in the Enact ecosystem and register the first result as a tool
Search capabilities in the Enact ecosystem
Execute an enact capability by its ID
Tool 'enact-search-and-register-capabilities' violates single-responsibility principle, name contains 'and', combining search + register. Should split into separate tools.
Parameter 'args' in execute-capability-by-id uses z.record(z.any()), accepts any object with no validation, type hints, or constraints. LLM cannot infer valid structure.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., capability IDs for chaining).
Error responses return plain text without recovery guidance. E.g., 'Error searching capabilities' tells LLM nothing about retry eligibility or next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLM cannot distinguish safe reads from destructive writes without explicit hints.