How to Use MCP with Devin AI

Devin AI supports three transport methods for Model Context Protocol (stdio, SSE, and HTTP), and Cognition's own docs split MCP into separate product surfaces: marketplace connections, DeepWiki MCP, and Devin MCP. Most generic MCP tutorials collapse that into a single "paste this JSON" snippet. That is why setups fail quietly, why public-only tools show up when teams expected private repos, and why CLI configs work in Cursor but vanish in Devin Desktop.

Devin AI MCP support lets teams connect Model Context Protocol servers so Devin can call external tools, repositories, and data sources during autonomous coding sessions. In practice you choose a surface first, then authenticate, configure the server, test tool discovery, and apply production guardrails. The rest of this guide follows that path.

The three surfaces in plain language

• MCP Marketplace (inside Devin): Browse and enable third-party servers (Sentry, Linear, Notion, databases, and more) under Settings > Connections > MCP servers. Admins can also add custom servers over STDIO, SSE, or HTTP.
• DeepWiki MCP: A free, remote, no-auth server at https://mcp.deepwiki.com/ for public repository documentation and "Ask Devin" style questions.
• Devin MCP: An authenticated server at https://mcp.devin.ai/ for public and private repos plus session, playbook, knowledge, schedule, and integration management.

Numbered path (featured-snippet shape)

1. Choose the MCP surface (marketplace tool, DeepWiki for public wiki, Devin MCP for private/platform, or CLI local servers).
2. Authenticate (none for DeepWiki; OAuth or service account for marketplace; cog_ API key for Devin MCP; env tokens for CLI STDIO servers).
3. Configure the server (UI form, remote URL + headers, or .devin/config.local.json).
4. Test a tool call ("Test listing tools" in the UI, or a natural-language request that forces tool use).
5. Add production guardrails (scoped keys, org vs personal OAuth access, deny lists, secrets management, durable file storage outside the sandbox).

Cognition's docs also warn about a client-specific field name trap: Devin Desktop expects serverUrl for remote servers, while most other clients use url. Using the wrong key causes the server to be silently ignored.

Teams searching for "devin mcp" or "deepwiki mcp" often land on two different servers that share some documentation tools but diverge on auth and scope. Official docs publish this comparison explicitly.

DeepWiki MCP (public, free, no key)

Base URL: https://mcp.deepwiki.com/

Recommended transport: Streamable HTTP at https://mcp.deepwiki.com/mcp (SSE at /sse is legacy and being deprecated).

Tools:

1. read_wiki_structure - list documentation topics for a GitHub repository
2. read_wiki_contents - view documentation for a repository
3. ask_question - ask a question about a public repository and get a context-grounded answer

Devin Desktop config example:

{
  "mcpServers": {
    "deepwiki": {
      "serverUrl": "https://mcp.deepwiki.com/mcp"
    }
  }
}

Other clients (for example Cursor) use "url" instead of "serverUrl". Claude Code can add the server with:

claude mcp add -s user -t http deepwiki https://mcp.deepwiki.com/mcp

DeepWiki is the right starting point when you need public repo context without billing or API keys. It is not the right tool for private monorepos or Devin platform automation.

Devin MCP (authenticated platform server)

Base URL: https://mcp.devin.ai/

Recommended transport: Streamable HTTP at https://mcp.devin.ai/mcp. The legacy SSE endpoint is deprecated.

Auth: A Devin API key. Org-scoped service user keys (cog_ prefix) resolve the org automatically. Enterprise service user keys and personal access tokens also use the cog_ prefix but require an X-Org-Id header. Legacy keys with apk_ or apk_user_ prefixes are not supported by the Devin MCP server.

Devin Desktop example with org header (enterprise / PAT patterns):

{
  "mcpServers": {
    "devin": {
      "serverUrl": "https://mcp.devin.ai/mcp",
      "headers": {
        "Authorization": "Bearer <API_KEY>",
        "X-Org-Id": "<YOUR_ORG_ID>"
      }
    }
  }
}

Find the org ID under Settings > Service users, or call GET /v3/self with your key.

Beyond wiki tools, Devin MCP exposes platform operations documented by Cognition:

• Repository docs: read_wiki_structure, read_wiki_contents, ask_question (up to 10 repos), list_available_repos
• Sessions: create, search, interact, inspect events, gather parallel sessions
• Playbooks and knowledge: full manage/CRUD style tools
• Schedules: cron and one-time session scheduling
• Integrations: list native integrations and MCP server install status

When to pick which

Public GitHub wiki Q&A with zero setup: DeepWiki MCP

• Private repos plus Devin session control: Devin MCP
• Sentry, Linear, databases, or design tools during a Devin run: Marketplace MCP
• Local GitHub MCP or custom STDIO tools in CLI: Devin CLI MCP config

