What can you do with this server?

This MCP server enables an LLM to act as a CrewAI orchestrator, managing the full lifecycle of agent crews — from creation and templating to execution, debugging, and optimization — via 15 tools and a RAG knowledge engine. Project Management * Create new CrewAI crew or flow projects, scaffold directory structure, pyproject.toml, and YAML configs (crewai_create_project) * Install dependencies and optional extra packages (crewai_install_deps) * Inspect a project's dependencies, YAML configs, and source files (crewai_project_info) Templating * Apply prebuilt crew templates (e.g., 5-agent CyberOps MVP) to instantly scaffold a full team (crewai_apply_template) Agents & Tasks * Define agents with custom roles, goals, backstories, LLMs, and tools (crewai_define_agent) * Define tasks with descriptions, expected outputs, assigned agents, and context dependencies (crewai_define_task) * Modify agent parameters in crew.py (LLM, tools, custom constructor args) (crewai_edit_crew_py) Execution & Flows * Kick off a crew with optional input variables (crewai_kickoff) * Generate an interactive HTML visualization of a flow's states and transitions (crewai_flow_plot) * Execute a flow project with optional inputs (crewai_flow_run) Knowledge & Memory * Query a RAG-indexed database of 266+ CrewAI documentation articles (crewai_query_knowledge) * Reset or check the status of project memory (crewai_manage_memory) Debugging & Optimization * Test crew output quality over multiple iterations using an LLM judge (crewai_test_crew) * Run human-in-the-loop training to improve agent prompts (crewai_train_crew) * Replay a specific failed task by ID without restarting the entire crew (crewai_replay_task) It connects via stdio or SSE to any MCP client (Claude Desktop, Cursor, Roo Code, etc.).

Which integrations are available for this server?

Allows orchestration of CrewAI multi-agent projects, including creating projects, defining agents and tasks, running flows, and querying documentation via RAG.

How do I use CrewAI MCP Orchestrator?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CrewAI MCP Orchestrator Create a new crew project for content writing" 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.

CrewAI MCP Orchestrator

by ssolis-ti

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

🚀 CrewAI MCP Orchestrator

MCP server that turns any LLM into a CrewAI orchestrator. 18 tools, prebuilt crew templates, multi-agent LLM routing, and RAG engine with 266+ indexed docs.

📖 Documentation: English · Español

⚡ Install

git clone https://github.com/ssolis-ti/crewai-mcp-hq.git
cd crewai-mcp-hq
uv sync

Related MCP server: Code-MCP

🔌 Connect to MCP Clients

Hermes Agent

hermes mcp add crewai-orchestrator \
  --command "/path/to/crewai-mcp-hq/.venv/Scripts/python.exe"
  --args "-X utf8 -m crewai_mcp.server"

Claude Desktop / Cursor / Roo Code

{
  "mcpServers": {
    "crewai-orchestrator": {
      "command": "/path/to/crewai-mcp-hq/.venv/bin/python",
      "args": ["-m", "crewai_mcp.server"],
      "cwd": "/path/to/crewai-mcp-hq",
      "env": { "CREWAI_MCP_TRANSPORT": "stdio" }
    }
  }
}

Docker (SSE)

docker-compose up -d
# Available at http://localhost:8808/sse

🧰 Tools (18)

Domain	Tools
Projects	`crewai_create_project`, `crewai_install_deps`, `crewai_project_info`
Templates	`crewai_apply_template`
Agents & Tasks	`crewai_define_agent`, `crewai_define_task`, `crewai_edit_crew_py`, `crewai_kickoff`
LLM Routing	`crewai_configure_llm_provider`, `crewai_assign_llms`, `crewai_list_agents`
Flows	`crewai_flow_plot`, `crewai_flow_run`
Knowledge	`crewai_query_knowledge`, `crewai_manage_memory`
Observability	`crewai_test_crew`, `crewai_train_crew`, `crewai_replay_task`

🔀 LLM Routing (multi-agent, multi-select)

Connect a provider once, then route models to any subset of agents:

# 1. Connect the project to a provider (writes the .env layout)
crewai_configure_llm_provider("my-team", provider="litellm-proxy",
                              api_base="http://localhost:4000")
