How to Configure and Use the Devin AI MCP Server

Two AI agents running on separate platforms will fail to coordinate unless they share a unified protocol, resulting in conflicting edits and split contexts. The Devin Model Context Protocol (MCP) server addresses this challenge by establishing a standard host-to-client bridge, allowing external development clients to programmatically drive Devin's internal workspace sessions.

Many developers struggle with Devin's MCP integration because they confuse the two directions of communication. To use this protocol effectively, you must understand the distinction between Devin acting as a client and Devin acting as a host.

When Devin acts as a client, it runs external MCP servers inside its secure cloud VM sandbox. In this direction, Devin uses tools that you configure for it, such as querying a local database, reading a private repository, or posting messages to team channels. Devin is the one invoking the tools, and the external servers are the providers.

When Devin acts as a host, the relationship is inverted. The official devin ai mcp server runs as an external web service. External clients, such as Cursor, Claude Code, or custom scripts, connect to this service. In this scenario, the external client is the caller, and Devin is the provider. The external client uses Devin's platform tools to create new coding sessions, trigger playbooks, and read workspace outputs.

This distinction is critical for developers configuring their workspaces. If you attempt to use the local CLI commands to expose Devin's internals, or if you confuse the API key headers, your configuration will fail. By establishing a clear separation, teams can orchestrate workflows where a local agent delegates complex software engineering tasks to Devin, monitors progress, and pulls the resulting files back into a central repository.

For teams using shared workspaces, storing persistent data is essential, and linking local tools to Fast.io shared workspaces provides the necessary infrastructure.

The Model Context Protocol was developed to replace ad hoc API integrations with a standard JSON-RPC schema. In a multi-agent environment, this protocol serves as a universal connector. For example, instead of writing custom API integration code for Devin to talk to external tools, or for external tools to talk to Devin, both sides speak the same protocol. This reduces integration overhead and ensures that tools are reusable across different LLMs and developer interfaces.

When you configure Devin to run external tools, you are setting up Devin as an MCP client. This process requires devin mcp config commands to register external services and declare their execution parameters. The devin mcp configuration cli provides a dedicated command suite to manage these integrations without editing configuration files directly.

The CLI automatically detects the transport type for each server. If you pass a URL, the CLI configures an HTTP or Server-Sent Events connection. If you pass a command, the CLI configures a standard input and output pipe.

Here is the table of the primary CLI commands and their arguments for devin mcp tool setup:

When running these commands, you must choose the appropriate scope for your configuration. Scoping determines where Devin saves the JSON file and which projects have access to the tools.

• Local scope: By default, the CLI saves configurations to .devin/mcp_config.local.json. This file is gitignored and is intended for local overrides and private secrets like API keys.

• Project scope: Using the -s project flag saves the configuration to .devin/mcp_config.json. This file is tracked in version control, allowing all team members working on the project to share the same tool configurations.

• User scope: Using the -s user flag saves the configuration to ~/.config/devin/mcp_config.json on macOS and Linux, or %APPDATA%\devin\mcp_config.json on Windows. This configures the tools globally for all Devin sessions run by the current user.

Understanding these scopes prevents configuration errors. For example, if you save a database password to the project scope, it may be committed to version control. Conversely, if you save a project-specific tool to the user scope, other team members will not be able to use it when they run Devin on the same repository.

When working with these local configuration files, developers often encounter permission issues or file paths that fail to resolve. If you run a command-line utility within Devin's VM that attempts to read an MCP server configuration stored in a project-specific scope, it must have read permissions for the .devin directory. If the scope is set incorrectly, Devin may fail to locate the tool, throwing a silent error. To resolve this, run devin mcp list within the active project directory to verify that the CLI has successfully parsed the local JSON files. Verify that any environment variables required by your stdio server are defined inside the .local.json file, as the project-level config is typically committed to version control and should not contain sensitive tokens.

To control Devin programmatically from external applications, you must configure Devin as an MCP host. In this mode, external clients connect to the official devin model context protocol server. The host endpoint is hosted at https://mcp.devin.ai/mcp, which acts as the entry point for all session and playbook operations.

Connecting to this endpoint requires proper authentication credentials. The Devin MCP server does not support legacy API keys, which are identified by the apk_ prefix. Instead, you must generate a modern service user API key from your account settings page.

For enterprise organizations, the server requires an additional header to scope requests correctly. Because enterprise service user keys or personal tokens can span multiple organizations, you must include the X-Org-Id header. This header tells the Devin MCP server which organization's workspaces, playbooks, and knowledge bases to target. You can find your organization ID in your account settings under the service users section.

Here is an example of a configuration JSON block for Cursor or other standard MCP clients:

{
  "mcpServers": {
    "devin": {
      "url": "https://mcp.devin.ai/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SERVICE_USER_API_KEY",
        "X-Org-Id": "YOUR_ENTERPRISE_ORGANIZATION_ID"
      }
    }
  }
}

If you are using Claude Code, you can register the server using the CLI:

claude mcp add -s user -t http devin https://mcp.devin.ai/mcp -H "Authorization: Bearer YOUR_SERVICE_USER_API_KEY" -H "X-Org-Id: YOUR_ENTERPRISE_ORGANIZATION_ID"

Once the connection is established, the external client gains access to Devin's platform tools. This allows you to orchestrate workflows where a local agent can spawn Devin sessions to handle background tasks, such as running a test suite or refactoring a legacy module, while you continue working in your primary IDE.