Cognition positions DeepWiki as the free public path and Devin MCP as the account-backed path for private repositories and platform management.

Keep Devin session files where the team can review them

Use a shared Fast.io workspace with MCP endpoints, version history, and search so agent outputs outlive a single Devin session. Start a 14-day free trial (credit card required) and connect your agent storage path.

Start 14-Day Trial

The marketplace is how most day-to-day Devin users attach tools without writing config files. Navigate to Settings > Connections > MCP servers in the Devin app to browse and enable servers. Marketplace entries cover log tools (Sentry, Datadog), project trackers (Linear, Asana, Atlassian), design (Figma), docs (Notion), and databases (PostgreSQL, MySQL, BigQuery, Neon, and others). Many marketplace MCPs enable with one click, then complete OAuth when you test tools or start a session.

OAuth access modes matter

For OAuth servers, Devin's docs define two Access settings:

• Organization: every member shares one authenticated connection. Cognition strongly recommends a service account, not a personal login, because every member session reuses that connection.
• Personal: each member authenticates with their own account. That is fine for personal OAuth, but docs note it is not a security boundary, since other users can still interact with sessions.

Only users with Manage MCP Servers permission can authenticate OAuth-based servers. Devin's OAuth callback URL for custom client credentials is https://api.devin.ai/mcp/oauth/callback.

Custom MCP servers

If the tool you need is missing, organization admins use Add a custom MCP. Devin supports three transports:

• STDIO: local CLI servers (npx, uvx, Docker). Requires command, args, and env variables.
• SSE: legacy remote servers. Requires server URL and headers.
• HTTP: Streamable HTTP remote servers. Requires server URL and headers.

Prefer HTTP for new remote integrations. SSE remains supported for older servers but is treated as legacy across the MCP ecosystem.

HTTP + bearer token (conceptual fields shown as JSON):

{
  "transport": "HTTP",
  "url": "https://mcp.internal-service.example.com/mcp",
  "auth_method": "auth_header",
  "headers": {
    "Authorization": "Bearer your-api-token"
  }
}

STDIO database pattern (read-only credentials recommended in production):

{
  "transport": "STDIO",
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-postgres",
    "postgresql://user:password@host:5432/database"
  ]
}

After save, use Test listing tools. Devin spins up an isolated test environment, connects, and attempts tool discovery. The button stays disabled until you save. Failures usually mean unreachable URL, bad credentials, timeout, or a STDIO process that writes non-protocol noise to stdout.

Secrets

Pass API keys through environment variables or Devin Secrets rather than hardcoding tokens in args. Treat every MCP server as production-grade access: scope database users, prefer service accounts for org OAuth, and revoke marketplace connections you no longer use.

Devin CLI treats MCP servers as first-class tool providers. When configured, the agent discovers tools and calls them like built-in capabilities. Official CLI docs show a four-step flow: define the server, launch the process, discover tools, execute tool calls against the external API.

Project config example

Keep tokens out of committed files. Cognition's example uses a gitignored local config:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

File name in the docs: .devin/config.local.json.

Once connected, tools appear with a namespaced format: mcp__<server>__<tool>. A GitHub server exposing create_issue becomes mcp__github__create_issue.

Permissions

MCP tools follow the same permission system as built-in tools. You can allow a whole server and deny dangerous tools:

{
  "permissions": {
    "allow": [
      "mcp__github__*"
    ],
    "deny": [
      "mcp__github__delete_repo"
    ]
  }
}

(Shape simplified for readability; follow the current CLI permission reference for the full key nesting.)

Remote OAuth and enable/disable

Some remote servers (Atlassian, Notion, Linear, and similar) require OAuth. Each MCP client authenticates independently: tokens from Windsurf or Claude Code are not shared with Devin CLI. After adding a remote server, complete the browser OAuth flow documented for Devin CLI.

Temporarily disable a server without deleting credentials:

devin mcp disable <server-name>
devin mcp enable <server-name>

Practical smoke tests

After config, force a real tool path instead of only listing servers:

1. Ask Devin to list available MCP tools for the session.
2. Request a low-risk action (list open issues, read a wiki section, fetch a Sentry error summary).
3. Confirm the session log shows an MCP call, not a hallucinated answer.
4. Fail closed: disable the server and confirm the agent no longer claims those tools.

If tools connect but never appear, check that STDIO servers speak clean JSON-RPC on stdout, that env vars are present, and that you did not mix url / serverUrl for remote HTTP servers.

MCP solves tool access. It does not by itself solve durable team storage for agent outputs. Devin sessions run work in an isolated environment. Logs, patches, design exports, customer PDFs, and intermediate reports still need a place humans can open after the session sleeps, archives, or is recreated.

