1Open Slashspace and go to Settings, then Connectors.
2On Discover, search for Devin MCP and click Connect.
3Sign in to Devin MCP in your browser. Slashspace updates when the account is connected.
Then ask for what you need in any Agent mode chat. Devin MCP is on in every chat unless you switch it off.
What your chats can do
23 tools from Devin MCP.
Ask wiki questionAsk any question about a GitHub repository's codebase and get an AI-powered answer
grounded in its DeepWiki.
Devin automation manageManage 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.
Devin billing tag manageManage 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).
Devin blueprint testTest 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.
Devin code scan manageManage 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.
Devin find settingFind 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.
Devin knowledge manageManage Devin knowledge notes and suggestions via a single action-based tool.
Devin list integrationsList 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).
Devin mcp server manageManage 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.
Devin oncall manageManage 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.
Devin playbook manageManage Devin playbooks with a single action-based tool.
Devin review manageTrigger 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).
Devin schedule manageManage 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.
Devin session createCreate 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").
Devin session eventsInspect 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.
Devin session gatherWait 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".
Devin session interactConsolidated 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.
Devin session searchSearch 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").
Devin user listList the current organization's users, one membership kind per call.
Rows are `user_id | email | name` (roles appended with include_roles).
Generate wikiGenerate 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 wiki reposList 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.
Read wiki contentsView documentation about a GitHub repository.
Read wiki structureGet a list of documentation topics for a GitHub repository.