# presets: openai · anthropic · gemini · groq · ollama · openrouter · bifrost · litellm-proxy

# Bifrost gateway in Docker? One call — default base http://localhost:8080/v1,
# and the gateway holds the real provider keys (client key can be a dummy):
crewai_configure_llm_provider("my-team", provider="bifrost")

# 2. See agent names and current models
crewai_list_agents("my-team")

# 3. Route — three modes:
crewai_assign_llms("my-team", llm="openai/gpt-4o")                        # ALL agents
crewai_assign_llms("my-team", llm="groq/llama-3.3-70b-versatile",
                   agents=["researcher", "writer"])                       # multi-select
crewai_assign_llms("my-team", assignments={                               # per-agent map
    "prd_architect": "openai/deepseek-ai/deepseek-v4-pro",
    "ai_developer":  "openai/meta/llama-4-maverick-17b-128e-instruct",
    "qa_reviewer":   "openai/meta/llama-3.1-70b-instruct",
})

Routing updates agents.yaml and any hardcoded llm= override in crew.py (which would otherwise silently win over YAML). API keys are never required in the tool call — placeholders are written to .env for the user to fill in.

🧩 Prebuilt Crew Templates

Deploy a full team in one call — no per-agent setup:

crewai_create_project(name="my-mvp", project_type="crew")
crewai_apply_template(project_name="my-mvp", template_name="cyberops")
# agents.yaml, tasks.yaml, and crew.py ready to run

CyberOps — MVP Development Team

5-agent sequential crew. Input: project description. Output: PRD + architecture + code + docs + QA.

Agent	Role	Configurable
PRD_Architect	Requirements & user stories	LLM, tools, max_iter
System_Designer	Architecture (ADRs, C4, API)	LLM, tools, max_iter
AI_Developer	AI-first code (<100 lines/file)	LLM, tools, max_iter
Doc_Engineer	LLM-optimized documentation	LLM, tools, max_iter
QA_Reviewer	Quality audit & traceability	LLM, tools, max_iter

🗺️ Deployment Workflow (with your AI assistant)

The logical order to deploy a team of agents using the MCP. Just tell your assistant "I need a team for X" and it handles the rest:

1. CREATE      crewai_create_project("my-team", "crew")
                ↓
2. TEMPLATE    crewai_apply_template("my-team", "cyberops")
                ↓
3. INSTALL     crewai_install_deps("my-team")
                ↓
4. KICKOFF     crewai_kickoff("my-team", inputs={...})
                ↓
5. ITERATE     crewai_test_crew / crewai_replay_task / crewai_train_crew

Step-by-step with your AI assistant

Step	What you say	Tool called
Research	"I need a team to build [project]"	`crewai_query_knowledge` — assistant researches CrewAI docs
Scaffold	"Create the project"	`crewai_create_project` — directory + pyproject.toml
Template	"Apply CyberOps template"	`crewai_apply_template` — agents + tasks + crew.py
Customize	"Change AI_Developer to use gpt-4"	`crewai_edit_crew_py` — per-agent LLM/tools config
Install	"Install dependencies"	`crewai_install_deps` — pip/uv sync
Run	"Execute the crew"	`crewai_kickoff` — agents work sequentially
Debug	"QA agent failed — retry it"	`crewai_replay_task` — resumes from failed task
Improve	"Test and train"	`crewai_test_crew` / `crewai_train_crew`

Building a custom team from scratch

No prebuilt template? Define agents and tasks one by one:

1. CREATE     crewai_create_project("my-custom", "crew")
2. AGENTS     crewai_define_agent("my-custom", "researcher", role="...")
              crewai_define_agent("my-custom", "writer", role="...")
3. TASKS      crewai_define_task("my-custom", "research", agent="researcher")
              crewai_define_task("my-custom", "write", agent="writer")
4. INSTALL    crewai_install_deps("my-custom")
5. KICKOFF    crewai_kickoff("my-custom", inputs={...})

🤖 LLM Playbook — step-by-step instructions for the agent using this MCP

The server ships these instructions in its MCP instructions field, so any compliant client injects them into the LLM automatically. This section documents the same contract for humans and for system prompts.

Golden path (mandatory order)

