This MCP server enables AI assistants to delegate specialized tasks to autonomous sub-agents defined in markdown files, bringing Claude Code-style workflows to any MCP-compatible tool.
Core Capabilities:
Agent delegation - Offload complex, multi-step, or specialized tasks (code reviews, test writing, security checks, refactoring) to autonomous agents using the run_agent function
Reusable agent definitions - Create custom agents as simple markdown files that are portable and reusable across projects and teams
Cross-tool compatibility - Use the same agent definitions in any MCP-compatible tool (Cursor, Claude Desktop, Windsurf, etc.)
Engine flexibility - Execute agents through cursor-agent or claude CLI backends via the AGENT_TYPE environment variable
Context isolation - Each agent runs with fresh, independent context to prevent interference between tasks
Session management - Optional persistent sessions (SESSION_ENABLED) allow agents to maintain context and build upon previous executions for iterative workflows
Execution control - Configure working directories (cwd), timeouts, and shell command permissions through allowlists
Batch operations - Handle systematic codebase analysis, fix multiple test failures, or perform refactoring across multiple files
Team collaboration - Share standardized agent definitions across teams regardless of IDE preferences
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Task Agents review this Python function for bugs and improvements"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Run reusable coding agents from any MCP-compatible client.
Write a reviewer, test writer, or investigator in Markdown, then ask your assistant to use it. The MCP server runs that agent with the coding CLI you choose and returns the result to the same conversation.
Delegate code review, test writing, investigation, and documentation to focused agents
Reuse the same agent definitions across MCP clients with one shared backend and model configuration
Continue the same agent across multiple calls for longer work
Related MCP server: Agents Council
You need Node.js 22 or later, an MCP-compatible client, and one supported coding CLI installed and signed in. This example uses Codex.
Create an agents folder anywhere on your machine, then add code-reviewer.md:
# Code Reviewer
Review code for bugs and maintainability issues.
## Task
- Find concrete problems in the requested changes
- Explain why each problem matters
- Point to the affected code
## Done When
- All requested files have been reviewed
- Findings include evidence and suggested next stepsThe filename becomes the agent name: code-reviewer.md becomes code-reviewer.
Add the server to your client's MCP configuration. Replace AGENTS_DIR with the absolute path to the folder you created.
{
"mcpServers": {
"sub-agents": {
"command": "npx",
"args": ["-y", "sub-agents-mcp"],
"env": {
"AGENTS_DIR": "/absolute/path/to/agents",
"AGENT_TYPE": "codex"
}
}
}
}Restart or reconnect your MCP client after saving the configuration.
Ask your assistant:
Use the code-reviewer agent to review the authentication changes.Your assistant runs the agent with Codex and returns the review to the conversation.
Use the test-writer agent to add unit tests for the auth module.Use the bug-investigator agent to find the cause of the failed checkout requests.Use the doc-writer agent to document the public API changes.Name both the agent and the work you want it to do.
Use the MCP server when you want to share the same agents across MCP clients while keeping backend and model configuration in one place.
If you prefer a lighter installation or want each agent to choose its own backend and model, see Sub-Agents Skills.
Set AGENT_TYPE to the backend you already use:
| Backend | Command |
| Codex |
|
| Claude Code |
|
| Cursor CLI |
|
| Command Code |
|
| GLM (Z.ai) |
|
| Kimi |
|
| Grok Build |
|
| Google Antigravity |
|
| Gemini CLI (compatibility) |
|
| OpenCode |
|
The selected CLI must be installed and configured before the MCP server starts.
GLM and Kimi require CLI_API_KEY in the MCP server environment. Other backends use the CLI's existing authentication.
For Google models, prefer Antigravity. Gemini CLI remains available for existing enterprise, API key, or Vertex AI configurations.
Set AGENT_MODEL to use one model for every agent. Omit it to use the backend's default.
AGENT_PERMISSION controls what agents may do:
read-only — review and investigation
safe-edit — edits allowed without approval (default)
yolo — unrestricted execution
If an agent reports that an action was blocked, choose a less restrictive mode.
Set SESSION_ENABLED to "true" when you want an agent to remember earlier calls and continue a longer task. Your assistant must reuse the returned session_id on the next call to continue that session.
Run the selected backend command directly and confirm that it is installed and signed in
Make sure AGENTS_DIR is an absolute path and contains at least one .md or .txt file
Restart or reconnect the MCP client after changing its configuration
MIT
Delegate complex, multi-step, or specialized tasks to an autonomous agent for independent execution with dedicated context (e.g., refactoring across multiple files, fixing all test failures, systematic codebase analysis, batch operations). Returns session_id in response metadata - reuse it in subsequent calls to maintain conversation context continuity across multiple agent executions.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | Working directory path for agent execution context. Must be an absolute path to a valid directory. | |
| agent | Yes | Agent name exactly as listed in list_agents resource. | |
| prompt | Yes | User's direct request content. Agent context is separately provided via agent parameter. | |
| session_id | No | Session ID for continuing previous conversation context (optional). If omitted, a new session will be auto-generated and returned in response metadata. Reuse the returned session_id in subsequent calls to maintain context continuity. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful behavior beyond the schema: the agent runs independently with dedicated context and returns a session_id in response metadata for reuse. However, with no annotations provided, the description should be clearer about potential side effects such as file modifications or long-running operations, which are implied by the examples but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and use cases, followed by the only critical chaining detail. Every sentence earns its place with no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an autonomous agent tool with no output schema or annotations, the description covers the core contract (task delegation, dedicated context, session continuity) but omits the result payload beyond session_id, execution lifecycle, and safety caveats. This is adequate but incomplete for a potentially powerful and side-effectful tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameter meanings are already documented and the baseline is 3. The description adds a small extra note about session_id being returned and reusable, but does not provide deeper syntax or format details beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb ('Delegate') and identifies both the resource ('autonomous agent') and the execution mode ('independent execution with dedicated context'). Concrete examples like refactoring across files, fixing test failures, and batch operations remove ambiguity about what the tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Complex, multi-step, or specialized tasks' explicitly defines the intended trigger conditions, and the session_id guidance explains how to chain multiple executions. There are no exclusions or alternative tools named, but no sibling tools exist to require them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.14.2run_agent1 field changedInput schema / properties / extra_argsRemoved value: -{
- "description": "Additional configuration parameters for agent execution (optional)",
- "items": {
- "type": "string"
- },
- "type": "array"
-}v1.0.0run_agent5 fields changedInput schema / properties / agent / descriptionPrevious value: -"Identifier of the specialized agent to delegate the task to"New value: +"Agent name exactly as listed in list_agents resource."Input schema / properties / cwd / descriptionPrevious value: -"Working directory path for agent execution context (optional)"New value: +"Working directory path for agent execution context. Must be an absolute path to a valid directory."Input schema / properties / prompt / descriptionPrevious value: -"Task description or instructions for the agent to execute. When referencing file paths, use absolute paths to ensure proper file access."New value: +"User's direct request content. Agent context is separately provided via agent parameter."Input schema / properties / session_idAdded value: +{
+ "description": "Session ID for continuing previous conversation context (optional). If omitted, a new session will be auto-generated and returned in response metadata. Reuse the returned session_id in subsequent calls to maintain context continuity.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "agent",
- "prompt"
-]New value: +[
+ "agent",
+ "prompt",
+ "cwd"
+]run_agentScored across 1 tool
With only one tool, there is no possibility of confusion or misselection between tools. The tool's purpose is clearly described and stands alone.
The single tool name 'run_agent' is clear and follows a conventional verb_noun style. There are no other names to contradict a consistent pattern.
A single tool for a server called 'Task Agents' is too few for the apparent scope. Users cannot list, manage, or monitor agents, making the toolset feel extremely thin.
The server provides only an invocation operation with no lifecycle management—no status checks, cancellation, listing, or result retrieval mechanisms. This is severely incomplete for a task-agent-oriented server.
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
Agent-native task management: your AI agent is the interface. Delegate to anyone by email.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
