Enables the creation of Express.js APIs with features like JWT authentication through subagent delegation
Supports Node.js backend development through specialized subagents that can build server-side logic and APIs
Facilitates React frontend development using dedicated subagents to create components and integrate with backend APIs
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., "@MCP Goose Subagents Server Build a React dashboard with Node.js backend and PostgreSQL database"
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.
An MCP (Model Context Protocol) server that enables AI clients to delegate tasks to autonomous developer teams using Goose CLI subagents.
Delegate to Subagents: Create specialized AI agents for different development roles
Parallel & Sequential Execution: Run agents simultaneously or in sequence
Recipe System: Create reusable agent configurations
Session Management: Track and retrieve results from active subagent sessions
Pure Goose CLI Integration: Uses only Goose CLI for subagent delegation
Related MCP server: MCP Goose Subagents Server
Goose CLI installed and configured
Node.js (v18 or higher)
Alpha features enabled for Goose subagents
npm installAdd this server to your MCP client configuration (e.g., mcp_config.json):
{
"mcpServers": {
"goose-subagents": {
"command": "node",
"args": ["path/to/mcp-goose-subagents/src/index.js"],
"env": {
"ALPHA_FEATURES": "true"
}
}
}
}export ALPHA_FEATURES=truedelegate_to_subagentsDelegate development tasks to specialized Goose subagents.
Parameters:
task (string): The development task to delegate
agents (array): Array of subagent configurations
role (string): Agent role (e.g., "backend_developer", "frontend_developer")
instructions (string): Specific instructions for the agent
recipe (string, optional): Recipe name to use
execution_mode (string): "parallel" or "sequential"
working_directory (string, optional): Working directory for agents
Example:
{
"task": "Build a REST API with authentication",
"agents": [
{
"role": "backend_developer",
"instructions": "Create Express.js API with JWT authentication"
},
{
"role": "database_engineer",
"instructions": "Design and implement user database schema"
},
{
"role": "security_auditor",
"instructions": "Review authentication implementation for security issues"
}
],
"execution_mode": "parallel"
}create_goose_recipeCreate reusable Goose recipes for specialized subagents.
Parameters:
recipe_name (string): Name of the recipe
role (string): Agent role
instructions (string): Detailed instructions
extensions (array, optional): Goose extensions to enable
parameters (object, optional): Recipe parameters
list_active_subagentsList currently active subagent sessions and their status.
get_subagent_resultsRetrieve results from completed subagent sessions.
Parameters:
session_id (string): Session ID to get results for
// Delegate a complete web app development task
{
"task": "Create a todo app with React frontend and Node.js backend",
"agents": [
{
"role": "project_architect",
"instructions": "Design overall architecture and create project structure"
},
{
"role": "backend_developer",
"instructions": "Build REST API with CRUD operations for todos"
},
{
"role": "frontend_developer",
"instructions": "Create React components and integrate with API"
},
{
"role": "qa_engineer",
"instructions": "Write tests and ensure quality standards"
}
],
"execution_mode": "sequential"
}{
"task": "Review authentication module for security and performance",
"agents": [
{
"role": "security_auditor",
"instructions": "Analyze for security vulnerabilities and best practices"
},
{
"role": "performance_reviewer",
"instructions": "Identify performance bottlenecks and optimization opportunities"
},
{
"role": "code_quality_reviewer",
"instructions": "Check code style, maintainability, and documentation"
}
],
"execution_mode": "parallel"
}backend_developer - API development, server-side logic
frontend_developer - UI/UX implementation, client-side code
database_engineer - Schema design, query optimization
devops_engineer - Deployment, CI/CD, infrastructure
qa_engineer - Testing, quality assurance
security_auditor - Security review, vulnerability assessment
code_reviewer - Code quality, best practices
documentation_writer - Technical documentation, API docs
project_architect - System design, architecture planning
ALPHA_FEATURES=true - Required for Goose subagents
GOOSE_RECIPE_PATH - Path to custom recipe directory
Subagents not working: Ensure ALPHA_FEATURES=true is set
Goose not found: Verify Goose CLI is installed and in PATH
Recipe not found: Check GOOSE_RECIPE_PATH or place recipes in working directory
MIT
Create a reusable Goose recipe for specialized subagents
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_name | Yes | Name of the recipe | |
| role | Yes | Agent role (e.g., code_reviewer, security_auditor) | |
| instructions | Yes | Detailed instructions for the agent | |
| extensions | No | List of Goose extensions to enable | |
| parameters | No | Recipe parameters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates something, implying a write operation, but doesn't cover critical aspects like permissions needed, whether recipes are editable or deletable, rate limits, or what happens on success/failure. This is inadequate for a creation tool with zero annotation coverage.
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 any wasted words. It's appropriately sized and front-loaded, making it easy for an agent 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 (5 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain the tool's behavior, output expectations, or how it relates to sibling tools. For a creation tool with rich input schema but no other structured data, 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 fully documents all 5 parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain what 'Goose extensions' are or how 'parameters' are used). Baseline 3 is appropriate when the schema does 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 clearly states the action ('Create') and resource ('reusable Goose recipe for specialized subagents'), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'delegate_to_subagents' or 'list_active_subagents', which prevents a perfect score.
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 'delegate_to_subagents' or 'get_subagent_results'. It lacks context about prerequisites, such as when recipes are needed versus direct delegation, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate tasks to Goose CLI subagents for autonomous development
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The development task to delegate to subagents | |
| agents | Yes | Array of subagents to create | |
| execution_mode | No | How to execute the subagents | parallel |
| working_directory | No | Working directory for the subagents (defaults to current directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only mentions delegation for autonomous development. It omits critical details such as whether this is a read-only or mutating operation, authentication requirements, rate limits, error handling, or what happens after delegation (e.g., asynchronous execution). The description is insufficient for a tool with complex parameters and no output schema.
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 front-loads the core functionality without unnecessary words. It earns its place by clearly stating the tool's purpose, making it appropriately sized and well-structured for quick comprehension.
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 complexity (4 parameters, no output schema, no annotations), the description is incomplete. It fails to explain behavioral traits, return values, or usage context, leaving significant gaps for an agent to understand how to invoke it correctly and what to expect, despite the schema covering parameters.
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 fully documents all parameters. The description adds no additional meaning beyond implying delegation involves tasks and subagents, which aligns with the schema but doesn't enhance understanding of parameter usage or interactions. Baseline 3 is appropriate as 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 tool's purpose as delegating tasks to Goose CLI subagents for autonomous development, specifying both the action (delegate) and target (subagents). It distinguishes from siblings like create_goose_recipe (recipe creation) and get_subagent_results (result retrieval), but doesn't explicitly contrast with list_active_subagents (listing 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?
The description provides no guidance on when to use this tool versus alternatives like get_subagent_results for checking outcomes or list_active_subagents for monitoring. It lacks context about prerequisites, appropriate scenarios, or exclusions, offering only a basic functional statement without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get results from completed subagents
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID to get results for |
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 tool retrieves results but doesn't clarify what 'results' entail (e.g., data format, success/failure status), whether it's idempotent, or if there are rate limits or authentication requirements. This leaves significant gaps in understanding the tool's 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 with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every part of the description contributes directly to understanding the tool's function.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'results' include (e.g., structured data, error messages), how to interpret them, or any behavioral nuances. Given the complexity of handling subagent results, more context is needed to make the tool usable without trial and error.
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 input schema has 100% description coverage, with the single parameter 'session_id' documented as 'Session ID to get results for'. The description adds no additional meaning beyond this, such as explaining session ID format or constraints. Given the high schema coverage, a baseline score of 3 is appropriate.
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 ('Get results') and resource ('from completed subagents'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'list_active_subagents' or 'delegate_to_subagents', which might handle similar subagent-related operations.
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. It doesn't mention prerequisites (e.g., that subagents must be completed), exclusions, or comparisons to sibling tools like 'list_active_subagents' for active subagents or 'delegate_to_subagents' for initiating tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently active subagents and their status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the action ('List') but doesn't describe what 'active' means, how status is reported, whether this is a read-only operation, or any limitations like rate limits. This leaves significant gaps for a tool that might involve dynamic system state.
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 front-loads the core purpose with zero wasted words. It's appropriately sized for a simple listing tool with no parameters.
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 listing active subagents (which involves dynamic system state), no annotations, and no output schema, the description is incomplete. It doesn't explain what information is returned, how 'active' is defined, or any behavioral aspects, leaving the agent with insufficient context for reliable 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no required inputs by not mentioning any, earning a baseline score for zero-parameter tools.
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 ('List') and resource ('currently active subagents and their status'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'get_subagent_results' which might retrieve specific results rather than list active agents, but the distinction isn't explicit.
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 like 'get_subagent_results' or 'delegate_to_subagents'. The description implies usage for checking active subagents, but lacks explicit context, prerequisites, or exclusions.
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.
create_goose_recipedelegate_to_subagentsget_subagent_resultslist_active_subagentsScored across 4 tools
Each tool has a clearly distinct purpose: create_goose_recipe focuses on recipe creation, delegate_to_subagents handles task delegation, get_subagent_results retrieves results, and list_active_subagents monitors subagent status. There is no overlap or ambiguity between these functions.
All tool names follow a consistent verb_noun pattern with clear, descriptive actions: create_goose_recipe, delegate_to_subagents, get_subagent_results, and list_active_subagents. The naming is uniform and predictable throughout the set.
With 4 tools, the count is reasonable for managing subagents, covering creation, delegation, monitoring, and result retrieval. It is slightly lean but well-scoped, as each tool serves a distinct role without redundancy.
The tool set covers core workflows for subagent management: creation, delegation, status listing, and result fetching. Minor gaps might include updating or deleting recipes or subagents, but these are not critical for basic operations and agents can work around them.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
