Click on "Install 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., "@autogen-mcp Register a cheap sub-agent 'code_reviewer' for reviewing pull requests."
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.
AutoGen multi-agent conversations as an MCP server for Claude Code. Two surfaces:
Swarm hierarchy — persistent sub-agents, each owning one task's context, with tiered conversation permissions (heavy agents converse freely; cheap agents route requests through the manager).
Group debates — ad-hoc autonomous round-robin conversations between fresh agents.
Transcripts and per-agent logs are stored per project: in
.autogen-swarm/ inside whatever directory the Claude Code session runs in
(override with the AUTOGEN_MCP_DATA_DIR env var; falls back to this
project's directory if the cwd isn't writable).
The manager is your claude-manager (heavy / GLM-5.2) Claude Code
session — it drives the MCP tools and follows
~/agent-swarm/manager_prompt.md.
Sub-agents are persistent AutoGen agents in this server. Each is
registered with a role (the task it owns) and keeps its conversation
memory for the whole server session; every exchange is appended to
.autogen-swarm/agents/<name>.jsonl in the session's project.
Tiers: heavy agents get a server-side converse tool and can talk
to any other agent directly. cheap agents get no such tool — the server
instructs them to emit NEED_INFO(<task-or-agent>): <question> lines,
which send_message surfaces as info_requests for the manager to relay.
Circular conversations and deep relay chains are blocked server-side.
If tier is omitted at registration, the cheap model alias defaults to
the cheap tier and everything else to heavy.
Related MCP server: Orchestrator MCP Server
cd ~/Documents/projects/claude_code+autogen
uv syncRequired environment variables (in the shell that launches Claude Code):
ANTHROPIC_API_KEY — for anthropic:* / opus participants
DEEPINFRA_API_KEY — for deepinfra:* / heavy / cheap participants
The project-scoped .mcp.json is already in place — any claude session
started in this directory picks up the autogen-chat server automatically
(you'll be asked to approve it once).
It is also registered user-scope (global) in all three Claude Code profiles, so it's available from any directory. User-scope config lives in the profile's config dir, so each profile needs its own registration:
MCPDIR=~/Documents/projects/claude_code+autogen
# default profile
claude mcp add --scope user autogen-chat -- \
uv run --project "$MCPDIR" python "$MCPDIR/server.py"
# manager / worker profiles (separate CLAUDE_CONFIG_DIR)
CLAUDE_CONFIG_DIR=~/.claude-manager claude mcp add --scope user autogen-chat -- \
uv run --project "$MCPDIR" python "$MCPDIR/server.py"
CLAUDE_CONFIG_DIR=~/.claude-worker claude mcp add --scope user autogen-chat -- \
uv run --project "$MCPDIR" python "$MCPDIR/server.py"Note: --project (not --directory) matters — it selects this project's
Python environment while preserving the working directory Claude Code
launches the server with, which is what makes per-project log storage work.
Just ask in natural language.
Swarm workflow (the manager session does this per its prompt):
Register a cheap sub-agent
api_taskowning the REST endpoints and a cheap sub-agentdb_taskowning the schema. Brief each with its scope and acceptance test, then relay any NEED_INFO requests between them.
Group debate:
Start a conversation between opus and heavy about whether we should migrate this repo to a monorepo. 8 rounds. Check on it and summarize when done.
Claude Code will call the tools:
Swarm hierarchy (persistent sub-agents):
Tool | Purpose |
| Create a persistent sub-agent owning one task ( |
| Converse with a sub-agent; result includes |
| Read an agent's exchange history ( |
| Roster with tiers, roles, exchange counts |
| Retire an agent (log file survives) |
Group debates (ad-hoc conversations):
Tool | Purpose |
| Kick off a background group chat, returns an ID |
| Poll new turns ( |
| Queue a steering message, delivered at the next round boundary |
| Cancel a running chat |
| Show all chats in this session |
MCP resources: conversation://<id> and agent://<name> expose full
transcripts as readable text.
Participants take "model" as <provider>:<model> or a shorthand alias:
Alias | Resolves to |
|
|
|
|
|
|
Any DeepInfra model works via deepinfra:<org>/<model> (uses their
OpenAI-compatible endpoint at api.deepinfra.com/v1/openai).
Which shell you launch from decides which providers work. The
claude-cheap/claude-heavy/claude-manager aliases blank
ANTHROPIC_API_KEY, so from those sessions only DeepInfra participants
(heavy, cheap, deepinfra:*) work — which is all the swarm hierarchy
needs. opus / anthropic:* participants require a shell with
ANTHROPIC_API_KEY set (your plain claude). Note the debate default
pair includes opus, so from an alias shell pass explicit agents to
start_conversation. The server pins its base URLs
(api.anthropic.com / DeepInfra), so the aliases' ANTHROPIC_BASE_URL
override can't misroute requests either way. The server is registered
user-scope in all three profiles, so any session in any directory gets
the tools — and its swarm data lands in that session's own
.autogen-swarm/.
Conversations and agent memory die with the session. stdio servers
live as long as the Claude Code session that spawned them. Transcripts
(.autogen-swarm/transcripts/*.jsonl) and agent logs
(.autogen-swarm/agents/*.jsonl) survive on disk in the session's
project, but in-flight chats and sub-agent conversation memory don't —
after a restart, re-register agents and re-brief them (e.g. paste the
relevant log back as the first message). If you want a long-lived daemon,
switch mcp.run() to the streamable-HTTP transport and register the URL
instead.
Sub-agents are chat-only. They think and produce code as text; they
don't touch files. Execution stays with the manager or headless
claude-cheap-yolo workers — report outcomes back into the owning
agent's context so it remains the source of truth.
Steering granularity is one round. inject_message is delivered at the
next round-robin boundary, not mid-turn.
Cost: max_rounds is the guardrail. Two eager models can burn tokens
fast — keep rounds modest and use cheap participants for experiments.
Return a conversation's status and its turns starting at since_turn.
Pass the previous total_turns as since_turn to get only new turns.
| Name | Required | Description | Default |
|---|---|---|---|
| since_turn | No | ||
| conversation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Correctly implies a read operation and specifies output details (status and turns), but lacks disclosure of auth requirements or rate limits. No annotations exist to supplement.
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, no unnecessary words, with the main purpose front-loaded.
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?
Adequate for a simple retrieval tool with two parameters; explains return value and parameter usage. Could mention status details slightly, but not critical.
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?
Despite 0% schema coverage, the description adds meaningful guidance for since_turn with a practical usage pattern. conversation_id is self-evident.
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?
The description clearly states it returns a conversation's status and turns, which distinguishes it from sibling tools that manage messages or agents.
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?
Provides explicit guidance on using since_turn for incremental fetching, but does not elaborate on when to avoid or alternatives beyond sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue a steering message for a running conversation.
Delivered to the agents at the next round boundary (after the current round-robin round completes).
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| conversation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds behavioral context (queued, delivered at round boundary), but fails to disclose side effects, permissions, or whether the message can be canceled, leaving some ambiguity.
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?
The description is two sentences, front-loading the primary action and adding one behavioral detail, with no wasted words.
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 a simple tool with two parameters and no output schema, the description covers the primary purpose and timing but lacks parameter details and return value info, making it adequate but not comprehensive.
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?
With 0% schema coverage, the description does not elaborate on the 'message' or 'conversation_id' parameters (e.g., format, constraints, what constitutes a steering message), leaving agents to infer meaning from type alone.
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?
The description clearly states it queues a steering message for a running conversation, distinguishing it from sibling 'send_message' via the term 'steering', implying a meta-message for agent coordination.
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?
The description implies use for steering messages and specifies delivery timing (after round-robin round), but does not explicitly compare to alternatives like send_message or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all conversations known to this server session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates the scope ('known to this server session') but does not mention whether it is read-only, potential limits, or error conditions. For a simple list tool, this is minimally adequate.
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?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the essential information.
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?
Given the tool has no parameters and an output schema likely describes return values, the description is mostly complete. It could briefly mention that the list is a snapshot or that it does not change state, but overall it suffices for a simple list operation.
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?
There are no parameters, so the schema provides all needed information. The description adds no parameter details, but baseline for 0 parameters is 4. The description does clarify the scope of the list, which is not part of the schema.
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?
The description clearly states the action 'List' and the resource 'conversations', and specifies scope 'known to this server session'. It is distinct from sibling tools like send_message or get_transcript.
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?
No explicit guidance on when to use this tool versus alternatives, but the tool is simple (no parameters) and its purpose is straightforward. Implicitly, it is for retrieving the list of all conversations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unregister an agent and release its model client. Its log file remains.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose all behaviors. Only mentions that log file remains. Does not state irreversibility, required permissions, or effects on active conversations.
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 action, no redundant information. Condensed and efficient.
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?
Simple tool with one param and no output schema, but description omits crucial context: what an 'agent' is in this domain, whether the agent must be inactive, and how to confirm success. Leaves gaps for an AI agent.
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 has one parameter with 0% coverage in description. Description completely fails to explain the 'agent_name' parameter beyond the schema's type and required status.
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?
Clearly states the action ('Unregister an agent and release its model client') and the resource (agent). Distinguishes from siblings which deal with conversations and messages.
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?
No guidance on when to use this tool vs alternatives. Lacks prerequisites or conditions for use. Sibling tools are listed but no explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a registered agent and return its reply (manager channel).
Context persists across calls — the agent remembers previous exchanges.
Check info_requests in the result: any NEED_INFO(...) lines mean the
agent is blocked on information owned by another agent. Fetch the answer
from the responsible agent (another send_message) and relay it back to
the requester with a follow-up send_message.
| Name | Required | Description | Default |
|---|---|---|---|
| sender | No | manager | |
| message | Yes | ||
| agent_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses communication via manager channel, context persistence, result structure including info_requests, and protocol for NEED_INFO.
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?
Five sentences, front-loaded with main action, well-structured. Could be slightly more concise but no wasted words.
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?
Covers persistence, result handling with info_requests, and protocol. No output schema but describes result content well. Complete for complexity level.
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 coverage is 0%, so description must compensate. It adds context for sender (defaults to manager) and agent_name/message, but doesn't describe parameters in detail. Adequate but not fully compensating.
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?
Clear verb 'send', resource 'message to a registered agent', and specifies 'manager channel'. Distinguishes from siblings like inject_message and start_conversation.
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?
Explains context persistence and provides detailed guidance on handling NEED_INFO in responses, though does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an autonomous multi-agent conversation running in the background.
Args: topic: The task or question the agents discuss. agents: Optional participants, each {"name", "model", "system"}. "model" is ":" — e.g. "anthropic:claude-opus-4-8", "deepinfra:zai-org/GLM-5.2" — or an alias: "opus", "heavy", "cheap". Defaults to an opus + GLM-5.2 pair (proponent vs critic). max_rounds: Full round-robin rounds before the conversation ends.
Returns the conversation_id to use with get_transcript / inject_message / stop_conversation. Poll get_transcript to follow progress.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| agents | No | ||
| max_rounds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the conversation runs in the background, returns a conversation_id, and that progress is tracked via polling get_transcript. However, it does not mention any destructive effects, required permissions, or rate limits, which would be helpful for a mutation tool.
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?
The description is well-structured with clear sections (Args, Returns) and front-loaded with the main purpose. Every sentence adds value, and there is no unnecessary verbosity. At around 80 words, it is appropriately sized.
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?
Given the complexity of the tool (multi-agent, async, three parameters), the description covers the essentials: purpose, parameters, return value, and how to monitor progress. It could mention that the conversation proceeds until max_rounds is reached or stopped, but overall it is sufficiently complete.
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?
The schema has 0% description coverage, but the description provides extensive detail for all three parameters: topic, agents (including format and defaults), and max_rounds (including default value). This fully compensates for the schema's lack of descriptions, adding significant meaning.
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?
The description clearly states the tool starts an autonomous multi-agent conversation running in the background. It uses a specific verb ('start') and resource ('multi-agent conversation'), and implicitly distinguishes from sibling tools like send_message or inject_message which operate on an existing conversation.
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?
The description explains when to use the tool (to initiate a background conversation) and references related tools (get_transcript, inject_message, stop_conversation) for post-start actions. It does not explicitly state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a running conversation. The transcript so far is preserved.
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds important behavioral context: the transcript is preserved after cancellation. This is beyond the schema and helps the agent understand side effects.
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 short sentences, no filler. Front-loaded with the action, and the critical preservation detail is included efficiently.
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?
Given the tool's simplicity (1 param, no output schema, no nested objects), the description covers essential behavior. The sibling list provides context for when this tool fits.
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?
The single parameter 'conversation_id' has no description in schema (0% coverage), and the tool description does not add any semantic detail about it. The agent gets no guidance on what value to provide.
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?
The description clearly states the action ('Cancel a running conversation') and resource, and the note about preserving the transcript distinguishes it from potential deletion behaviors. It effectively differentiates from siblings like start_conversation or send_message.
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?
The description implies usage (to stop a conversation) but lacks explicit guidance on when not to use it or alternatives. No comparison to siblings like inject_message or remove_agent is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: sending messages, removing agents, starting/stopping conversations, retrieving transcripts, injecting messages, and listing conversations. No overlapping functionality.
All tool names follow a consistent verb_noun pattern (e.g., send_message, start_conversation, get_transcript) using snake_case throughout.
With 7 tools, the server is well-scoped for multi-agent conversation management. Each tool serves a specific purpose without redundancy or being too thin.
Core conversation lifecycle (start, get transcript, inject message, stop) and agent management (remove) are covered. Minor gaps include lacking an explicit 'list agents' tool or ability to modify agent configurations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/theodieu/claude-code-autogen_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
