Cursor cloud agents and Sume MCP: HTTP, redacted headers

Yes, a Cursor cloud agent can use Sume's hosted MCP server, because Cursor's cloud agents accept HTTP MCP servers and Sume's endpoint, https://mcp.sume.com/mcp, is a remote HTTP server. Add it through the MCP dropdown at cursor.com/agents (personal) or under Dashboard, Plugins & MCPs (team), then pick OAuth or an API-key header. The choice matters more here than in the IDE, because a cloud agent runs without you watching it.

Cursor's side of this comes from its Cloud Agent capabilities page (read 2026-10-10). Sume's side comes from the MCP pages on docs.sume.com. This post does not claim a tested cloud run; it lines up what each page promises so you can set the right limits before the first paid call.

What Cursor says about cloud-agent MCP

Per Cursor's page, cloud agents use MCP servers configured for your team or added personally. Custom servers can use HTTP or stdio, while SSE and mcp-remote are not supported. Sume's hosted server does not need either of the unsupported paths: the Sume quickstart tells clients to set a streamable HTTP URL.

The most useful detail is where the credentials live. Cursor recommends HTTP and says that for HTTP servers the configuration is never present in the cloud agent's VM, that the agent has no access to refresh tokens or headers, and that tool calls are proxied through Cursor's backend. Headers and the OAuth client secret are redacted after saving and cannot be read back.

Pick the Sume credential for an unattended run

Sume gives two credentials for the same endpoint, and they behave differently. OAuth gives mcp:read by default, and the user opts into mcp:write with the Write toggle on the consent page. There is no mcp:paid scope. An API key sees the full hosted tool set.

For a cloud agent that means: with read-only OAuth, generate_image or avatars_create return insufficient_scope and nothing is billed, which is a safe default for research runs. With a write grant or an API key the agent can submit paid work, and Sume's own spend gate is the wallet and admission, not a prompt. Cursor's per-user OAuth also means a teammate who has not signed in to Sume cannot borrow your grant.

Put the guardrails in the prompt and the task

Sume's docs list three gates for paid and write tools: a required idempotency_key, an optional dry_run=true that previews cost without submitting, and an optional max_spend_usd that Sume enforces only when you pass it. A cloud agent will not add the optional ones unless told to, so write them into the task.

A prompt that works as a standing instruction: call mcp_health and tools_list first; before any paid call run dry_run=true and report the estimate; set max_spend_usd on every paid call; never re-use an idempotency_key for a different request; poll with jobs_wait rather than re-submitting.

• Start the task with mcp_health; Sume documents it as the check for endpoint, auth source and safety posture.
• Ask for dry_run=true on the first paid call, then review the estimate before the real submit.
• Keep Write off for any run whose job is only to read catalog_list, balance_get or jobs_list.
• Rotate the API key if it was ever pasted into a prompt or chat; the header field is for it.

Network access is a separate switch

Cursor's settings page (read 2026-10-10) lets users, admins and environment owners choose allow all network access, default plus an allowlist, or an allowlist only. Because Cursor says HTTP MCP calls are proxied through its backend, the MCP request itself is not made from the VM. Downloading a result file is a different step: if the agent fetches a media URL from Sume inside the VM, that request is subject to your network mode, so add the host from the result URL if you run allowlist-only. That last point is our reading of the two pages, not a Cursor statement, so confirm it with one small test job.

Sume's docs say integrations should store the Sume media URL, not provider URLs, so the host to allow is the one that appears in your own job results.