SWE2 Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| devin_runA | Start a delegated engineering task through the installed Devin CLI. Returns a job_id promptly; collect its result with devin_wait. The worker may edit files and execute commands. One external job runs at a time per bridge instance. |
| devin_waitA | Read the current or terminal result of an existing Devin job. Waits for completion for at most wait_seconds. Reuse the same job_id while it is running; a completed process still requires review of the work. |
| devin_cancelA | Stop an existing Devin job and return its cancellation or existing terminal state. Cancellation preserves changes already made in the working directory. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool maps to a distinct job lifecycle stage: run (start), wait (poll/collect), cancel (stop). Descriptions explicitly distinguish devin_run from devin_wait and mention job_id handoff, so there is no realistic overlap.
All three tools use the same devin_<verb> snake_case pattern with parallel imperative verbs (run, wait, cancel). Fully predictable and readable.
Three tools precisely cover the async start/poll/cancel lifecycle for a single-job bridge. Nothing is redundant; adding more would be overengineering.
Start, wait, and cancel cover the core lifecycle, and cancellation notes that changes are preserved. Minor gaps could be listing/inspecting active jobs or cleaning up terminal job state, but these are workable around.