Devin MCP write scopes by default: Sume keeps write opt-in
Devin now requests read/write scopes by default for Microsoft 365 MCP. Sume's hosted MCP asks for read only unless the user turns Write on at consent.
Devin's September 25 release notes say Microsoft 365 MCP connections now request all read/write permissions that do not need admin approval by default. That is Microsoft 365 only. Sume's hosted MCP works the other way: mcp:read is required and mcp:write is opt-in, and the consent page has the Write toggle off by default.
Vendor facts are from the Devin release notes; Sume facts are from MCP OAuth and MCP tools and gates, read 2026-10-01.
What did Devin change?
The notes say the change lets Devin send mail, create events and post in Teams without reconnecting. The wording covers Microsoft 365 MCP connections; the notes do not describe other servers as changing.
What scopes does Sume request?
The docs list two supported scopes. Granting write always includes read.
| Item | What the docs say |
|---|---|
mcp:read | Required; sessions see read-only tools |
mcp:write | Opt-in; sessions see mutating and paid tools |
| Consent screen | Read locked on, Write toggle default off |
mcp:paid | Does not exist; paid submits go through wallet and admission |
| Missing write | A mutating tool returns insufficient_scope |
What happens if the user leaves Write off?
The session only sees read-only tools, and a mutating call returns insufficient_scope. Job reads such as jobs_status still work. A session that needs to submit a paid generation has to be reconnected with Write granted, or use an API key. See Claude Code 403 insufficient scope for the re-auth flow.
Does Write mean the agent can spend freely?
No scope grants spend on its own. Paid and write tools require an idempotency_key, and dry_run=true previews admission and cost without submitting. max_spend_usd is enforced only when you send it.
What should I check when I connect an MCP in Devin?
Read the permission list on the consent screen before approving, and grant Write only when the agent has a task that needs it. The same habit applies to any server whose default scopes change between releases; see Zed MCP OAuth scopes.
Sources
Related posts
More in Integrations
- fal MCP "why did my request fail": the Sume job equivalent
fal's Platform MCP lets an assistant debug a failed request. For a failed Sume media job, read jobs_events and the error, then retry by the error rules.
- Mastra idleTimeoutMs observer detach: the Sume job keeps running
Mastra idleTimeoutMs detaches the observer and keeps the run. A Sume job it started keeps running too: re-wait on its id, do not resubmit.
- Mastra respondToToolApproval needs toolCallId: Sume paid calls
Mastra now rejects approval responses without toolCallId. When you approve a Sume paid tool call, key it to that id and keep its idempotency_key stable.
- OpenAI Agents Python conditional approval and Sume dry_run
Openai-agents-python v0.22.3 aligns conditional approvals with validated tool arguments. For Sume tools, base the check on tools_schema and dry_run.
Written by Sume