Provides optional Docker-based code execution environment for the agents when executing code as part of conversations
Supports environment variable configuration through .env files for managing API keys and server settings
Supports installation via git clone from a repository
Hosts the server repository, enabling installation directly from GitHub
Enables integration with OpenAI models (like GPT-4) for agent conversations, with configurable LLM settings including model selection and temperature
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 Server create a code review workflow for my Python script"
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.
A comprehensive MCP server that provides deep integration with Microsoft's AutoGen framework v0.9+, featuring the latest capabilities including prompts, resources, advanced workflows, and enhanced agent types. This server enables sophisticated multi-agent conversations through a standardized Model Context Protocol interface.
Prompts: Pre-built templates for common workflows (code review, research, creative writing)
Resources: Real-time access to agent status, chat history, and configurations
Dynamic Content: Template-based prompts with arguments and embedded resources
Latest MCP SDK: Version 1.12.3 with full feature support
Assistant Agents: Enhanced with latest LLM capabilities
Conversable Agents: Flexible conversation patterns
Teachable Agents: Learning and memory persistence
Retrievable Agents: Knowledge base integration
Multimodal Agents: Image and document processing (when available)
Code Generation: Architect ā Developer ā Reviewer ā Executor pipeline
Research Analysis: Researcher ā Analyst ā Critic ā Synthesizer workflow
Creative Writing: Multi-stage creative collaboration
Problem Solving: Structured approach to complex problems
Code Review: Security ā Performance ā Style review teams
Custom Workflows: Build your own agent collaboration patterns
Smart Speaker Selection: Auto, manual, random, round-robin modes
Nested Conversations: Hierarchical agent interactions
Swarm Intelligence: Coordinated multi-agent problem solving
Memory Management: Persistent agent knowledge and preferences
Quality Checks: Built-in validation and improvement loops
Related MCP server: Stellastra MCP Server
create_agent - Create agents with advanced configurations
create_workflow - Build complete multi-agent workflows
get_agent_status - Detailed agent metrics and health monitoring
execute_chat - Enhanced two-agent conversations
execute_group_chat - Multi-agent group discussions
execute_nested_chat - Hierarchical conversation structures
execute_swarm - Swarm-based collaborative problem solving
execute_workflow - Run predefined workflow templates
manage_agent_memory - Handle agent learning and persistence
configure_teachability - Enable/configure agent learning capabilities
autogen-workflowCreate sophisticated multi-agent workflows with customizable parameters:
Arguments: task_description, agent_count, workflow_type
Use case: Rapid workflow prototyping and deployment
code-reviewSet up collaborative code review with specialized agents:
Arguments: code, language, focus_areas
Use case: Comprehensive code quality assessment
research-analysisDeploy research teams for in-depth topic analysis:
Arguments: topic, depth
Use case: Academic research, market analysis, technical investigation
autogen://agents/listLive list of active agents with status and capabilities
autogen://workflows/templatesAvailable workflow templates and configurations
autogen://chat/historyRecent conversation history and interaction logs
autogen://config/currentCurrent server configuration and settings
To install AutoGen Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @DynamicEndpoints/autogen_mcp --client claudeClone the repository:
git clone https://github.com/yourusername/autogen-mcp.git
cd autogen-mcpInstall Node.js dependencies:
npm installInstall Python dependencies:
pip install -r requirements.txt --userBuild the TypeScript project:
npm run buildSet up configuration:
cp .env.example .env
cp config.json.example config.json
# Edit .env and config.json with your settingsCreate a .env file from the template:
# Required
OPENAI_API_KEY=your-openai-api-key-here
# Optional - Path to configuration file
AUTOGEN_MCP_CONFIG=config.json
# Enhanced Features
ENABLE_PROMPTS=true
ENABLE_RESOURCES=true
ENABLE_WORKFLOWS=true
ENABLE_TEACHABILITY=true
# Performance Settings
MAX_CHAT_TURNS=10
DEFAULT_OUTPUT_FORMAT=jsonUpdate config.json with your preferences:
{
"llm_config": {
"config_list": [
{
"model": "gpt-4o",
"api_key": "your-openai-api-key"
}
],
"temperature": 0.7
},
"enhanced_features": {
"prompts": { "enabled": true },
"resources": { "enabled": true },
"workflows": { "enabled": true }
}
}Add to your claude_desktop_config.json:
{
"mcpServers": {
"autogen": {
"command": "node",
"args": ["path/to/autogen-mcp/build/index.js"],
"env": {
"OPENAI_API_KEY": "your-key-here"
}
}
}
}Test the server functionality:
# Run comprehensive tests
python test_server.py
# Test CLI interface
python cli_example.py create_agent "researcher" "assistant" "You are a research specialist"
python cli_example.py execute_workflow "code_generation" '{"task":"Hello world","language":"python"}'The server provides several built-in prompts:
autogen-workflow - Create multi-agent workflows
code-review - Set up collaborative code review
research-analysis - Deploy research teams
Available resources provide real-time data:
autogen://agents/list - Current active agents
autogen://workflows/templates - Available workflow templates
autogen://chat/history - Recent conversation history
autogen://config/current - Server configuration
{
"workflow_name": "code_generation",
"input_data": {
"task": "Create a REST API endpoint",
"language": "python",
"requirements": ["FastAPI", "Pydantic", "Error handling"]
},
"quality_checks": true
}{
"workflow_name": "research",
"input_data": {
"topic": "AI Ethics in 2025",
"depth": "comprehensive"
},
"output_format": "markdown"
}Assistant Agents: LLM-powered conversational agents
User Proxy Agents: Code execution and human interaction
Conversable Agents: Flexible conversation patterns
Teachable Agents: Learning and memory persistence (when available)
Retrievable Agents: Knowledge base integration (when available)
Two-Agent Chat: Direct conversation between agents
Group Chat: Multi-agent discussions with smart speaker selection
Nested Chat: Hierarchical conversation structures
Swarm Intelligence: Coordinated problem solving (experimental)
Persistent agent memory across sessions
Conversation history tracking
Learning from interactions (teachable agents)
Memory cleanup and optimization
API Key Errors: Ensure your OpenAI API key is valid and has sufficient credits
Import Errors: Install all dependencies with pip install -r requirements.txt --user
Build Failures: Check Node.js version (>= 18) and run npm install
Chat Failures: Verify agent creation succeeded before attempting conversations
Enable detailed logging:
export LOG_LEVEL=DEBUG
python test_server.pyUse gpt-4o-mini for faster, cost-effective operations
Enable caching for repeated operations
Set appropriate timeout values for long-running workflows
Use quality checks only when needed (increases execution time)
# Full test suite
python test_server.py
# Individual workflow tests
python -c "
import asyncio
from src.autogen_mcp.workflows import WorkflowManager
wm = WorkflowManager()
print(asyncio.run(wm.execute_workflow('code_generation', {'task': 'test'})))
"npm run build
npm run lintFork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Submit a pull request
āØ Enhanced MCP support with prompts and resources
š¤ Advanced agent types (teachable, retrievable)
š Sophisticated workflows with quality checks
šÆ Smart speaker selection and nested conversations
š Real-time resource monitoring
š§ Memory management and persistence
Basic AutoGen integration
Simple agent creation and chat execution
MCP tool interface
For issues and questions:
Check the troubleshooting section above
Review the test examples in test_server.py
Open an issue on GitHub with detailed reproduction steps
MIT License - see LICENSE file for details.
OPENAI_API_KEY=your-openai-api-key
### Server Configuration
1. Copy `config.json.example` to `config.json`:
```bash
cp config.json.example config.jsonConfigure the server settings:
{
"llm_config": {
"config_list": [
{
"model": "gpt-4",
"api_key": "your-openai-api-key"
}
],
"temperature": 0
},
"code_execution_config": {
"work_dir": "workspace",
"use_docker": false
}
}The server supports three main operations:
{
"name": "create_agent",
"arguments": {
"name": "tech_lead",
"type": "assistant",
"system_message": "You are a technical lead with expertise in software architecture and design patterns."
}
}{
"name": "execute_chat",
"arguments": {
"initiator": "agent1",
"responder": "agent2",
"message": "Let's discuss the system architecture."
}
}{
"name": "execute_group_chat",
"arguments": {
"agents": ["agent1", "agent2", "agent3"],
"message": "Let's review the proposed solution."
}
}Common error scenarios include:
Agent Creation Errors
{
"error": "Agent already exists"
}Execution Errors
{
"error": "Agent not found"
}Configuration Errors
{
"error": "AUTOGEN_MCP_CONFIG environment variable not set"
}The server follows a modular architecture:
src/
āāā autogen_mcp/
ā āāā __init__.py
ā āāā agents.py # Agent management and configuration
ā āāā config.py # Configuration handling and validation
ā āāā server.py # MCP server implementation
ā āāā workflows.py # Conversation workflow managementMIT License - See LICENSE file for details
Create a new AutoGen agent
| Name | Required | Description | Default |
|---|---|---|---|
| llm_config | No | LLM configuration | |
| name | Yes | Unique name for the agent | |
| system_message | No | System message | |
| type | Yes | Agent type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Create') but doesn't describe what happens after creation (e.g., whether the agent is immediately active, stored, or requires further steps), error conditions, or side effects. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by conveying essential information concisely.
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 creating an agent (a mutation operation with 4 parameters, no output schema, and no annotations), the description is insufficient. It doesn't cover behavioral aspects like what the tool returns, error handling, or how the created agent integrates with other tools (e.g., 'start_streaming_chat'). For a creation tool, more context is needed to guide effective use.
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 the schema already documents all 4 parameters with basic descriptions. The description adds no additional meaning about parameters beyond what the schema provides, such as explaining the significance of 'type' or how 'llm_config' should be structured. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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 verb ('Create') and resource ('new AutoGen agent'), making the purpose immediately understandable. It distinguishes from siblings like 'create_streaming_workflow' by specifying the resource type, though it doesn't explicitly contrast them. The description avoids tautology by not just restating the tool name.
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 provides no guidance on when to use this tool versus alternatives like 'create_streaming_workflow' or 'execute_workflow'. It doesn't mention prerequisites, dependencies, or scenarios where this tool is preferred. Usage is implied only by the tool name and description, with no explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a workflow with real-time streaming
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | List of agent configurations | |
| streaming | No | Enable streaming | |
| workflow_name | Yes | Name for the workflow | |
| workflow_type | Yes | Type of workflow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create' which implies a write/mutation operation but doesn't disclose behavioral traits such as permissions needed, whether the workflow is immediately active, error handling, or rate limits. The mention of 'real-time streaming' hints at ongoing behavior but lacks specifics.
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, efficient sentence with no wasted words. It is front-loaded with the core purpose ('Create a workflow') and adds a distinguishing feature ('with real-time streaming') concisely.
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 no annotations and no output schema, the description is incomplete for a tool that creates workflows with streaming. It doesn't cover what the tool returns, error conditions, or the implications of 'real-time streaming' in practice. For a mutation tool with multiple parameters, more context is needed.
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 the schema already documents all parameters. The description adds no additional meaning beyond implying that 'streaming' is a key feature, but it doesn't explain parameter interactions, defaults, or usage examples. Baseline 3 is appropriate as the schema handles parameter documentation.
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 ('Create') and resource ('workflow') with a distinguishing feature ('with real-time streaming'). It differentiates from siblings like 'create_agent' and 'execute_workflow' by focusing on workflow creation with streaming capabilities, though it doesn't explicitly contrast with 'start_streaming_chat'.
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 provides no guidance on when to use this tool versus alternatives like 'create_agent' or 'execute_workflow'. It mentions 'real-time streaming' but doesn't specify prerequisites, exclusions, or contextual scenarios for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a workflow with streaming support
| Name | Required | Description | Default |
|---|---|---|---|
| input_data | Yes | Input data | |
| streaming | No | Enable streaming | |
| workflow_name | Yes | Workflow name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'streaming support', which hints at real-time output or progressive processing, but fails to detail critical aspects such as permissions needed, whether execution is destructive or idempotent, rate limits, or what happens on failure. This is a significant gap for a tool that likely performs operations.
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, efficient sentence with zero waste. It's front-loaded with the core action and includes a key feature (streaming support), making it appropriately sized and easy to parse quickly.
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 executing workflows (likely involving processing and mutations), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, return values, and how it differs from siblings. This leaves the agent under-informed for safe and effective use.
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 the schema already documents all three parameters (workflow_name, input_data, streaming). The description adds no additional meaning beyond implying that 'streaming' is a feature, but doesn't explain parameter interactions or provide examples. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 'Execute a workflow with streaming support' states the action (execute) and resource (workflow), but is vague about what 'execute' entails (e.g., run, trigger, process) and doesn't differentiate from siblings like 'create_agent' or 'start_streaming_chat'. It mentions streaming support, which adds some specificity but lacks detail on the workflow's nature or scope.
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 is provided on when to use this tool versus alternatives. The description implies streaming is optional, but it doesn't specify scenarios for using streaming versus non-streaming, nor does it reference sibling tools like 'create_streaming_workflow' or 'start_streaming_chat' for context. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a streaming chat session
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | Name of the agent | |
| message | Yes | Initial message | |
| streaming | No | Enable streaming |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'streaming' but doesn't explain what that means operationally (e.g., real-time responses, event-driven flow, or connection handling). It also lacks details on permissions, rate limits, session management, or what 'start' implies (e.g., does it return a session ID?). This leaves significant gaps for a tool that likely involves ongoing interaction.
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 extremely concise with just four words: 'Start a streaming chat session'. It's front-loaded with the core action and resource, with no wasted words or redundant information. This efficiency is appropriate given the tool's straightforward name.
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 a streaming chat tool (likely involving real-time interaction and session management), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like how streaming works, what the output looks like, error handling, or session lifecycle. This leaves the agent under-informed for effective tool invocation.
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 the input schema already documents all three parameters (agent_name, message, streaming) with clear descriptions. The tool description adds no additional meaning beyond what's in the schema, such as explaining how parameters interact (e.g., whether 'streaming' overrides agent settings) or providing usage examples. This meets the baseline for high schema coverage.
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 'Start a streaming chat session' clearly states the action (start) and resource (streaming chat session), but it's somewhat vague about what 'streaming chat' entails compared to regular chat. It doesn't differentiate from sibling tools like 'create_streaming_workflow' or 'execute_workflow', leaving ambiguity about when to use this versus those alternatives.
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 provides no guidance on when to use this tool versus sibling tools like 'create_agent', 'create_streaming_workflow', or 'execute_workflow'. There's no mention of prerequisites, alternatives, or specific contexts where this tool is appropriate, leaving the agent to guess based on tool names alone.
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. Dates show when Glama detected each change.
v1.0.0create_agentcreate_streaming_workflowexecute_workflowstart_streaming_chatThe tools have mostly distinct purposes, but there is some potential for confusion between 'create_streaming_workflow' and 'execute_workflow' as they both involve workflows, though one is for creation and the other for execution. The other tools ('create_agent' and 'start_streaming_chat') are clearly separate in function.
All tool names follow a consistent verb_noun pattern (e.g., create_agent, create_streaming_workflow, execute_workflow, start_streaming_chat). The naming is predictable and readable throughout the set.
With only 4 tools, the set feels thin for an AutoGen MCP server, which might be expected to handle more complex agent and workflow operations. However, it covers basic creation and execution tasks, so it's borderline but not severely lacking.
The tools cover creation and execution of agents and workflows, but there are notable gaps such as updating or deleting agents/workflows, managing existing sessions, or handling non-streaming operations. This could lead to agent failures in more complex scenarios.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server for AI dialogue using various LLM models via AceDataCloud
An MCP server that integrates with Discord to provide AI-powered features.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DynamicEndpoints/Autogen_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server