Loading ToolBench
AI Infrastructure You Can Verify. Provider-independent routing, deterministic verification, cryptographic signatures, append-only audit.
Sovereign MCP has critical definition gaps across all 6 tools. While tool names follow verb_noun convention (compute_route, ere_verify, proxy_register, proxy_list, magma_seal, agent_dispatch), descriptions are vague and lack actionable context. Input schemas are present but lack parameter descriptions, critical for LLM tool selection. No output schemas documented. Error handling is absent. The server exposes domain-specific concepts (Magma envelopes, ERE verification, agent dispatch) without explaining when/why to use each tool or what they return. This forces LLMs to guess at tool semantics.
dispatch a task to a named sovereign agent
dynamic LLM router (Bedrock → Groq → Ollama)
local ERE 5-pass on any content string
wrap any result in a Magma envelope + WORM hash
list all registered proxy tools
register a named proxy tool at a URL
No parameter descriptions in any tool. Parameters like 'prompt', 'agent', 'content', 'filepath', 'name', 'url', 'result', 'task' lack guidance on format, constraints, or valid values. LLMs cannot infer whether 'agent' expects 'ahmad' or 'Agent Ahmad' or a UUID.
No output schemas documented for any tool. Callers cannot know what fields to expect (e.g., does compute_route return {result, tokens_used, model_used} or just {result}?). This breaks tool chaining and forces LLMs to guess at response structure.
Tool descriptions are too vague and lack context. 'dynamic LLM router' does not explain when to use compute_route vs agent_dispatch. 'local ERE 5-pass' assumes LLM knows what ERE is. Descriptions should be 50-200 chars and answer: what does it do, when to use it, what does it return?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
No error handling guidance. If compute_route fails (all providers down), what does the LLM do? If ere_verify rejects content, what should the agent try next? No recovery paths documented.
Agent parameter in compute_route and agent_dispatch accepts hardcoded enum (ahmad, forge, oracle, sentinel, vault, enki, nexus, edaulc) but this is not declared as an enum constraint in the schema. LLMs may hallucinate invalid agent names.