Related Servers

Most tools have clearly distinct purposes: pipeline_* tools manage pipelines, role/agent tools manage permissions, add/update tools handle feature and test tracking. The main confusion is between cortex_health and cortex_auto_heal, which both check integrity and repair broken items, and cortex_check_reminders overlaps somewhat with both. The cortex_get_state vs cortex_get_detail distinction is clear.

The set follows a consistent cortex_ prefix with verb_noun structure (add_feature, get_state, resolve_issue, pipeline_start). A few deviations exist: cortex_health is a bare noun instead of a verb_noun form, and cortex_tick_file uses the unusual 'tick' verb, but these are minor and decodable. Overall the pattern is predictable.

42 tools is well beyond the 25+ threshold for 'too many' and requires a large surface area for an agent to internalize. The scope is broad (project state, features, tests, issues, knowledge base, skills, roles, pipelines, tokens, health), but much of it could be consolidated — e.g., pipeline alone takes 7 tools, and health/auto_heal/check_reminders could be unified. The count makes misselection more likely.

The core workflow is well covered: init → get_next_task → log_progress → tick_file → add/update tests → log/resolve issues, plus pipeline lifecycle has full start/pause/resume/cancel/plan/history coverage. However, there are notable gaps: no delete operations anywhere (no delete_feature, delete_test, delete_snippet, delete_issue), and no list/get_all tools — retrieval depends almost entirely on cortex_search or the compressed state. Read and removal paths are weak for a system that stores this much data.