Scored across 29 tools
Tool boundaries are exceptionally clear: each resource family has a dedicated read/search/list/get path, and the three validation lenses are cleanly separated by role (architecture, surface, spec). Even near-neighbor tools like architect.validate vs architect.validate_consensus are explicitly distinguished by invocation intent and output.
The names follow a consistent <namespace>.<action> pattern across content, validators, personal, and handoff tools, and tokenization is uniformly lowercase snake_case. Minor deviations exist—me.sessions and me.learning_path are noun-like rather than action-like, and handoff tools use operator/partnership/agency rather than create_handoff—but the pattern remains highly readable and predictable.
29 tools is above the ideal 3-15 range and pushes into heavy territory, requiring real selection overhead for an agent. However, the server spans content browsing, validation/certification, personal learning, team sessions, signals, and support handoffs, so the breadth is plausibly justified even if trimming would improve focus.
The surface covers the full read/search/get lifecycle for principles, clusters, guides, and examples, plus validation, consensus, certification, history/recovery, learning evidence, sessions, signals, and human handoffs. Obvious lifecycle gaps exist (e.g. no delete/update for evidence, no certification or consensus for design/spec lenses, principles.search limited to architecture lens), but agents can work around them without dead-ends.
