Skip to main content
Glama
phenasdev

devin-mcp-bridge

by phenasdev
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

devin-mcp-bridge

Lets Claude Code delegate work to Devin.

Claude Code  ──MCP/stdio──▶  devin-mcp-bridge  ──ACP/stdio──▶  devin acp

Devin ships an ACP agent (devin acp), which is what makes it usable from Zed. Claude Code speaks MCP, not ACP. This process sits in the middle: it is an ACP client toward Devin (spawning the agent, answering its filesystem and permission requests) and an MCP server toward Claude Code.

Tools

Tool

Purpose

devin_task({ task, cwd? })

Send a task to Devin, return its full response. Session persists per cwd, so follow-up calls keep context.

devin_reset({ cwd? })

Kill the agent and drop its context. Next devin_task starts fresh.

Related MCP server: peer-cli-mcp

Install

git clone https://github.com/phenasdev/devin-mcp-bridge.git
cd devin-mcp-bridge
npm install
npm run smoke          # boots the server, lists tools — no Devin needed
npm run smoke:call     # full turn against a fake ACP agent
npm run smoke:sandbox  # verifies symlinks cannot escape the session root

Register with Claude Code, using an absolute path to your clone:

# this project only
claude mcp add devin -- node "$PWD/src/devin-mcp.mjs"

# every project
claude mcp add -s user devin -- node "$PWD/src/devin-mcp.mjs"

Verify with /mcp inside Claude Code. Tool names appear as mcp__devin__devin_task.

Security

Devin runs autonomously and, over ACP, asks this process for permission and for filesystem access. Two controls exist, both on by default:

  • DEVIN_MCP_PERMISSION=once (default) — grant only one-shot permissions; never allow_always, which would remove the decision for the rest of the session. all approves everything including persistent grants. deny refuses everything.

  • DEVIN_MCP_SANDBOX_FS=1 (default) — fs/read_text_file and fs/write_text_file are confined to the session root; paths resolving outside it, including through symlinks, are rejected. Set 0 to disable. This path check is not an OS sandbox and cannot prevent a concurrent filesystem race.

When the bridge refuses a request, the turn result carries a [bridge] ... refused block naming the operation and path. Without it a sandbox rejection reaches Claude Code as a bare [tool failed], indistinguishable from a genuine Devin error.

There is no human in the loop on permission decisions — Claude Code sees one tool call, while Devin may perform many actions behind it. Before pointing this at a repo you care about, prefer a disposable worktree or a container, and keep the sandbox on.

Config

Env var

Default

Meaning

DEVIN_MCP_AGENT_CMD

devin

Agent binary. Set to npx to bridge a different ACP agent.

DEVIN_MCP_AGENT_ARGS

acp

Space-separated args.

DEVIN_MCP_PERMISSION

once

once | all | deny

DEVIN_MCP_SANDBOX_FS

1

0 disables the path guard.

DEVIN_MCP_TIMEOUT_MS

900000

Per-turn cap; the turn is cancelled on expiry.

Because the agent command is configurable, the same bridge works for any ACP agent — e.g. DEVIN_MCP_AGENT_CMD=npx DEVIN_MCP_AGENT_ARGS="-y @zed-industries/claude-code-acp".

Debugging

Agent stderr is inherited, so claude --debug shows both the bridge's [devin-mcp] log lines and Devin's own output. claude mcp list shows connection status.

Layout

  • src/devin-mcp.mjs — the bridge; ACP client + MCP server in one process.

  • scripts/fake-agent.mjs — minimal ACP agent used by the smoke test, so the wiring can be exercised without opening a real Devin session. It also probes the fs sandbox.

  • scripts/smoke.mjs — MCP handshake, tools/list, and optionally one full turn.

Available Tools

2 tools
devin_resetReset the Devin sessionA

Kill the running Devin agent and discard its conversation context. The next devin_task starts a fresh session. Use when Devin is stuck or the context is polluted.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory whose session to reset.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses that the agent is killed and its conversation context is discarded, and that the next task starts fresh. It doesn't mention any side effects like unsaved work, but for a reset tool, it's fairly transparent.

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 sentences: the first states the action, the second provides usage guidance. No wasted words, front-loaded with the essential 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?

For a simple one-parameter tool with no output schema, the description sufficiently covers purpose and usage. It could mention irreversibility, but the tool is straightforward.

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 only parameter 'cwd' is fully described in the input schema (100% coverage). The tool description adds no extra meaning beyond what the schema provides, so the baseline score of 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 specifies the verb 'Kill' and 'discard' and the resource 'Devin agent/session', and distinguishes from the sibling 'devin_task' by stating the next task starts a fresh session.

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 states when to use this tool: 'when Devin is stuck or the context is polluted.' It doesn't explicitly mention when not to use it, but the context is clear.

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

devin_taskDelegate a task to DevinA

Send a coding task to Devin (a separate autonomous coding agent) and return its full response. Devin keeps context across calls for the same working directory, so follow-up calls can refer to earlier work. Use for self-contained work you want done in parallel; state the task and the acceptance criteria explicitly, since Devin cannot ask you questions.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoAbsolute path to the repo root Devin should work in. Defaults to the server's cwd.
taskYesThe task for Devin, with enough context to act without follow-up.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description discloses key behaviors: Devin keeps context across calls for the same working directory, returns full response, and cannot ask questions. This provides adequate 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?

Three sentences: first states purpose, second adds behavioral context, third gives usage guidance. Every sentence is essential 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 no output schema and moderate complexity, the description covers purpose, behavior, and usage. Could mention error handling or timeouts, but sufficient for most use cases.

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%, but the description adds value by explaining the cwd parameter defaults to server's cwd and task should have enough context to act without follow-up.

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 delegates a coding task to a separate autonomous agent (Devin) and returns its response. It distinguishes from the sibling tool devin_reset by implying this is the task-creation tool.

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?

It advises using for self-contained parallel work and instructs to state task and acceptance criteria explicitly since Devin cannot ask questions. Implicitly suggests follow-up calls are possible due to context retention.

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. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observeddevin_reset
    • First observeddevin_task
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one sends a task to Devin, the other resets the session. No overlap or confusion possible.

Naming Consistency4/5

Both tools use the 'devin_' prefix and snake_case, but the pattern is slightly inconsistent: 'devin_task' is a noun while 'devin_reset' is a verb. However, the prefix makes them clearly related.

Tool Count4/5

With only 2 tools, the server is minimal. For its purpose as a bridge to an autonomous agent, this is reasonable but slightly thin. A status or cancel tool could be added.

Completeness3/5

The server covers the basic workflow of sending tasks and resetting, but lacks features like checking task status or interrupting a running task. Some gaps exist but core functionality is present.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • kimi-acp-mcp

    TuTouPower
    A
    license
    A
    quality
    B
    maintenance
    Bridges Claude Code to Kimi Code via MCP, enabling task delegation with file and command execution.
    3
    MIT

  • devin-mcp

    iainmck29
    A
    license
    A
    quality
    D
    maintenance
    Enables Claude Code to delegate implementation tasks to Devin.
    4
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/phenasdev/devin-mcp-bridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server