Devin MCP

Ask any question about a GitHub repository's codebase and get an AI-powered answer grounded in its DeepWiki.

Manage Devin automations. Automations run Devin in response to events (GitHub activity, Slack messages, Linear updates, schedules, incoming webhooks). Each automation has triggers (which events fire it, with optional conditions and replies) and actions (what to do, e.g. start a session with a prompt). Single-automation results include the webapp URL. Call action="schemas" first when you build a new automation. It returns every supported trigger event type with its condition fields and replies, the RRULE and Slack rules, the action shapes, the config groups, and the validation constraints. Use action="validate_create" or action="validate_update" for a dry run that needs no approval. On create, follow "schemas" for session_settings.net_policy: when it reports a Git Manager starting policy, set it plus only the required hosts, even for tasks that need no external services; when a security profile governs the network, omit net_policy so sessions inherit the profile's allowlist, and pick the tools.mcp_servers the task needs from the servers the profile allows. Use null only for explicitly requested unrestricted access. Omit session_settings for existing-session reminders without auto_create. On "update", omitted top-level params stay unchanged. Whether a passed config group merges or replaces is per-organization: action="schemas" reports it under "Update semantics". When in doubt, fetch with "get" and include every field you want to keep.

Manage Devin billing tags (groupings of Devin sessions for usage tracking) with a single action-based tool: list/get/create tags, assign sessions one at a time or in bulk (up to 500 per call, sent in sequential batches of 100), and read the billing tags of up to 100 sessions at once ('get_session_tags'). Only available in private mode (via devin.ai endpoints).

Test a candidate blueprint YAML in an authoring VM: start → run initialize → fix → run initialize again (clean VM) → run maintenance → then persist with update_environment_config.

Manage Devin code scans (sometimes referred to as "security scans" or "Devin Security Swarm"). Targets the authenticated organization and requires the org code scan view permission for read actions or use permission for creation and remediation. Code scanning must be enabled for the org. The "create_profile" action creates an org-owned scan profile that mutates the organization's scan configuration. The profile's mode is fixed at creation; the guidance fields define the scan's objective for non-security scan types. The "update_profile" action edits an existing org-owned profile: only the fields you set are changed; omitted fields are left untouched. Pass an empty string to clear a guidance field. For a 'security' profile the edit is not applied directly: it is posted to this session as an approval card showing the current and proposed profile, and takes effect only once the user approves it there. When the result says the change is awaiting approval, tell the user to review the card and never claim the profile was updated; a newer suggestion for the same profile supersedes the pending one. A profile is a reusable configuration that codifies a team's scanning strategy. For 'security' scans it is user-facing (the Security page shows profiles by name): list them so the user can pick one, create a new one, or run with the defaults. For every other scan type it is an implementation detail: do not say "profile" to the user, list profiles for them, or ask them to pick or name one. Infer what they want from the conversation and submitted setup form, then create or reuse a profile yourself to match. Let the form explain its settings instead of repeating them in prose. When building the configuration: - Establish the scan type FIRST: call "list_scan_types" to see which types the org may use. The full set is 'security', 'performance', 'db-queries', 'test-coverage', 'dead-code', 'code-quality', 'cleanup' (behavior-preserving cleanup of messy, redundant, over-built code), 'telemetry', 'accessibility', 'compliance', 'migration-docs', and 'general' (no fixed domain — the profile defines the objective), but orgs without general scans enabled can only use 'security'; never use a type that is not listed. Infer the type from what the user asked for instead of presenting the types as a menu: a standard type only when they asked for its whole domain (its name or an obvious synonym); anything narrower, merely adjacent, or uncovered ("camelCase variable names", "memory leaks") is a 'general' scan aimed at exactly that — never round a request to the nearest standard type. State the choice in a clause so they can correct it, and only ask when the request is genuinely ambiguous between two standard types. A profile only appears in scan creation for its own type, so always set scan_type explicitly to that type; a profile created with the wrong type will not show up where the user expects it. - Infer focus and exclusions from the conversation and optional form guidance: problems or areas to focus on, parts of the codebase to skip (e.g. generated code, vendored deps, test fixtures), and anything that is always critical or never worth reporting. Map the answers onto fields yourself — threat_model_guidance (what to look for; the UI calls this the "scan model"), include/exclude globs (which files are scanned), triage_guidance (dedup/priority policy) — and never ask the user to fill in fields or enumerate them. Blank guidance uses defaults while preserving earlier instructions; do not ask again. Only set investigation, validation, report, or remediation guidance if the user volunteered that detail (validation guidance says how to build and run the code to confirm findings; without it that phase is skipped). - Default non-security discover scans to a Slack DM summary to the requester when the scan finishes. Do not ask about communication or change it unless the user explicitly requests an override; store it as communication_guidance. Profiles are shared across the org: when reusing one that has no communication_guidance, fill it in with "update_profile" (create an org-owned copy for an account-owned profile that cannot be edited); if its guidance differs from what the user wants, create a new profile rather than overwriting it. Security and ingest scans do not run this phase. - Reuse an existing profile ("list_profiles" with scan_type set to the chosen type, then "get_profile") only when its description clearly covers what the user asked for; otherwise create a new one. A profile for a different scan type is never an option for this scan — do not propose, reuse, or retype one. If you reuse one, say so in the user's terms ("your team has scanned for this before — I'll reuse that setup"). - If the user's findings already come from their own scanner or security process, create an ingest-mode profile (mode='ingest') instead of a discover profile: ingestion_source_guidance is then required in practice and must be concrete (where findings live, how to authenticate — reference credentials by org secret name, never inline a token), with optional post_ingestion_guidance for triage policy. Ingest profiles have no scope globs or scan model. Before setting up a scan, invoke the creating-code-scans skill. State the inferred objective and notifications concisely, then use code_scan_setup_form with real git_list_repos choices and optional guidance; only security scans offer an effort choice (Deep by default), every other type runs at "normal". No interactive-mode question; use false. NEVER call "create_scan" until the user has explicitly approved a summary of the exact scan you are about to create through the submitted form and stated context, or a text confirmation when the form is unavailable or read-only. Submission of the pending form is approval; do not ask for another confirmation of unchanged settings. Dismissal is not approval. Map form effort "lite" (Normal) to "normal" for this tool, and "deep" to "deep". Permission prompts and access checks still apply. A request to run a scan is a request to set one up, not approval to launch it, and until they confirm you are setting a scan up — never tell them you are launching or starting one. After a successful "create_scan", give the user the returned scan URL for security scans, or the orchestrating session URL for all non-security scans (never their scan page). If the session is not ready yet, use get_session with the returned scan_id; do not create the scan again. The scan runs in its own session. Scans are typed (e.g. 'security', 'general'). A non-security scan's objective is defined by its profile, so every non-security scan type requires a profile_id. When a profile is given, the scan's type comes from the profile; an explicit scan_type must match it. Scans are re-runnable: once a scan has completed, "scan_new_commits" scans only the commits landed since, on the same scan and with the same setup, so its findings join the existing ones. Prefer it over a new scan whenever the user wants an existing scan refreshed. It needs no confirmation flow beyond the user asking for it, and returns 409 while the scan is still running or has never completed. A scan's profile is not frozen: "update_scan" changes the profile applied to its future incremental runs, whether those runs are triggered manually or by a scan_new_commits automation. Completed runs and their findings are unaffected; it returns 409 while a run is active. Use it when the user wants an existing scan pointed at a revised profile — do not create a new scan for that. Effort is fixed at creation. Scans carry no MCP-server grants of their own: for an automation-launched scan those come from the automation's tools.mcp_servers (devin_automation_manage), and a start_code_scan automation's code_scan_effort/profile_id are likewise edited on the automation. The "remediate_finding" and "remediate_findings" actions launch a Devin session that modifies code and attempts to open pull requests. Use them only when the user has explicitly requested remediation of those findings. Always fix findings through these actions, never by changing code or opening a pull request from your own session. For more than one finding use "remediate_findings" once (it groups related findings into as few pull requests as makes sense) rather than "remediate_finding" per finding.