#	Step	Tool	Precondition	Postcondition
1	Research (optional)	`crewai_query_knowledge(query)`	—	Relevant CrewAI patterns known
2	Create	`crewai_create_project(name, "crew"\|"flow")`	Project must not exist	Scaffold in workspace
3	Configure	`crewai_apply_template` or `crewai_define_agent` + `crewai_define_task`	Project exists	`agents.yaml`, `tasks.yaml`, `crew.py` ready
4	Connect LLMs	`crewai_configure_llm_provider(project, provider, api_base=...)`, then `crewai_assign_llms` (see LLM Routing)	Step 3 done	Provider in `.env`, models routed per agent
5	Tune (optional)	`crewai_edit_crew_py(project, agent, llm=..., tools=[...])`	Agent method exists in `crew.py`	Per-agent LLM/tools set
6	Prepare	User sets API keys in project `.env`, then `crewai_install_deps(project)`	Step 3 done	Venv ready, deps resolved
7	Run	`crewai_kickoff(project, inputs={...})`	Steps 3+6 done, keys set	Crew output returned
8	Debug / improve	`crewai_replay_task`, `crewai_test_crew`, `crewai_train_crew`, `crewai_manage_memory`	A previous run exists	Iterated quality

Decision guide

User wants a full team fast → step 3a: crewai_apply_template. List options first: read crewai://templates/prebuilt/index.
User describes a custom workflow → step 3b: one crewai_define_agent per role, then one crewai_define_task per task (agent= references the agent name; context=[...] chains outputs between tasks).
User has a flow (event-driven, stateful) → crewai_create_project(name, "flow"), visualize with crewai_flow_plot, execute with crewai_flow_run.
Unsure how something works in CrewAI → crewai_query_knowledge before guessing; cite the returned crewai://docs/... URIs.

Invariants (do not violate)

create → configure → install → kickoff — never skip or reorder.
inputs keys in kickoff must match the {placeholders} in the YAML files — verify with crewai_project_info before running.
The LLM cannot set API keys: ask the user to edit the project's .env. A kickoff without keys fails with an auth error — report it, don't retry.
install / kickoff / test / train take minutes — call once and wait; don't fire duplicates.

Error recovery

Symptom	Action
`Error: Project '<x>' not found`	Wrong name or not created yet → `crewai_create_project`
Kickoff fails with auth/API-key error in STDERR	Ask the user to fill the project `.env`, then retry
Kickoff fails mid-run on one task	Fix the config, then `crewai_replay_task(project, task_id)`
`Error: Agent method '<x>' not found in crew.py`	List real names with `crewai_project_info`, retry
Stale or corrupted agent memory	`crewai_manage_memory(project, "reset")`

📚 Documentation Resources

URI	Content
`crewai://docs/index`	266+ docs across 31 categories
`crewai://docs/concepts/agents`	Specific documentation pages
`crewai://docs/search/{query}`	Keyword search
`crewai://templates/index`	Agent, crew & flow templates
`crewai://templates/prebuilt/index`	Full crew templates (CyberOps + extensible)

🛡️ Robustness

Auto-patch versions: crewai create outputs pre-release pins → auto-patched to >=1.14.0
Name normalization: hyphens/underscores handled transparently
Timeouts on all subprocess calls: 120s–1200s depending on operation
Standardized CLI: always uv run crewai, no PATH dependency

📁 Structure

src/crewai_mcp/
├── server.py           ← Entry point (stdio/sse/streamable-http)
├── resources/          ← Docs, templates, prebuilt crews
├── tools/              ← 18 tools + shared utils.py
├── prompts/            ← Guided workflows (design_crew, debug_crew)
└── knowledge/          ← ChromaDB indexer + retriever

📖 Documentación en Español

La documentación de CrewAI está disponible en inglés en docs.crewai.com. Para usar el MCP en español:

El motor RAG indexa docs en inglés pero responde preguntas en cualquier idioma
Los templates de crews aceptan descripciones de proyecto en español
Las herramientas retornan mensajes en inglés; el LLM que consume el MCP traduce al contexto del usuario

Guías rápidas en español:

