Roo Code .roo/mcp.json overrides the global Sume MCP entry
In Roo Code a project .roo/mcp.json wins over global mcp_settings.json when both name the same server. Use one name for Sume and keep the key in one file.

Roo Code reads MCP servers from a global mcp_settings.json and from a project-level .roo/mcp.json, and when the same server name appears in both, the project entry takes precedence. If you register Sume under one name in both files, the project file replaces the global one rather than adding to it, so a project entry that lacks your header or alwaysAllow list can change what Roo sends.
What Roo's docs say
Roo's page describes the two files and the precedence rule. For a remote server, the type must be streamable-http, the url is required, headers are optional, alwaysAllow is an array of tool names, and disabled is a boolean.
| Key | Required | Sume value |
|---|---|---|
| type | Yes | streamable-http |
| url | Yes | https://mcp.sume.com/mcp |
| headers | No | x-api-key with your Sume key, or leave out and use OAuth |
| alwaysAllow | No | Read tools only, if any |
| disabled | No | true to pause the server |
Choose where the key lives
Sume accepts an API key as an Authorization Bearer header or an x-api-key header, and its docs say an API-key session sees the full hosted tool set. Putting that key in a project .roo/mcp.json risks committing it with the repository. Sume's credential-safety notes say to rotate keys that appear in logs or chat history.
A safe split follows from the precedence rule. Keep the key and the Sume entry only in the global file, and do not add a Sume entry to the project file. If the project needs to disable Sume, a same-name project entry with disabled set to true would take precedence, though check that behavior in your Roo version before relying on it.
{
"mcpServers": {
"sume": {
"type": "streamable-http",
"url": "https://mcp.sume.com/mcp",
"headers": { "x-api-key": "<SUME_API_KEY>" },
"alwaysAllow": ["tools_list", "mcp_health"]
}
}
}Quick diagnostic
If Sume behaves differently in one repository than everywhere else, look for a .roo/mcp.json with a server of the same name. Then run mcp_health to see the auth source Sume recorded and tools_list to see which tools that session can see.
Roo's per-server network timeout defaults to 60 seconds and ranges from 1 to 3600 seconds; the project entry is the one that applies when it overrides the name. Sume's gates, including idempotency_key on paid calls, are in Tools and gates.
Sources
Related posts
More in Integrations
- SendGrid ECDSA event webhook vs a Sume HMAC verifier: two checks
SendGrid signs event webhooks with ECDSA, while Sume uses HMAC SHA256. Here is why one verifier will not cover both and how to start a Sume run from an event.
- Shopify X-Shopify-Webhook-Id as the Sume Idempotency-Key
Shopify retries a failed webhook 8 times over 4 hours. Derive the Sume Idempotency-Key from the webhook id so each delivery makes one run, never two.
- Slack link unfurling for a page that shows a Sume render
A Slack app can unfurl your own link with a Sume render preview using link_shared and chat.unfurl. Learn the 5-domain limit and the reinstall rule first.
- Slack scheduleMessage: announce a finished Sume render
Slack lets a bot schedule a post up to 120 days ahead, with at most 30 per 5 minutes in a channel. Finish the Sume render first, then schedule the announcement.
Written by Sume