Claude mcp_tool_listing pin: what a Sume tool list depends on
A pinned mcp_tool_listing holds the Sume tool list fetched for one session scope. Sume's list depends on mcp:read vs mcp:write and never pushes list changes.

With the mcp-client-2026-09-15 beta header, a Claude API response records each server's fetched tool list in an mcp_tool_listing block, and sending it back pins that list. For Sume the pinned list is only as good as the scope of the session that fetched it: an OAuth mcp:read session sees read-only tools, and Sume does not push tool-list change notifications.
The Claude behavior is from the release notes read 2026-10-01; the Sume behavior from MCP tools and gates and the server source.
What does the release note say?
The September 22, 2026 entry says tools can be defined inside a mid-conversation system message with the inline-tools-2026-09-15 beta header. With the MCP connector's mcp-client-2026-09-15 header as well, the definition can be an MCP toolset, and "a response records each server's fetched tool list in an mcp_tool_listing block, which pins that list when you send it back." The excerpt does not say how long a pin lasts, so read the migration guide before relying on it.
What decides which tools Sume lists?
Visibility follows the credential. Mutating and paid tools are hidden until the session has mcp:write or an API key. Default hosted OAuth grants read-only access (mcp:read).
| Session | Tools visible | Write or paid call |
|---|---|---|
OAuth mcp:read | Read-only tools | insufficient_scope |
OAuth mcp:read + mcp:write | Full hosted set | Needs idempotency_key |
| API key | Full hosted set | Needs idempotency_key |
Will a pinned list notice a scope change?
Do not assume so. The server's initialize response sets tools: { listChanged: false }, so it does not tell a client its list changed. If a user later grants Write, or you switch from OAuth to an API key, a list pinned earlier still shows the read-only set. Fetch a new listing in the new session and pin that one. See tools/list freshness for the per-session visibility details.
What should I do about it?
Pin only after the credential is final for that conversation. Ask the agent to call tools_list once after connecting, as the quickstart suggests, and use tools_schema for the contract of a single tool rather than trusting a cached description. If a tool you expect is missing, check the scope first: an insufficient_scope error or a missing paid tool usually means a read-only session. The connector itself is covered in Claude API MCP connector.
Sources
Related posts
- Claude API MCP connector with Sume: what works today
- MCP tools/list ttlMs and cacheScope: what is safe to cache?
- Sume MCP tools list: hosted tools grouped by read, write, and paid
- Fix MCP insufficient_scope on Sume: scopes, missing tools, timeouts
- Claude Code list_changed and reconnect: refresh Sume tools
More in Developers
- Claude Code MCP 403 insufficient_scope: re-auth Sume with Write
Claude Code 2.1.274 names the missing permission on a 403 insufficient_scope. For Sume, a read-only grant lacks mcp:write: re-authenticate and turn Write on.
- Claude Code alwaysLoad meta false: deferred Sume tools
Claude Code 2.1.285: a tool with _meta anthropic/alwaysLoad false stays deferred under a server alwaysLoad. What that means for Sume's tool set.
- Claude Code API 400 after a tool returned an object: Sume results
Claude Code 2.1.286 fixed API 400s when a tool returned an object, number or boolean. Sume tools return text content blocks, errors too.
- Claude Code background Bash 30-minute limit and Sume jobs
Claude Code 2.1.285 stops background Bash after 30 minutes by default (2 h max). A Sume render is a job id, so poll it with jobs_wait slices, never resubmit.
Written by Sume