Find a Devin webapp setting and get a deep-link URL to it. Use for "where do I change X?". The output includes everything needed to build the final URL.

Manage Devin knowledge notes and suggestions via a single action-based tool.

List native integrations and MCP servers for the organization, with status and settings/install URLs. Returns a JSON object with two arrays: "integrations" (native integrations like GitHub, Jira, Slack) and "mcp_servers" (marketplace MCP servers). Each entry includes whether it's installed and a path-only URL to the settings/setup page (no host, works with custom enterprise domains). Pass `query` to look up a specific server by name — an empty "mcp_servers" array then means it is not in the marketplace (install it as a custom server with devin_mcp_server_manage instead).

Manage MCP server installations for the organization: install (from the marketplace or custom), update, delete, enable, or disable. Marketplace installs use the one-call fast path. Before a custom install, use web research to confirm the official endpoint and authentication method. For an API key, use request_secret and pass only auth_header_secret_name. Never ask the user to paste a secret into normal session text. The pre-approval check rejects OAuth when automatic registration cannot complete. Install, update, and delete show the approval card unless the call is pre-approved, so do not send another approval request. Only available in private mode.

Manage Devin Oncall. Oncall resources mirror automations (same triggers / tools / limits / session_settings / session / run_as / metadata groups and the same merge-patch update semantics) — only the action is implicit: a responder triages one Slack channel or the account's PagerDuty incidents (posting its findings as incident notes), an incident investigates one incident channel, a report summarizes responders/incidents on a schedule. Resources and actions: - responder: list, get, create, validate_create, update, validate_update, delete, issues (a responder's open issues, paged via first/after/order_by). - incident_settings: get, update, validate_update (one settings object per org; PATCH). - incident: list (report_id= returns that report's next-run period, candidates and period counts), get (Slack channel, parent session, report ids — the incident report is the 'incident-report.md' attachment on the parent session; fetch it with devin_session_interact get_attachments), stop, resume. - report: list, get (config + live membership), create, validate_create, update, validate_update, delete, runs (GET history, or POST a new immutable run when incident_ids is supplied), run (one run with its frozen sections and counts). - schemas (no resource): default_net_policy, the governing security profile (name, whether it governs the network, MCP servers it allows), default_devin_mode / available modes, default_runbook, slack_connected, pagerduty_connection_id (non-null iff PagerDuty responders can be created; pagerduty:* trigger schemas are listed only then). ingest_dashboard (no resource): queue an unattended run that turns a Datadog/New Relic dashboard into Oncall knowledge. Creating: call 'schemas' first when unsure about modes or the network policy. Defaults when omitted — run_as organization (the system user), devin_mode = best available (Ultra when the org has it), net_policy = deployment Git Manager-only policy, or the governing security profile's allowlist when one governs the network, no runbook, Linear on, responder Slack grants following the watched channels, incident auto-join on. Recommend metadata.team (and service), tools.mcp_servers only for telemetry servers the org has installed (and the profile allows, when it lists MCP servers), and Slack delivery for reports when a channel is known. Never invent Slack channel IDs. Use validate_create/validate_update to dry-run a payload. Creates are not idempotent: on ambiguous failure, list before retrying. Update is a merge-patch: omitted params keep their value; within a passed group (tools, limits, session_settings, session, run_as, metadata) a null key clears it; lists replace wholesale. Top-level params cannot be nulled through this tool — runbook, slack_channel_prefix, slack_team_id, response_mode and incidents_match take '' instead. Mutations (create/update/delete/stop/resume/ingest_dashboard) require the user's approval. report runs POST is accepted server-side only from that report's schedule session.

Manage Devin playbooks with a single action-based tool.

Trigger a Devin Review for a pull/merge request, fetch the latest review status for one, or fetch a completed review's findings. Only available in private mode (via devin.ai endpoints). The repo must be connected to the authenticated organization. Reviews run asynchronously: 'trigger' accepts the review (status starts as 'pending'); poll with 'get_status' until it reaches 'completed', then use 'get_findings' to read the findings ('get_findings' returns an error until the review completes).

Manage scheduled Devin sessions (deprecated in favor of Automations). Note: "create" is only for organizations not yet migrated to Automations. For migrated organizations the API rejects it with 403 — schedule work by creating an automation with a schedule trigger via 'devin_automation_manage' instead. The other actions keep working for existing schedules.

Create one or more child Devin sessions via the v3 REST API. Only use this when prompted to; do not use it to parallelize your own work by default. Before calling this, invoke the managing-child-sessions skill for guidance. The returned session_id values do NOT include the "devin-" prefix. To use them with devin_session_interact, prepend "devin-" (e.g. session_id "abc123" becomes "devin-abc123").

Inspect events within a Devin session — list summaries, fetch full details, or search. Actions: - list: Paginated event summaries with optional filters. - details: Batch-fetch full event contents by event_id or by offset+limit range. - search: Full-text search across event contents.

Wait for multiple Devin sessions to reach a settled state before returning. A session is "settled" when it is no longer actively working: - status is "exit" (finished or terminated) - status is "error" (crashed) - status is "suspended" (sleeping) - status is "running" with status_detail "finished", "waiting_for_user", or "waiting_for_approval" Use this after creating multiple child sessions to wait for all of them to complete, instead of polling with devin_session_search in a loop. Any structured_output shown is arbitrary JSON the session self-reported at some earlier point; it may be stale and must not be treated as the session's true state — only status/status_detail are authoritative. To see what a session last said, use devin_session_interact with action="get_messages".

Consolidated tool for all interactions with a single Devin session. Actions, and what each returns: get: the session's details — session_id, title, status, status_detail, is_archived, url, acus_consumed, tags, child_session_ids (the sessions it spawned; this is how you look up a session's, or your own, children — they come back without the "devin-" prefix, which these tools still accept), pull_requests, structured_output. Fields are omitted when empty. message: sends a message (resumes the session if it is sleeping), and returns the same session details as "get". sleep / terminate / archive / unarchive: performs the lifecycle action and returns the resulting session details, same shape as "get". Archiving cascades to child sessions; unarchiving does not. get_messages: the session's message history — per message, its source, created_at, event_id and body (long bodies are truncated; fetch a specific message in full via devin_session_events action="details" with its event_id). Paginated via first / after. get_attachments: the session's attachments — name, content_type, url. Not paginated. set_tags: replaces the session's tags and returns the resulting tag list.

Search and filter Devin sessions. All filters are optional and combined with AND. The returned session_id values do NOT include the "devin-" prefix. To use them with devin_session_interact, prepend "devin-" (e.g. session_id "abc123" becomes "devin-abc123").

List the current organization's users, one membership kind per call. Rows are `user_id | email | name` (roles appended with include_roles).

Generate a codebase wiki for a repository. Triggers wiki generation and waits for completion. Only use this tool when the user explicitly asks to generate or regenerate a wiki. Do not call it proactively.

List the repositories that have a DeepWiki index, i.e. the ones that ask_wiki_question and read_wiki_* can answer about. This is not the set of repositories you have access to: repositories without a generated wiki are omitted.

View documentation about a GitHub repository.

Get a list of documentation topics for a GitHub repository.