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 "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., "@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 the full burden of behavioral disclosure. It mentions 'autonomous development' but doesn't explain what happens during delegation—whether subagents run independently, how errors are handled, if there are rate limits, or what permissions are required. For a tool that presumably creates and manages subprocesses, this lack of operational detail is a significant gap.
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 states the core purpose without redundancy. It's front-loaded with the main action and resource, and every word earns its place. No unnecessary elaboration or repetition exists.
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 delegating tasks to subagents, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how to monitor delegated tasks, or error handling. For a tool with 4 parameters and nested agent objects, 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 fully documents all 4 parameters. The description adds no additional meaning beyond the schema's details about task, agents, execution mode, or working directory. It doesn't clarify parameter interactions or provide examples. 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 verb ('delegate') and resource ('tasks to Goose CLI subagents') with a specific purpose ('for autonomous development'). It distinguishes from siblings like 'create_goose_recipe' or 'get_subagent_results' by focusing on task delegation rather than recipe creation or result retrieval. However, it could be more specific about what types of development tasks are appropriate.
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_goose_recipe' for recipe management or 'get_subagent_results' for retrieving outcomes. There's no mention of prerequisites, typical use cases, or scenarios where delegation is preferred over direct execution. The agent must infer usage from the tool name alone.
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 tool lists active subagents and their status, implying a read-only operation, but doesn't specify whether this requires permissions, how status is defined, or what the return format looks like. This leaves significant gaps for a 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 front-loaded and 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 tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic listing operation. However, it lacks details on output format, status definitions, or how it relates to sibling tools, which could help the agent use it more effectively in context.
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 appropriately doesn't add parameter details, as none are needed, earning a baseline score of 4 for not introducing unnecessary information.
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 tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_subagent_results' or explain how this differs from 'delegate_to_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 'get_subagent_results' or 'delegate_to_subagents'. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.
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: 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lordstyled55/goose-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
