Scored across 29 tools
Tools are cleanly separated by domain namespaces (examples, principles, clusters, guides, architect, design, spec, me, handoffs), and each tool targets a distinct resource or action. The only mild ambiguities are signals.feedback vs signals.report and the three search tools, but their descriptions clearly delineate when to use which.
The dominant pattern is <domain>.<action> in snake_case (examples.get, principles.search, architect.validate), which is predictable and readable. Minor deviations include me.sessions (plural noun), signals.feedback/report (noun forms), and handoffs.operator/partnership/agency (category nouns), but these do not seriously undermine consistency.
At 29 tools, the server exceeds the 25+ threshold for 'too many' and spans ten distinct namespaces, making the surface heavy for a single MCP server. Each tool has a legitimate purpose, but the count will feel overwhelming, especially with many tools gated behind Pro/Teams plans.
The doctrine discovery surface (principles, clusters, examples, guides, assets), all three validation lenses, coaching/learning progress, session history, and human handoffs are well covered. Obvious gaps include the lack of consensus and certification modes for design.validate and spec.validate, and no MCP-side session creation, but these are documented as v1 limitations or web-app responsibilities.
