Loading ToolBench
Governed Model Context Protocol server with deterministic execution, providing governance and policy evaluation tools over a local stub substrate
The Iter MCP server exposes 8 tools with reasonable naming (verb-noun patterns like 'node.create', 'edge.bind') but suffers from significant gaps in descriptions, parameter documentation, and output schema visibility. Most tool descriptions are present but fall short of the 10-1024 character guidance and lack actionable context. Input schemas are visible for all tools with basic type coverage, but parameter descriptions are minimal and lack constraints (enums, ranges, format hints). No visible output schemas or error handling guidance. The server appears to be in early/mid development with stub implementations ('public_stub' feature flag suggests reserved functionality). Tools are not annotated with risk metadata suitable for production use beyond the risk=READ_ONLY/WRITE declarations visible in the inventory.
Searches audit logs for governance decisions with filtering and deterministic ordering
Creates a directed edge between two nodes with a specified weight
Executes belief/energy propagation along a specified edge
Non-mutating preview of a governance decision without applying it
Returns the current health and coherence status of the governance system
Creates a new node in the governance graph with specified belief and energy values
Applies a mutation to a node's belief value with governance evaluation
Parameter descriptions are minimal and lack actionable constraints. Parameters like 'belief', 'energy', 'delta', and 'weight' have 1-line descriptions but no guidance on valid ranges, units, or semantics. LLMs cannot infer whether 'belief' should be 0-1, -∞ to +∞, or require special formatting.
No visible output schemas documented. Tools like 'node.create', 'node.query', and 'audit.search' do not show what fields they return. An LLM cannot plan downstream calls (e.g., using a node_id from node.create in node.query) without knowing the response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | 1.0.0+ | v1 |
Queries the state of an existing node by its identifier
Tool descriptions lack WHEN/WHY context. 'Creates a new node in the governance graph with specified belief and energy values' states WHAT but not WHEN to use node.create vs direct governance operations, what 'belief' and 'energy' represent semantically, or what side effects occur.
No error handling or recovery guidance visible. No indication of what errors each tool can raise, whether failures are retryable, or what the LLM should do next (e.g., 'If node not found, try listing all nodes first').
'audit.search' accepts 8 parameters (principal, action, resource, decision, policy_id, from, to, limit) with no documentation of their semantics, valid formats, or constraints. LLMs will guess at date formats ('from'/'to'), enum values ('action', 'decision'), and whether filtering is OR or AND logic.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). While the inventory marks tools as READ_ONLY or WRITE, these are not expressed in the MCP protocol's tool annotation format, limiting client-side optimization and safety checks.
'governance.preview' accepts a generic 'request' object parameter with no schema detail or example structure. LLMs cannot construct a valid request without examples or a detailed nested schema.