Loading ToolBench
MCP server for Quipu — a project management and protocol engine system. Provides tools for managing blocks, tasks, deliverables, evidence, criteria, contracts, and knowledge base. Integrates with Laravel backend and enforces protocol gates.
Quipu defines 46 tools with basic structure but significant quality gaps. All tools have names and descriptions, but descriptions are often terse (many under 100 chars) and lack actionable context for LLM selection. Input schemas are present but sparse: most tools have 0-2 parameters with minimal type information. Output schemas are not documented anywhere in the provided source. Parameter descriptions exist but are generic ('The X identifier'). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. Error handling is not visible in tool definitions. The codebase shows Laravel/MCP framework usage but tool implementations are not fully visible, making it impossible to verify actual behavior vs. declared schemas.
Adds evidence to a microtask, linking it to acceptance criteria. Evidence must declare which criteria it proves via criterion_ids
Claims a ready block and returns the complete payload with deliverables, acceptance criteria, frozen contracts, endpoints, and screens
Completes a task (microtask or block). If the gate is not green, returns an error with exactly what is missing
Creates a change in the demand chain
Reads a decision from the normative chain
Proposes a decision. This is a conservative act that does not bind anyone until a human decides
Declares requirements for a change
Output schemas not documented. No tool returns a documented schema showing what fields the LLM should expect. This forces LLMs to guess at response structure and breaks tool chaining when downstream tools need IDs or references.
Tool annotations missing. 46 tools lack readOnlyHint, destructiveHint, and idempotentHint despite clear risk classifications (READ_ONLY vs WRITE). LLMs cannot infer safety properties and may retry destructive operations.
Parameter descriptions are generic. Most parameters use boilerplate like 'The X identifier' without explaining format, constraints, or valid values. LLMs cannot validate input before calling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Declares deliverables for a block. Only needed if the block does not already declare them or if new pieces are discovered during work
Returns the domain context: what is norm today, what ceased to be, why, and what invariants apply
Links coverage to requirements
Identifies which screens are affected when touching a contract
Returns analysis fields for project analysis
Inspects a block without claiming it
Returns details of a change
Returns the gate status of a change
Returns a frozen contract that must be respected exactly as specified
Returns the schema for an endpoint
Returns existing components in the codebase. Can be filtered by project_slug
Returns the complete design of a feature including endpoints and screens in a single call
Checks if a block's gate is green. Returns specific details about what is missing: which deliverable is not built and which criterion lacks proof
Returns import contract for project structure
Returns tasks assigned to the current agent
Returns the analysis results for a project
Returns blocks that have passed dependency and contract gates and are ready to be claimed
Returns the design of a screen
Imports project structure from external source
Returns the invariants that apply to a domain
Links criteria to evidence
Lists available project templates
Lists all needs in the system
Lists all suspicions/issues in the system
Marks an acceptance criterion as met. Fails if no evidence is linked to it
Returns the next question in project analysis
Divides a block into microtasks, one per deliverable. Idempotent operation
Proposes revalidation of a requirement
Searches the knowledge base before repeating an error
Recommends an entry path for project implementation
Recommends project templates based on analysis
Records analysis results for a project
Records a new entry in the knowledge base
Records a contradiction. This is a conservative act that does not resolve anything until a human decides
Records a new need in the demand chain
Starts work on a microtask
Triages a need
Validates project design, identifying screens without data sources
Verifies contradictions before closing. Checks protocol consistency
Spanish tool names mixed with English. Tools like 'registrar_necesidad', 'triar_necesidad', 'declarar_requisitos' use Spanish verbs while most tools use English. This inconsistency confuses LLM tool selection and violates naming conventions.
No error handling guidance in tool definitions. Tools like 'complete_task' mention 'returns an error' but do not document what errors are possible, when they occur, or how to recover. LLMs cannot self-correct.