When configuring these headers, ensure that the authorization value starts with the prefix Bearer followed by your key. A common error is omitting the prefix, which results in authorization failures. If you are a non-enterprise user, you can omit the X-Org-Id header, as your API key will automatically route requests to your personal workspace. However, enterprise administrators must enforce the use of X-Org-Id to ensure all actions are logged in the organization's central events feed and audit trails.

To see how Fast.io exposes its own tools to external agents, check the Fast.io MCP server configuration.

When using Cursor, developers can configure the server through the graphical settings panel rather than editing the configuration file manually. Navigate to Settings, click on MCP, select Add New MCP Server, choose HTTP as the type, set the name to devin, and input https://mcp.devin.ai/mcp as the URL. You must then add the headers for authorization and organization routing manually in the headers input box. This graphical configuration writes directly to the global user configuration, ensuring that the settings persist across all Cursor workspaces.

Coordinate your Devin AI MCP server files in one place

Set up a persistent, secure workspace with an MCP-ready endpoint for your Devin AI MCP server reads and writes, complete with versioning and search. Start your 14-day free trial today.

Start 14-Day Trial

The Devin MCP server allows developers to control Devin programmatically, enabling other Model Context Protocol-compatible AI clients to trigger playbooks, manage sessions, and read workspace outputs. Once connected, your local client can access several specific tools designed for session and knowledge orchestration.

Below is the list of tools exposed by the Devin MCP server:

1. devin_session_create: This tool programmatically spins up a new Devin session. You can pass a prompt describing the task, reference specific playbooks, and apply tags for organization.

2. send_message_to_session: This tool allows you to send follow-up messages or instructions to an active session, establishing a continuous feedback loop between your local client and Devin.

3. read_wiki_structure and read_wiki_contents: These tools fetch repository documentation, allowing external agents to read guides and wiki pages stored in Devin's knowledge system.

4. ask_question: This tool queries Devin's internal knowledge base, returning context-grounded answers to guide development.

For example, a developer can configure Cursor to invoke Devin when a local build fails. Cursor uses devin_session_create to start a new session, uploads the build log, and requests a fix. Devin boots an isolated virtual machine, inspects the code, runs the compiler, and tests the solution. While Devin is working, the developer can monitor progress in Cursor or send feedback using send_message_to_session. Once Devin finishes, the local agent retrieves the corrected files.

This multi-agent collaboration pattern uses the strengths of both tools. The local agent handles immediate, low-latency edits, while Devin manages long-running, complex tasks in its cloud sandbox. This removes the bottleneck of local resource constraints and lets developers parallelize their engineering workflows.

Playbooks are particularly useful in this setup. A playbook defines a structured sequence of steps or rules for Devin to follow, such as run a specific linter, check test coverage, or execute a database migration script. By triggering a playbook through the MCP tool, you ensure that Devin follows company-standard procedures every time. This eliminates variability in agent performance and guarantees that the outputs conform to your project's architectural guidelines. The external client can simply pass the playbook identifier in the session creation payload, automate the execution, and wait for the status tool to report completion.

Because Devin runs in its own isolated VM, it does not share environment state with your local machine. If your playbook relies on specific local databases, you must either mock those databases inside Devin's VM environment or expose a secure tunnel so Devin can query them. You can configure this connection by passing port forwarding configurations or remote access credentials inside the session launch parameters.

While you can write files directly to local storage, S3 buckets, or consumer sync tools like Google Drive, these platforms are not built for autonomous agents. General-purpose storage tools lack audit logs, fail to track version history for parallel writes, and do not provide an integrated intelligence layer.

Fast.io provides a persistent workspace layer designed for multi-agent teams. Instead of leaving Devin's outputs scattered across ephemeral VM instances, teams use Fast.io as a shared coordinate workspace. This setup allows both human developers and agents to collaborate on the same files.

Here is how Fast.io supports multi-agent coordination:

• Persistent shared workspaces: Create workspaces owned by your organization where multiple agents can read and write files. This provides a central storage repository for inputs and outputs.

• Per-file version history: Agents working concurrently can easily overwrite files. Fast.io maintains a complete history of revisions for every file, allowing you to track changes and restore prior versions if an agent makes an error.

• Granular permission controls: Set access rights at the organization, workspace, folder, or file level to ensure agents only access the documents they need.

• Append-only audit logs: Monitor every read, write, and access event for compliance and security, keeping agent activities fully transparent.

• Metadata Views: Turn folders of files into a queryable database by linking to Metadata Views. AI automatically extracts structured fields like dates, totals, or custom tags from PDFs, images, or notes without manual templates or OCR rules.

• Ownership transfer: The human creates a paid organization to start a 14-day free trial (credit card required), and the agent hands off full ownership.

Fast.io requires a paid subscription for organization workspaces. Plans include Starter ($29/mo), Business ($99/mo), and Growth ($299/mo). Every new organization begins with a 14-day free trial that requires a credit card.

Connecting Devin's MCP server to Fast.io workspaces creates a reliable loop. Devin reads source files, executes tasks in its sandbox, and writes the results to Fast.io. Humans can review the files, check the version history, and query structured outputs via Metadata Views. This setup turns raw files into an organized team asset.

For teams ready to secure their environments, reviewing the Fast.io subscription plans is the first step.

Co-editing and Finding Files Across Systems

In a multi-agent system, agents and humans must be able to search files quickly and co-edit documents in real time. Fast.io supports this with hybrid search, combining full-text, semantic, and metadata-value queries. When Devin writes a report, humans can locate it by searching for its meaning rather than its exact name. Collaborative Notes allows humans and agents to edit project documentation simultaneously, facilitating real-time feedback loops. This ensures that the entire team, whether human or AI, operates from the same knowledge base.