Cursor supports MCP roots and elicitation; Sume uses tools only
Cursor lists tools, prompts, resources, roots, elicitation and Apps as supported. Sume's hosted MCP answers only tools, so here is what you will see.

Cursor can use MCP tools, prompts, resources, roots, elicitation and the Apps extension, but Sume's hosted MCP server offers only tools. Its initialize response declares a tools capability with listChanged set to false, and the server code answers initialize, ping, tools/list and tools/call only. In Cursor that means Sume shows up as a list of callable tools, with no prompts to pick, no resources to attach and no server-initiated forms.
Cursor's matrix is from Cursor Docs: Model Context Protocol, read 2026-10-02; the Sume side is from the server source in packages/mcp-server/src/mcp.ts and the MCP overview.
What does Cursor say it supports?
The page has a protocol table with six rows. Tools are functions for the model to run. Prompts are templated messages for users. Resources are structured data sources. Roots are server-initiated inquiries into URI or filesystem boundaries. Elicitation is a server asking the user for more information. Apps is an extension where tools return interactive UI, with progressive enhancement: if a host cannot render it, the tool still works through normal MCP responses.
| Feature | Cursor | Sume hosted MCP |
|---|---|---|
| Tools | Supported | Yes, the only declared capability |
| Prompts | Supported | No prompts/list method; unknown methods return -32601 |
| Resources | Supported | No resources/list or resources/read |
| Roots | Supported | Not requested by the server |
| Elicitation | Supported | Not used; confirmation is dry_run and wallet admission |
| Apps (extension) | Supported | Not used; results come back as text |
Why does that matter for paid calls?
With elicitation, a server could ask you to confirm a charge in a form. Sume does not. Its safety model is arguments and credentials: paid tools require an idempotency_key, dry_run=true previews admission and cost, max_spend_usd applies when sent, and OAuth mcp:read hides mutating tools. The confirmation you see in Cursor is Cursor's own tool approval, which the page says asks before using MCP tools by default and shows arguments behind an arrow next to the tool name.
What will I see in Cursor after connecting?
Only a tool list. Ask the agent to call tools_list to see the tools your session can use, and mcp_health to see the auth source. Because listChanged is false, Sume never tells Cursor that its tool list changed; if you switch from a read-only OAuth session to one with Write, reconnect the server so Cursor fetches the list again.
If a Cursor feature that depends on prompts or resources looks empty for Sume, that is expected rather than a connection fault.
Where do I go for the generation workflow?
Use the tools themselves. Discover with tools_schema, preview with dry_run, submit with an idempotency_key, then wait with jobs_wait. Sume MCP tools and gates lists the full inventory, and Auto run MCP tools in Cursor covers which of them to let run unattended.
Sources
Related posts
More in Integrations
- Deno.serve webhook receiver for Sume with a KV dedupe check
A short Deno.serve receiver for Sume webhooks: verify sume-v1 over the raw body, dedupe on job_id with an atomic KV write, and acknowledge with 204.
- Devin Desktop team allowlist: Sume's MCP server blocked until listed
In Devin Desktop, once an admin allowlists any MCP server, all others are blocked for the team. Add Sume's production URL to the list before members connect.
- Devin Desktop 100-tool limit: fit Sume's MCP tools with disabledTools
Cascade in Devin Desktop (formerly Windsurf) caps total tools at 100. Sume's docs list about 75 tool ids; trim others with disabledTools.
- Fastify 5 raw body for a Sume webhook: parseAs string
Fastify parses JSON before your handler, which breaks HMAC checks. Use parseAs string, then verify sume-v1 and dedupe. Tested on Fastify 5.12.5.
Written by Sume