Guía	Descripción
Instalación y setup	Clonar, instalar dependencias, conectar a tu IDE
Playbook para el LLM	Instrucciones paso a paso que recibe el agente (orden obligatorio, invariantes, recuperación de errores)
CyberOps template	Equipo de 5 agentes para crear MVPs desde cero
Herramientas	Referencia completa de las 15 herramientas
Ejemplo: crear un proyecto	`create_project` + `apply_template` en 2 pasos

📝 License

MIT

Available Tools

14 tools

crewai_create_projectA

Create a new CrewAI project using the official CLI.

This generates the standard scaffolding for a CrewAI project, including pyproject.toml, src directory, yaml configs, and entry points. The project is created inside the configured CrewAI workspace.

Note: The --skip_provider flag is used to avoid interactive prompts. You will need to manually configure the provider API keys in the project's .env file.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Name of the project directory
`project_type`	No	Type of project to create ('crew' or 'flow')	crew
`provider`	No	LLM provider to use (e.g., 'openai', 'anthropic', 'gemini', 'ollama'). Note: This sets up the provider non-interactively via --skip_provider; you'll need to configure API keys in the project's .env file after creation.	openai

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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 tool uses CLI, creates scaffolding in a workspace, and skips provider prompts. However, it doesn't mention behavior on existing projects, error handling, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs, front-loaded with the main action. Every sentence provides essential information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the task complexity and that an output schema exists, the description adequately covers purpose, creation steps, and post-creation key configuration. It could mention return values or success indicators but is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, baseline is 3. The description adds meaningful context beyond the schema by explaining the --skip_provider flag, the need to configure API keys, and that provider sets up non-interactively. This adds value for the provider parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it creates a new CrewAI project using CLI and generates standard scaffolding. This clearly distinguishes it from sibling tools focused on agents, tasks, or running flows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions the --skip_provider flag and the need to manually configure API keys. While it doesn't explicitly list when not to use this tool, the context is clear and no sibling tools overlap in purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_define_agentD

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes
`agent_name`	Yes
`role`	Yes
`goal`	Yes
`backstory`	Yes
`llm`	No
`options`	No
`tools`	No
`add_to_crew_py`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_define_taskD

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes
`task_name`	Yes
`description`	Yes
`expected_output`	Yes
`agent`	Yes
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_edit_crew_pyB

Edit the crew.py file to add tools, LLM, or other parameters to a specific agent.

This tool modifies the agent method in crew.py to include custom tools, LLM configuration, or other agent parameters that can't be set via YAML alone.

