Reference MCP server implementing the Service-Oriented Protocol Router (SOPR) pattern with mode-based tools, composable resilience, and hexagonal architecture
SOPR MCP implements 8 tools with full Zod schema validation and documented input constraints. Naming follows verb-noun convention (snap, check, learn, integrate, pulse, graph, cache, help). All tools have descriptions and parameter documentation. However, tool descriptions are brief (19-118 chars), most lack output schema documentation, and error handling guidance is not visible in the source. The server prioritizes input validation (SafePathSchema, bounds checking, enums) over LLM-centric output design and recovery patterns. Strengths: comprehensive input schemas with security bounds; clear mode discriminators; safe path validation. Weaknesses: minimal output documentation; descriptions lack 'when to use' context; no visible error recovery guidance; tool compositions and chaining unclear.
Error & pattern cache operations. Modes: errors (error cache), patterns (pattern cache).
Code validation. Modes: quick, full, patterns, build, circular, security, coverage, orphans, health, evolution, integrations.
Dependency & file graph analysis. Modes: deps (dependency graph), files (file graph).
Tool discovery and documentation. Modes: tools (list tools), status (system status), wire (wire format info), modes (available modes), thresholds (configuration thresholds), decision (routing decision), all (complete documentation).
External integrations. Modes: git (repository context), sentry (error tracking), github (PR/issue data).
Learning system. Modes: load (retrieve learnings), save (persist insight), search (query learnings).
Output schemas not documented. No visible response type definitions for any tool. LLMs cannot plan chaining or know what fields to extract from results.
Tool descriptions are too brief (avg 65 chars; baseline 194 chars). Most lack context for when/why to use them. E.g., 'Snapshot lifecycle. Modes: start...' tells WHAT but not WHEN or prerequisites.
No visible error handling or recovery guidance in tool implementations. Errors likely return raw HTTP codes or stack traces instead of actionable recovery hints for LLMs.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2025-06-18+ | v2 |
System health monitoring. Modes: health (overall system status).
Snapshot lifecycle. Modes: start (begin task), check (validate), context (get context), end (complete), undo (revert + mask).
Tool composition unclear. Multi-mode tools (snap, check) with 5-11 modes each suggest multiple concerns bundled into single tools. E.g., snap handles start/check/context/end/undo, lifecycle management and undo should likely be separate.
'cache' tool accepts `value: unknown` with no type or format constraint. JSON-serialized size is mentioned (1MB cap) but no guidance on what data types are valid or how to structure values.
No batch variants for operations. E.g., if 'learn' is called repeatedly in a loop, agents waste tokens on sequential calls instead of one batch operation.