MicrosoftのAutoGenフレームワークとの統合を提供するMCPサーバー。標準化されたインターフェースを通じてマルチエージェント対話を実現します。このサーバーを使用すると、自然言語による対話を通じて連携し、問題を解決できるAIエージェントを作成・管理できます。
カスタマイズ可能な構成で AutoGen エージェントを作成および管理します
エージェント間の1対1の会話を実行する
複数のエージェントによるグループチャットのオーケストレーション
構成可能なLLM設定とコード実行環境
アシスタントとユーザープロキシエージェントの両方をサポート
組み込みのエラー処理と応答検証
Related MCP server: Stellastra MCP Server
リポジトリをクローンします。
git clone https://github.com/yourusername/autogen-mcp.git
cd autogen-mcp依存関係をインストールします:
pip install -e ..env.exampleを.envにコピーします。
cp .env.example .env環境変数を設定します。
# Path to the configuration file
AUTOGEN_MCP_CONFIG=config.json
# OpenAI API Key (optional, can also be set in config.json)
OPENAI_API_KEY=your-openai-api-keyconfig.json.exampleをconfig.jsonにコピーします。
cp config.json.example config.jsonサーバー設定を構成します。
{
"llm_config": {
"config_list": [
{
"model": "gpt-4",
"api_key": "your-openai-api-key"
}
],
"temperature": 0
},
"code_execution_config": {
"work_dir": "workspace",
"use_docker": false
}
}サーバーは主に 3 つの操作をサポートしています。
{
"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."
}
}一般的なエラーのシナリオは次のとおりです。
エージェント作成エラー
{
"error": "Agent already exists"
}実行エラー
{
"error": "Agent not found"
}構成エラー
{
"error": "AUTOGEN_MCP_CONFIG environment variable not set"
}サーバーはモジュラー アーキテクチャに従います。
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ファイルを参照
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.
v1.0.0create_agentcreate_streaming_workflowexecute_workflowstart_streaming_chatScored across 4 tools
The 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.
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.