cs-agent-mcp
Related Servers
Alternatives to cs-agent-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityAmaintenanceA stdio MCP server that lets any coding agent call any other as a subagent, exposing ask_ and dispatch_ tools for Claude Code, Codex, OpenCode, Antigravity, pi and HTTP endpoints. It enforces recursion depth guards, non-escalating permission ceilings and HMAC-attested results, and can hand off to a fallback agent when a rate limit is hit.122 npmMIT
- AlicenseBqualityBmaintenanceEnables any MCP host to delegate work to multiple coding-agent CLIs such as Codex, Claude Code, and Antigravity as subagents, preserving native sessions and supporting team-based supervision and agent-to-agent messaging.177 npmApache 2.0
- AlicenseNot gradedqualityDmaintenanceMCP bridge for calling local coding-agent CLIs (Codex, Claude) from another agent, enabling bounded tasks like code review, verification, and bug hunting.MIT
- FlicenseNot gradedqualityCmaintenanceA local MCP server that coordinates Claude Code CLI as subagents, providing tools to spawn, message, wait for, and interrupt agents.1-
- FlicenseNot gradedqualityBmaintenanceMCP server that bridges coding agents (Claude Code, Codex, Gemini CLI) via ACP for pair programming, enabling agents to consult each other as tools.3-
- AlicenseNot gradedqualityDmaintenanceEnables any MCP-compatible client to use existing Claude Code agents from .claude/agents/ directories. Spawns agents in separate CLI sessions for better context optimization and performance across Codex, Gemini CLI, and other AI coding assistants.3MIT
TDQS
Scored across 14 tools
Tools have clearly distinct roles with detailed descriptions, but the multiple wait/read variants (wait_message, wait_turn, get_message, get_turn, events) create some overlapping surface that could cause misselection without careful reading.
All tools share the cs_agent_ prefix and use consistent lowercase_with_underscores, but the verb pattern is mixed: some are bare verbs (create, list, send, cancel, destroy) while others are verb_noun (get_message, wait_turn). This is still predictable and readable.
14 tools is well within the optimal range and each tool serves a distinct need in the delegation lifecycle: capabilities, creation, messaging, waiting, permissions, cancellation, and destruction. The count feels appropriate for the domain.
The lifecycle is well covered: create, list, status, send, wait, cancel, destroy, plus capability discovery and permission handling. Minor gaps exist such as no explicit update_agent or non-turn messaging tool, but these are likely out of scope and core workflows are fully supported.