Skip to main content
Glama

Sub-Agents MCP Server

npm version License: MIT

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.

What You Can Do

  • 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: Sub-Agents MCP

Quick Start

You need Node.js 22 or later, an MCP-compatible client, and one supported coding CLI installed and signed in. This example uses Codex.

1. Create an Agent

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 steps

The filename becomes the agent name: code-reviewer.md becomes code-reviewer.

2. Add the MCP Server

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.

3. Run the Agent

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.

Examples

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.

When the MCP Server Fits

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.

Supported Backends

Set AGENT_TYPE to the backend you already use:

AGENT_TYPE

Backend

Command

codex

Codex

codex

claude

Claude Code

claude

cursor

Cursor CLI

cursor-agent

command-code

Command Code

command-code

glm

GLM (Z.ai)

claude

kimi

Kimi

claude

grok

Grok Build

grok

antigravity

Google Antigravity

agy 1.1.12+

gemini

Gemini CLI (compatibility)

gemini

opencode

OpenCode

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.

Shared Agent Settings

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.

Continue Work Across Calls

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.

If It Does Not Start

  • 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

License

MIT

Available Tools

1 tool
run_agentA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdYesWorking directory path for agent execution context. Must be an absolute path to a valid directory.
agentYesAgent name exactly as listed in list_agents resource.
promptYesUser's direct request content. Agent context is separately provided via agent parameter.
extra_argsNoAdditional configuration parameters for agent execution (optional)
session_idNoSession 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.

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must disclose behavioral traits. It mentions autonomous execution and context continuity via session_id, but lacks details on safety (e.g., what gets modified), error handling, or rate limits. The absence of annotations puts more burden on the description, which is only partially fulfilled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first provides purpose and examples, the second explains a key behavior (session_id reuse). It is front-loaded with important information and wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers the response metadata (session_id). It explains the core behavior and parameter usage. However, it could be more complete by mentioning error scenarios, timeouts, or concurrency implications, which are common for agent delegation tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value beyond the schema: it explains the `session_id` parameter's role in maintaining context continuity and how it is returned. It also clarifies the distinction between `prompt` (user request) and `agent` context. This extra context helps agents use parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Delegate') and resource ('multi-step, or specialized tasks to an autonomous agent'), and provides concrete examples (refactoring, fixing test failures, codebase analysis). It clearly distinguishes the tool's purpose as handling autonomous, multi-step tasks, even though no sibling tools are listed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool (complex, multi-step, specialized tasks) and provides examples. It does not include explicit when-not-to-use statements or alternatives, but the context is clear enough without siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • Changedrun_agent5 fields changed
      • changedInput schema / properties / agent / description
        Previous value: -"Identifier of the specialized agent to delegate the task to"New value: +"Agent name exactly as listed in list_agents resource."
      • changedInput schema / properties / cwd / description
        Previous 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."
      • changedInput schema / properties / prompt / description
        Previous 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."
      • addedInput schema / properties / session_id
        Added 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"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "agent",
        -  "prompt"
        -]New value: +[
        +  "agent",
        +  "prompt",
        +  "cwd"
        +]
  2. 1 tool update
    • First observedrun_agent

TDQS

A4.1/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of ambiguity or confusion with other tools.

Naming Consistency5/5

With a single tool, naming consistency is inherently perfect; the name 'run_agent' is descriptive and follows a clear verb_noun pattern.

Tool Count3/5

A single tool is thin for a server named 'Task Agents' which implies multiple task types. While the tool itself is powerful, the count feels borderline for typical multi-step workflows.

Completeness2/5

The server lacks tools for status checking, result retrieval, or cancellation of agent executions. The single tool covers delegation but leaves obvious lifecycle gaps.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shinpr/sub-agents-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server