Related Servers

The server is dominated by near-duplicate tool pairs (e.g. get_requirement_detail vs get_requirement_detail_by_ref, get_bug_detail vs get_bug_detail_by_ref, get_task_messages vs get_task_messages_by_ref) that differ only in whether the input is a task id or a number/URL. The descriptions explicitly state 'prefer *_by_ref for normal workflow reads,' which helps an agent choose, but the systematic duplication still creates real misselection risk. The doc tools (get_doc, get_doc_section, get_doc_chunks, get_doc_outline, get_doc_context) are mostly distinct by granularity, though get_doc_context overlaps with section/chunk retrieval.

All tools use snake_case verb_noun phrasing (get_, resolve_, list_, extract_, search_, download_) with a consistent '_by_ref' suffix convention for the reference-based variants. Minor stylistic drift exists between get_ vs resolve_ for related operations, but the pattern is largely predictable.

At 28 tools the set is heavy for the stated scope, and much of the bloat comes from duplicating roughly ten read operations into non-ref/ref pairs. Collapsing these pairs would bring the surface to a much more reasonable ~15 tools, so the current count is inflated rather than earned.

Coverage spans docs (retrieval, outline, chunks, search, resource download), requirements, bugs, tasks, comments, wiki pages, and rich resources, with by_ref variants for most read paths. It is a read-oriented surface with no create/update operations, but for a documentation/inspection server the lifecycle coverage is solid with only minor gaps (e.g. no generic task-detail fetch, search limited to docs).