Related Servers

There is heavy overlap between many tools: gc_conversation, gc_agent_conversation, gc_aden, gc_peer_conversation, and gc_peer all provide nearly identical spawn/turn/get/list/delete chat sessions — an agent could easily misselect among them. gc_docs and gc_recall both search knowledge; gc_project_status is literally an alias for gc_ticker/get; gc_peer is a legacy alias for gc_peer_conversation. Several tools (gc_workflow vs gc_workflow_watch vs gc_tool_call) also blur boundaries.

Most tools follow the gc_* prefix with snake_case, which provides surface consistency. However, the action-based dispatch convention means many tool names don't embed the verb; instead each gc_ tool takes an 'action' parameter (list, create, get, etc.), so the naming is more resource-oriented than verb_noun. There are also clear outliers like davinci_resolve, devonthink, gh_issues, and gh_issue_view which break the gc_ prefix pattern, and legacy aliases (gc_peer, gc_project_status) that don't follow the primary naming scheme.

At 63 tools this is far beyond the well-scoped range and will create significant selection burden and confusion for agents. Many tools cover adjacent concerns that could be consolidated (six conversation/chat tools, multiple alias tools, schedule vs dispatch vs workflow overlapping). The count reflects a sprawling monolithic daemon rather than a focused server purpose, making it very heavy for any agent to navigate.

The server covers an extraordinarily broad domain spanning memory, workflows, scheduling, dispatch, finances, publishing, project management, and even video editing — yet gaps exist within each sub-area (e.g., only one gh_issue_view tool among several gh_issue_* tools, no gh PR coverage despite gh_issue_view). Some sub-domains feel complete (workflows have full CRUD+ops) while others are fragmented. The scope itself makes 'complete' coverage nearly impossible.