Common options teams already use:

• Git remotes (GitHub, GitLab): Best for code. Weak for large binary handoffs, client portals, and mixed media review.
• Object storage (S3, GCS): Durable and cheap. Needs custom scripts for upload, permissions, previews, and search.
• Consumer drives (Google Drive, Dropbox): Easy for people. Awkward for agents that need API or MCP access, versioned overwrites, and scoped automation keys.

Fast.io is an intelligent workspace layer teams add beside those options when agents and humans must share the same project files. It is not a built-in Devin product feature. You wire it the same way you wire any remote MCP or API-backed storage: as an external system Devin (or a sibling agent) can write to and people can open in a browser.

What Fast.io provides for agentic coding workflows

• Shared org-owned workspaces with granular permissions at org, workspace, folder, and file levels
• Per-file version history so concurrent agent overwrites remain recoverable
• Append-only audit log for who uploaded, shared, or changed what
• Intelligence Mode for auto-indexing, hybrid search (full-text + semantic + metadata values), and citation-backed chat over project docs
• Metadata Views for structured extraction into a live grid when the job is contracts, invoices, or media tags (document data extraction)
• Branded shares (Send, Receive, Exchange) for client handoffs without dumping raw buckets
• Consolidated MCP tooling over Streamable HTTP at /mcp and legacy SSE at /sse on mcp.fast.io (see /storage-for-agents/)
• Ownership transfer so an agent can build an org structure, then hand the org to a human via claim link while keeping admin
• Webhooks for reactive pipelines when files change

Example pattern that stays honest about product boundaries:

1. Devin uses marketplace or CLI MCP tools to investigate Sentry or Linear.
2. Devin produces patches in the repo and a written summary with log excerpts.
3. A storage MCP or upload step places the summary, screenshots, and export bundles into a Fast.io workspace.
4. Humans review version history, search prior incident packs, and share a Receive/Exchange link with stakeholders.
5. When the agent-built org is ready for a person to own billing, transfer ownership and continue under a paid plan.

Creating a Fast.io user account is free, but real work needs an organization on a paid subscription. Every org starts with a 14-day free trial that requires a credit card. Plans include Starter at $29/mo, Business at $99/mo, and Growth at $299/mo. Agent-friendly path: agent signs up, prepares structure, human claims the org and starts the trial. Product context for agent storage lives at /storage-for-agents/ and pricing at /pricing/.

Use local disk or S3 when you only need bulk blobs. Use Fast.io when the bottleneck is coordination: search, permissions, handoff, and human review of agent output.

MCP multiplies what Devin can touch. Treat every server like production access to your company graph.

Security and access

• Prefer org-scoped service user keys for automation; avoid legacy apk_ keys on Devin MCP.
• For org OAuth marketplace connections, authenticate with a service account.
• Put secrets in env vars or Devin Secrets, never in committed CLI config.
• Use CLI allow/deny lists so destructive tools stay blocked (delete_repo, write tools on prod DBs).
• Give database MCPs read-only users in production.
• Disable unused servers with devin mcp disable instead of leaving stale credentials active.

Reliability

• Prefer Streamable HTTP over SSE for remote servers.
• Run Test listing tools after every custom marketplace add.
• Confirm serverUrl vs url for the client you actually use.
• For STDIO servers, keep debug logs off stdout so JSON-RPC stays intact.
• Smoke-test after enable: force a tool call, then disable and confirm loss of capability.

Operational clarity

• Document which surface owns which job (marketplace vs DeepWiki vs Devin MCP vs CLI).
• Keep private wiki and session automation on Devin MCP; keep public exploration on DeepWiki.
• Store durable artifacts outside the ephemeral agent environment so reviews do not depend on a live session.
• Pair tool audit (session logs) with workspace audit (file history) when regulated review is required.

Troubleshooting quick map

Server never appears: wrong URL field name. Use serverUrl in Devin Desktop, url elsewhere.

• Auth fails on Devin MCP: legacy key or missing org header. Use a cog_ key and add X-Org-Id when required.
• Test listing tools times out: unreachable host or firewall. Confirm public reachability or network path.
• Tools connect but stay empty: broken tools/list or stdout pollution. Fix the server protocol implementation.
• OAuth works in another IDE only: client-local tokens. Re-authenticate inside Devin or Devin CLI.
• Agent invents answers: tools not actually invoked. Disable the server, compare behavior, and re-test listing.

Done well, Devin AI MCP turns autonomous coding sessions into tool-using runs against your real systems. Done poorly, it is an unscoped superuser with a natural-language front door. Start with the smallest surface that solves the job, prove tool calls, then expand.