Devin Desktop team allowlist: Sume's MCP server blocked until listed

If your Devin Desktop team admin has allowlisted any MCP server, every server that is not on the list is blocked for the whole team, and Sume's hosted MCP is no exception. Ask the admin to add Sume's production server, https://mcp.sume.com/mcp, to the allowlist. Until then a member's mcp_config.json entry for Sume will not work, however correct it is.

The rule is from Devin's page Cascade MCP integration, read on 2026-10-02. Sume's endpoint and auth come from the MCP overview and OAuth and API keys.

How does the allowlist behave?

Devin's page says admins can restrict MCP access by allowlisting specific servers, and that once any server is allowlisted, all non-allowlisted servers will be blocked for the team. So the default is open, and the first entry flips it to closed. A team that added only an internal server last month has therefore blocked Sume without noticing.

What should the admin enter for Sume?

The production URL: https://mcp.sume.com/mcp. Sume's docs say customer configs should use mcp.sume.com; the mcp.dev.sume.com host is for Sume's own development environments and should not be allowlisted for customers. Devin's page does not describe the allowlist's exact matching rules in the part I read, so enter the full URL the same way members write it in serverUrl, and test with one member before announcing it.

If you manage several MCP servers, decide whether the list names servers or also tools. Devin's page mentions per-tool control through disabledTools in each user's config, which is a separate mechanism from the admin list.

How does a member test it after the admin adds Sume?

The member adds Sume to ~/.config/devin/mcp_config.json (macOS and Linux) with serverUrl and, for an API key, a headers object. Devin's page says secrets can come from ${env:VAR_NAME} or ${file:/path/to/file}, which keeps the key out of the file. Devin Desktop also supports OAuth for each transport, so a member can sign in with Sume's consent page instead of a key.

Then call mcp_health from the agent. It confirms the endpoint and the auth source, and tools_list shows the tools that session can use. With OAuth and Write off, only read-only tools appear; paid calls such as generate_image return insufficient_scope until the member grants mcp:write.

Should the team use OAuth or one shared key?

OAuth gives each member their own sign-in and a read-only default. A shared API key in a team-wide config means one credential for everyone, full tool visibility, and a rotation chore if it leaks. Sume says paid and write calls need an idempotency_key either way and that wallet admission is the spend gate; there is no mcp:paid scope to hand out separately.

What should the admin and the member each do?

Split the work so nobody guesses. The admin owns the list; the member owns the config and the sign-in. Doing the steps in order avoids the most common false alarm, a correct member config blocked by an admin rule nobody remembered.

• Admin: add https://mcp.sume.com/mcp to the MCP allowlist in the team settings.
• Member: add the Sume entry to mcp_config.json with serverUrl, and either sign in with OAuth or add a headers entry for an API key.
• Member: ask the agent to call mcp_health, then tools_list.
• Admin or member: if Write was left off at consent, reconnect and turn it on before running paid tools.

What does this not cover?

Devin's allowlist is Devin's control. Sume cannot see it and has no setting that overrides it. If Sume loads for you but not for a teammate, compare the admin's list, then the member's config, then the auth source from mcp_health, in that order.