Args: project_name: Name of the project agent_name: Name of the agent method to modify (e.g., 'researcher') tools: List of tool import strings (e.g., ['SerperDevTool()', 'WebsiteSearchTool()']) llm: LLM model string (e.g., 'gpt-4o', 'claude-3-5-sonnet') function_calling_llm: Function calling LLM model string other_params: Additional parameters to pass to the Agent constructor

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes
`agent_name`	Yes
`tools`	No
`llm`	No
`function_calling_llm`	No
`other_params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It states the tool modifies the agent method in crew.py, but lacks details on whether changes are destructive, reversible, require project existence, or affect other agents. The description is thin on safety and 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear first sentence stating purpose, a brief context sentence, and a structured Args list. No redundant information. It prioritizes the main purpose and parameter semantics efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters (2 required), nested objects, and an output schema, the description covers all parameter meanings but omits prerequisites (e.g., existing project with crew.py) and file-operation behavior. The output schema exists, so return value details are not needed, but behavioral completeness could be improved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description's Args section adds meaningful explanations: e.g., 'tools: List of tool import strings', 'llm: LLM model string', 'other_params: Additional parameters'. This provides context beyond parameter titles, though examples would improve clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool edits crew.py to add tools, LLM, or other parameters to an agent. It uses specific verbs and resource, distinguishing from sibling tools like crewai_define_agent which likely define agents via other means.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when YAML configuration is insufficient ('that can't be set via YAML alone'), but does not explicitly state when to use or not use this tool versus alternatives like editing the file manually. No exclusion criteria or alternative tool mentions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_flow_plotB

Generate an HTML visualization of a Flow project.

Runs crewai flow plot which outputs an interactive HTML file mapping out the flow states and transitions.

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Project name

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It states the tool runs a command and outputs an interactive HTML file, but does not mention side effects (e.g., file creation location, overwriting) or permissions needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences with no filler. Front-loaded with purpose, and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (one parameter, straightforward action) and existence of an output schema, the description is minimally adequate. However, it could specify the output format (file path vs. HTML content) for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond the schema's 'Project name' label.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Generate an HTML visualization of a Flow project') and specifies the resource ('Flow project'). It distinguishes from siblings by mentioning mapping flow states and transitions, unique among the listed tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., crewai_flow_run). No prerequisites are mentioned, such as requiring an existing flow project.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_flow_runB

Execute a Flow project using the Python API.

This runs the flow directly using the Python API (flow.kickoff(inputs=...)) instead of the CLI, ensuring proper tool execution and avoiding interactive prompts.

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Project name
`inputs`	No	Optional inputs for the flow

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It mentions avoiding interactive prompts but lacks disclosure on side effects, permissions, error handling, or output behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences that convey the core purpose and a key behavioral note. It is front-loaded and lacks redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (context signal), the description is not required to detail return values. It provides adequate context for a non-destructive flow execution tool, though it could mention input structure implications.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 both parameters. The description adds no additional meaning beyond the schema, earning a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that it executes a Flow project using the Python API, distinguishing it from CLI-based approaches. However, it does not explicitly differentiate from sibling tools like crewai_kickoff, which may serve a similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by noting 'instead of the CLI' and 'ensuring proper tool execution,' but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_install_depsA

Install project dependencies.

Runs crewai install inside the project directory and optionally installs additional packages (e.g., specific crewai-tools).

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Name of the project in the workspace
`extra_packages`	No	Optional additional pip/uv packages to install

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the burden. It mentions running 'crewai install' and installing extra packages, but omits details like idempotency, error handling, network usage, or effect on existing dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no redundant information. Every sentence adds value, and the structure is front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's straightforward nature (install dependencies) and the existence of an output schema, the description sufficiently covers key aspects. However, it could mention that the tool modifies the project environment and may require network access.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description adds context by explaining the command invoked ('crewai install') and providing an example for extra_packages ('e.g., specific crewai-tools'). This enriches the parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Install project dependencies' by running 'crewai install' inside the project directory, with optional extra packages. This distinguishes it from sibling tools like crewai_create_project and crewai_test_crew.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., crewai_test_crew or crewai_kickoff). The description does not mention prerequisites, order of operations, or exclusivity conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_kickoffD

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes
`inputs`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_manage_memoryB

Manage CrewAI memory for a specific project.

Use 'reset' to run crewai reset-memories (requires --all flag or specific options). Use 'status' to check if the project has memory enabled.

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Project name
`action`	Yes	Action: 'reset' or 'status'

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It mentions that 'reset' requires '--all flag or specific options' but does not detail side effects, permissions, or what happens during a reset or status check. This is minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with two sentences that first state the tool's purpose and then elaborate on the two actions. Every sentence adds value, and there is no superfluous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown) and full schema coverage for parameters, the description is largely complete. However, it could provide more context on what the 'status' action returns or what 'memory enabled' means, though the output schema may cover this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage with descriptions for both parameters. The description adds only the note about the '--all flag' for reset, which is helpful but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages CrewAI memory for a specific project and specifies two actions: reset and status. Although the verb 'manage' is generic, the actions clarify its purpose, and it differentiates from sibling tools focused on other aspects like project creation or agent definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context for when to use each action ('reset' to reset memories, 'status' to check memory enabled). However, it does not explicitly state when not to use this tool or provide alternatives, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_project_infoA

Read the structure and core configurations of a CrewAI project.

Returns the pyproject.toml dependencies, available YAML configs, and Python source files to understand the current state of the project.

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Name of the project

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description indicates it's a read operation with no side effects, listing what it returns (dependencies, configs, source files). However, it lacks details on permissions, rate limits, or depth of file scanning. For a read tool with no annotations, more transparency would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is two sentences: first states purpose, second summarizes return contents. It is concise and front-loaded, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description adequately describes the tool's return categories (pyproject.toml dependencies, YAML configs, Python source files). With one parameter and clear output, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single required parameter 'project_name' described as 'Name of the project'. The description does not add meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads the structure and core configurations of a CrewAI project, specifying the verb 'Read' and the resource. It distinguishes from siblings like crewai_create_project and crewai_define_agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied for inspecting project state but not explicitly stated. There is no guidance on when to use this vs alternatives or when not to use it. Among siblings, only this tool is for reading, but no exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_query_knowledgeA

Query the internal CrewAI documentation RAG engine.

Use this when you need to look up how to use a specific CrewAI feature, tool, or pattern. It searches the official documentation and returns relevant snippets with their source URIs.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No
`category`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden. It discloses that the tool is a read-only query (searches and returns snippets) and explains the output format (snippets with source URIs). No contradictions or hidden side effects are suggested.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short paragraphs with no filler. It front-loads the core purpose and then adds usage guidance and output format. Every sentence is meaningful and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and the simplicity of the tool (3 params, 1 required), the description provides a sufficient high-level understanding. However, the omission of parameter semantics for limit and category reduces completeness slightly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only implicitly covers the 'query' parameter by mentioning 'searches the official documentation.' The 'limit' and 'category' parameters are not explained, leaving the agent unsure about their meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool queries an internal CrewAI documentation RAG engine and returns snippets with source URIs. This is a specific verb-resource pair, distinct from sibling tools like crewai_create_project or crewai_kickoff.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this when you need to look up how to use a specific CrewAI feature, tool, or pattern.' It provides clear guidance on when to use the tool, though it does not mention when not to use it or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_replay_taskA

Replay a crew execution from a specific task.

Runs crewai replay -t {task_id}. Useful for debugging and retrying specific failed tasks.

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Project name
`task_id`	Yes	ID of the task to replay from

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It mentions running a CLI command, implying a write/mutation operation, but does not disclose side effects, permissions, or safety. The description adds some value by noting it's for debugging, but lacks detail on what is modified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with no wasted words. The purpose is stated first, followed by the underlying command and a usage note. Each sentence is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple replay tool with two well-described parameters and an output schema, the description covers the core purpose and usage context. It lacks prerequisites (e.g., needing a previous execution) but is otherwise adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage with descriptions for both parameters. The description adds little beyond the schema, only referencing task_id in a CLI example. Baseline 3 is appropriate as the schema already does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool replays a crew execution from a specific task, using a specific verb ('Replay') and resource ('crew execution from a specific task'). This distinguishes it from sibling tools like crewai_kickoff which starts a new execution, and crewai_test_crew which tests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Useful for debugging and retrying specific failed tasks,' which gives clear context for when to use. It does not explicitly exclude other scenarios or compare to alternatives, but the usage intent is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_test_crewB

Test the crew's performance and evaluate outputs.

Runs crewai test -n {iterations} -m {model}. This helps in assessing the quality of the crew's execution.

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Project name
`iterations`	No	Number of testing iterations
`model`	No	LLM to use for evaluation	openai/gpt-4o

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description only states it runs a CLI command; does not disclose side effects (e.g., whether it modifies anything), auth requirements, or safe-to-invoke status.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters and no annotations, description is too sparse. Does not explain return values (though output schema exists) or mention any dependencies like project existence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3. Description adds no extra meaning beyond schema; merely restates command syntax without clarifying parameter usage or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Test' and resource 'crew performance and outputs', clearly distinguishing it from siblings like crewai_kickoff (run) and crewai_train_crew (train).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like crewai_kickoff or crewai_train_crew. Does not specify prerequisites or context for testing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crewai_train_crewA

Train the crew to improve performance.

Runs crewai train -n {iterations} -f {filename}. Agent training provides human-in-the-loop feedback to optimize prompts.

ParametersJSON Schema

Name	Required	Description	Default
`project_name`	Yes	Project name
`iterations`	No	Number of training iterations
`filename`	No	Output file for trained weights	trained_agents_data.pkl

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description must fully disclose behavior. It mentions a command and human-in-the-loop feedback but omits details about side effects, file modifications, or other impacts beyond training.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two focused sentences: the first defines purpose, the second adds technical context. Every sentence is necessary and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema (not shown but indicated), the description is mostly complete. However, it could briefly mention expected outputs or how success is indicated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds value by mapping parameters to command-line arguments ('Runs `crewai train -n {iterations} -f {filename}`'), which goes beyond the schema descriptions alone, which already have 100% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Train the crew to improve performance.' It uses a specific verb and resource, distinguishing it from siblings like crewai_kickoff (run) or crewai_test_crew (test).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for training to improve performance but does not explicitly state when to use this tool over alternatives or provide exclusions. It lacks guidance on when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

14 tool updatesv1.1.0Jun 19, 2026
- First observedcrewai_create_project
- First observedcrewai_define_agent
- First observedcrewai_define_task
- First observedcrewai_edit_crew_py
- First observedcrewai_flow_plot
- First observedcrewai_flow_run
- First observedcrewai_install_deps
- First observedcrewai_kickoff
- First observedcrewai_manage_memory
- First observedcrewai_project_info
- First observedcrewai_query_knowledge
- First observedcrewai_replay_task
- First observedcrewai_test_crew
- First observedcrewai_train_crew

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored 2026-06-19 22:50 across 14 tools

Disambiguation4/5

Most tools have clearly distinct purposes. Potential confusion between crewai_kickoff (for crews) and crewai_flow_run (for flows) is mitigated by naming. Two tools lack descriptions, which could cause ambiguity, but names are descriptive enough.

Naming Consistency5/5

All tools follow a consistent 'crewai_verb_noun' pattern in snake_case, e.g., create_project, define_agent, flow_run. No mixing of conventions, making it predictable for an agent.

Tool Count5/5

14 tools is well within the ideal range for a server covering project creation, component definition, running, testing, training, memory management, and debugging. Each tool serves a distinct purpose.

Completeness4/5

Covers core lifecycle: create, define, run, test, train, and debug. Missing delete or rename operations for projects or components, but the surface is comprehensive enough for typical workflows.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ateam-mcp AOAuth
io.github.ariekogan
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Agent Orchestration Autonomous Agents Developer Tools
5921
RoryPlansOAuth
ai.roryplans
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
Agent Orchestration Project Management Coding Agents
2
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
DynamicEndpoints-autogen_mcpOAuth
ai.smithery
Create and manage AI agents that collaborate and solve problems through natural language interacti…
Autonomous Agents Agent Orchestration Developer Tools
215

Related MCP Servers

Crew AI MCP Server
Agent Orchestration Autonomous Agents
MatthewLaw1
F
license
Not graded
quality
D
maintenance
Enables AI agent and task management using the CrewAI framework, allowing users to create and run agents and tasks in an automated workflow environment.
Updated 2 years ago (2025-02-02 22:08 UTC)
2 npm
6
-
Code-MCP
Developer Tools Coding Agents Autonomous Agents
millsydotdev
F
license
B
quality
Not graded
maintenance
Turns AI assistants into full-stack software engineers with 36 tools for cognitive reasoning, code validation, project scaffolding, and AI/IDE configuration generation across 130+ programming languages, databases, and frameworks.
Updated 9 months ago (2025-12-08 01:02 UTC)
35
8 npm
-
Agentic Control Framework
Autonomous Agents Agent Orchestration Developer Tools
FutureAtoms
A
license
D
quality
D
maintenance
AI-native orchestration layer with 80+ tools for task management, code editing, browser automation, terminal control, and persistent memory across CLI, local MCP, and cloud deployments.
Updated a year ago (2025-09-20 10:26 UTC)
69
4 npm
31
ISC
ML Lab MCP
Developer Tools Autonomous Agents Cloud Platforms
PushPullCommitPush
A
license
Not graded
quality
D
maintenance
Transforms AI assistants into a full ML engineering environment for training and fine-tuning models across multiple backends (local GPU, Mistral, Together AI, OpenAI) and cloud providers (Lambda Labs, RunPod, SSH-accessible VPS), with dataset management, experiment tracking, cost estimation, and deployment to Ollama/Open WebUI.
Updated 8 months ago (2026-01-10 08:55 UTC)
3
PolyForm Noncommercial 1.0.0