Integrates with Google Gemini API, supporting models like gemini-2.0-flash for task-based AI orchestration.
Integrates with OpenAI API for task-based AI orchestration using OpenAI models.
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., "@MAGI Orchestrator run build-auth-layer"
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.
MAGI is a high-performance, task-based AI orchestrator designed to bring structure, persistence, and specialized intelligence to autonomous development. It operates as a bridge between your preferred AI models and your local environment, functioning simultaneously as a powerful interactive CLI and a background Model Context Protocol (MCP) server.
Professional Interactive UI: Inspired by Claude Code, featuring dimmed reasoning for better focus, real-time action spinners, and clean result boxes.
Hybrid Power: Use it directly in your terminal for dedicated focus, or annex it to your favorite AI client (Gemini CLI, Claude Desktop) via MCP.
Persistent Orchestration: Unlike standard chat interfaces, MAGI manages its own state in a local .magi directory, including progress logs, activity history, and strict Guardrails (Signs) to prevent AI loops.
Native SDK Integration: Fast and secure connections to official Google Gemini, Anthropic Claude, and OpenAI SDKs. No middleman proxies.
Zero-Touch Automation: Registration and skill installation happen automatically. Just install and start orquestrating.
Related MCP server: Agentic Control Framework (ACF)
Install MAGI Orchestrator globally via npm to get the magi command:
# Official installation
npm install -g magi-orchestratorNote: The automatic registration script (postinstall) will detect your Gemini CLI and Claude Desktop configurations and inject the MAGI server/skill automatically.
Run tasks directly from your terminal with rich, stylized feedback.
# Execute a task iteration interactively
magi run "build-auth-layer"Open your Gemini CLI and use the native skill:
/magi fix-login-bugMAGI will run in the background and report progress directly in your chat session.
MAGI looks for a magi-config.json file in your project directory. If not found, it uses sensible defaults.
{
"agents": [
{
"name": "gemini-flash",
"type": "gemini",
"model": "gemini-2.0-flash"
},
{
"name": "claude-sonnet",
"type": "claude",
"model": "claude-3-5-sonnet-20241022"
}
],
"defaultAgent": "gemini-flash",
"stateDirectory": ".magi"
}Set your API keys as environment variables:
GEMINI_API_KEY, ANTHROPIC_API_KEY, OPENAI_API_KEY.
MAGI keeps your project context clean by orchestrating everything inside the .magi folder:
progress.md: Tracking success criteria and current status.
guardrails.md: Active "Signs" learned from previous failures to guide the AI.
activity.log: Detailed history of every decision and action.
Command | Description |
| Start/Continue a task iteration interactively. |
| Manually trigger auto-registration in AI clients. |
| Start the MCP server (STDIO). |
| Report the current version (v1.2.1). |
Retrieve MAGI runtime status, default agent, available agent adapters, and resolved state directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description defines what is retrieved but does not disclose side effects, authentication needs, or rate limits. It implies a read-only operation but doesn't state it explicitly.
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?
Single sentence listing items concisely with no redundancy. Every word adds information.
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 parameterless status tool with no output schema, the description adequately explains what will be returned. Could be improved by noting it's a read-only operation.
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?
No parameters exist, so schema coverage is complete. The description adds value by enumerating the specific information retrieved (runtime status, default agent, adapters, state directory), which is not in the schema.
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 explicitly states the tool retrieves MAGI runtime status, default agent, available adapters, and state directory. It clearly distinguishes from the sibling 'run_magi_iteration' which executes iterations.
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 explicit when-to-use or alternatives, but the sibling name 'run_magi_iteration' implies this is for inspection while that is for action. Lacks guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one MAGI iteration for a task using agentName when provided, otherwise the configured default agent.
| Name | Required | Description | Default |
|---|---|---|---|
| taskName | Yes | Name of the task to run | |
| agentName | No | Optional agent adapter name (gemini-cli, claude, openai, ollama) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'execute' without specifying side effects, return value, or whether it blocks. Lacks behavioral depth.
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?
Single sentence, no fluff. Front-loaded with action and resource.
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?
Simple tool with no output schema. Covers purpose and param semantics well, but could mention result or side effects for full completeness.
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 covers both params with descriptions. Description adds value by explaining fallback behavior for agentName (uses default if omitted).
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?
Description clearly states it executes one MAGI iteration for a task, with optional agent override. Sibling get_magi_status is for status, so this tool is distinct.
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?
Implied usage: use to run an iteration, not to check status. No explicit when-not or alternatives, but context with sibling tool makes it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.4get_magi_statusrun_magi_iterationget_magi_status and run_magi_iteration have clearly distinct purposes: one retrieves runtime status, the other executes an iteration. No overlap or ambiguity.
Both tools follow a consistent verb_noun pattern: get_magi_status and run_magi_iteration, using snake_case throughout.
With only 2 tools, the server feels thin for an 'Orchestrator' concept. However, the tools cover basic status and execution, so it is borderline appropriate.
The tool surface lacks many expected operations for an orchestrator, such as agent management, task listing, or configuration. Significant gaps exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/reaper1067MSX/MAGI'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
