Verified, cited knowledge for AI agents — Model Context Protocol server with a bundled structured catalog.
Ayiru MCP provides 14 tools with complete JSON Schema input definitions and descriptions. Naming follows verb_noun conventions (ask, validate_command, get_tool_spec, search_tools, etc.). However, descriptions are inconsistent in depth and actionability. Most are 30-80 chars, below the 50-200 char baseline for LLM optimization. Parameter descriptions exist but are minimal (e.g., 'The question to ask' for ask.question). Output schemas are not documented in the visible code. Error handling guidance is absent, tools return HTTP semantics without recovery hints. The submit_claim tool (WRITE) lacks confirmation/dry-run pattern. Tool composition is sound (single responsibility, chainable IDs), but descriptions need expansion to guide LLM selection and parameter usage.
POST /query/ask over MCP — the headline v0.2 retrieval surface.
POST /query/explain-risk over MCP.
Retrieve capabilities for a subject.
Retrieve constraints for a subject.
Retrieve effects for a subject.
POST /query/safe-workflow over MCP.
Once subject_id is known, return its full typed spec.
Descriptions are too brief (avg 45 chars vs 50-200 baseline). LLMs cannot distinguish when to call get_capabilities vs get_constraints vs get_effects, all three retrieve subject metadata but serve different purposes. Expand each to 80-150 chars explaining the semantic difference and use case.
Output schemas are not documented. Tools return structured data (KnowledgeClaim, Subject, Capability, etc.) but the response format is not visible in the tool definitions. LLMs cannot plan downstream calls or extract required fields without knowing what fields are returned.
submit_claim (WRITE tool) lacks confirmation or dry-run pattern. Agents can submit claims without preview, risking incorrect or duplicate submissions. Add a dry_run parameter or a separate validate_claim tool to preview before committing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
GET /query/tools/{tool_id} over MCP.
Retrieve workflow plan for a subject.
Resolve an action to its subject and capability.
Discovery: turn a fuzzy hint into a typed list of subjects.
GET /query/search-tools over MCP.
POST /claims over MCP — the only write tool. Mirrors the REST handler in routes_claims.py: server-assigns ids and created_at, normalises evidence trust, persists the claim, runs the orchestrator, and returns the resulting KnowledgeClaim with its verification status set.
POST /query/validate-command over MCP.
No error recovery guidance. Tools return HTTP semantics (404, 400, 500) without actionable hints. E.g., if resolve_subject returns 'not found', the LLM should know to try search_tools or ask for clarification. Add recovery hints to error responses.
Parameter descriptions lack format/constraint details. E.g., limit (integer) has no min/max; tool_id_hint (string) has no pattern or example. Add constraints like 'limit: 1-100 (default 20)' and 'tool_id_hint: alphanumeric, e.g. gh, npm' to guide LLM input.