Devin MCP + Stream Deck

Ask any question about a GitHub repository and get an AI-powered, context-grounded response.

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 filter conditions and replies) and actions (what to do, e.g. start a session with a prompt). Single-automation results include the canonical webapp URL. Use action="schemas" first when building a new automation: it returns every supported trigger event type with its condition fields and supported replies, plus the validation constraints enforced on create/update, so you can construct valid triggers/actions for action="create" or action="update". Use action="validate_create" or action="validate_update" for a dry-run validation that needs no approval. Each schedule:recurring trigger accepts exactly one rrule condition and no other condition fields; use a separate trigger per additional schedule. When the user specifies a timezone, preserve it with an IANA TZID DTSTART; BYHOUR/BYMINUTE remain the requested local wall-clock values and DST follows that timezone. Only use a timezone-less or UTC rule when the user explicitly wants UTC or no wall-clock timezone applies, such as interval-only cadence. For a one-time schedule, preserve a specified timezone with a local wall-clock DTSTART and COUNT=1; an explicit UTC DTSTART remains valid. On create, always set session_settings.net_policy to the Git Manager policy from "schemas", even for tasks needing no external services. Add only required hosts and explain why. Omission blocks all access. Use null only for explicitly requested unrestricted access; omit settings for existing-session reminders without auto_create. Note: on "update", omitted top-level params are left unchanged. Whether a passed config group merges (omitted keys kept, null clears) or replaces wholesale is per-organization — action="schemas" reports it under "Update semantics". When in doubt, fetch with "get" and include every field you want to keep: that is correct under either semantics.

Manage Devin billing tags (groupings of Devin sessions for usage tracking) with a single action-based tool: list/get/create tags, add/list their members, and assign sessions. 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. A profile is a reusable configuration that codifies a team's scanning strategy. It is an implementation detail: do not say "profile" to the user, list profiles for them, or ask them to pick or name one. Ask what they want out of the scan and what should happen when it finishes, then create or reuse a profile yourself to match. Users rarely know what the settings mean: whenever you offer an option (effort; interactive mode for security scans), say in one plain sentence what it does and what choosing it changes before asking. When building the configuration from their answers: - 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 named type or obvious synonym maps to that type; a specific thing to find that no standard type covers ("camelCase variable names") is a 'general' scan aimed at exactly that. State the choice in a clause so they can correct it, and only ask when the request is genuinely ambiguous. 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. - Ask whether there is anything specific they want out of the scan: 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. 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). - Always ask about communication for non-security discover scans: should anything happen when the scan finishes? Offer concrete choices (Slack the requester a summary; identify the code owners of each finding and ping them with it and its recommended fix; post to a team channel; no notifications), pin down which findings qualify, and write the answer as communication_guidance. Profiles are shared across the org: when reusing one that has no communication_guidance, fill it in with "update_profile"; 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 and follow its guided flow (repositories → scan type → what to look for and what happens when it finishes → options → summary → explicit confirmation). NEVER call "create_scan" until the user has explicitly approved a summary of the exact scan you are about to create; 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. 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; 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).