MCP server/discover against Sume's hosted endpoint
The 2026-07-28 MCP spec adds server/discover. Sume's hosted server does not implement it and answers -32601; read initialize and tools/list instead.

Sume's hosted MCP server does not implement server/discover. The JSON-RPC dispatcher handles initialize, ping, tools/list and tools/call, and any other method is rejected with error code -32601 (method not found). Read the version and capabilities from initialize, and the tool catalog from tools/list.
Spec facts are from the 2026-07-28 server/discover page, read 2026-09-30. Sume facts are from the packages/mcp-server source and the MCP quickstart. Which spec version the server speaks is covered in this post.
What does server/discover do in the spec?
The page says it lets a client query a server's supported protocol versions, capabilities and identity before sending other requests. The response carries supportedVersions, capabilities, an optional instructions string, and caching hints (ttlMs, cacheScope). The same page says servers MUST implement it, while calling it is optional for clients, which may invoke any RPC inline and handle UnsupportedProtocolVersionError. Sume's server declares 2025-11-25 as its newest version, a revision that predates this method, so the gap is a version gap, not a documented Sume decision.
What does Sume's endpoint answer instead?
Method dispatch in the server source is a fixed switch; the default branch throws JsonRpcMethodNotFoundError, which the handler turns into a JSON-RPC error with code -32601. So a server/discover request gets that error, not a result object.
| Method | Sume behavior |
|---|---|
initialize | Returns protocolVersion, capabilities, serverInfo |
ping | Returns an empty object |
tools/list | Returns { tools } only |
tools/call | Runs the tool |
server/discover or any other | JSON-RPC error -32601 |
Where do I read the same information?
From initialize. The server echoes the requested protocolVersion when it is in its supported list (2025-03-26, 2025-06-18, 2025-11-25), and otherwise answers with 2025-11-25. Its capabilities object declares tools with listChanged set to false. Tool names come from tools/list; see the tools/list caching post.
const res = await fetch("https://mcp.sume.com/mcp", {
method: "POST",
headers: {
"Content-Type": "application/json",
Accept: "application/json, text/event-stream",
Authorization: "Bearer " + process.env.SUME_API_KEY,
},
body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "server/discover" }),
});
console.log(res.status, await res.text()); // expect error code -32601Should my client call it anyway?
Since clients are not required to call it, treat -32601 as "not available" and fall back to initialize. A client that probes first should not fail hard on that error. I did not verify how any specific client library reacts, so test yours against the endpoint.
Sources
Related posts
More in Developers
- MCP server notify when work finished: Sume webhooks vs jobs_wait
The MCP roadmap lists push delivery for finished work. On Sume today, MCP agents wait in bounded jobs_wait slices; HMAC webhooks are a REST job feature.
- MCP subscriptions/listen: Sume has no push stream to join
MCP's 2026-07-28 spec adds subscriptions/listen for change notifications. Sume's hosted MCP answers POST only and declares listChanged false.
- Merchant Center conversational attributes: draft them as JSON
Conversational attributes add richer context to product listings. Draft them per SKU as schema-bound JSON from a Sume Format run, then review before upload.
- Three Responses subagents, one Sume workspace queue
Responses multi_agent runs 3 subagents by default and they share your tools. Sume accepts extra jobs as queued until queue_full; give each create its own key.
Written by Sume