Responses API mcp_list_tools cache and Sume write tools
OpenAI reuses an mcp_list_tools item instead of refetching. If it was captured under mcp:read, Sume write tools stay missing until you start fresh.

If a Responses API conversation already holds an mcp_list_tools item from Sume's hosted MCP server, OpenAI will not ask the server for the list again on later turns. A list captured with a read-only token therefore keeps hiding Sume's write and paid tools, even after the user grants more access. Start a new conversation, or drop the old item from the context, to get a fresh list.
OpenAI states the caching rule in its MCP guide: as long as the mcp_list_tools item is present in the context, the API will not fetch the tool list from the MCP server again at each turn. Sume's side of the story is the scope. Under the required mcp:read scope, write and paid tools are hidden from tools_list, and calling one returns insufficient_scope (tools and gates).
What is cached and what is not
The table lines up the vendor rule with the Sume behavior it collides with.
| Fact | Source | Consequence for Sume |
|---|---|---|
The tool list is not refetched while mcp_list_tools is in context | OpenAI MCP guide | A read-only list stays read-only for that conversation |
mcp:read is required and read-only; mcp:write is opt-in on the consent page | Sume OAuth docs | Write tools only appear for a token that holds mcp:write |
Hidden tools return insufficient_scope when called | Sume tools and gates | A model that guesses a name still gets refused |
| An API key sees the full tool set | Sume hosted MCP docs | A key-based list does not have this gap |
How do I get the new tools into an existing thread?
Re-authorize on the consent page with mcp:write ticked, send the new token as the authorization value, and open a new conversation. Reusing the old context is the one thing that does not work, because the cached list is part of it. If you keep long threads, record which scopes the list was captured under so you know when it is stale.
curl -sS https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "'"$OPENAI_MODEL"'",
"input": "Call account_me and tell me my plan.",
"tools": [{
"type": "mcp",
"server_label": "sume",
"server_url": "https://mcp.sume.com/mcp",
"authorization": "'"$SUME_OAUTH_TOKEN"'",
"allowed_tools": ["account_me"],
"require_approval": "never"
}]
}'What to check before blaming the model
- Print the tool names in the
mcp_list_toolsitem: if only read tools show, the token was read-only. - Check the token's age. Sume access tokens last one hour with no refresh token, as this post explains.
- For unattended runs, an API key avoids the consent step entirely.
- Read the hosted MCP docs for the full gate table.
Sources
Related posts
More in Developers
- MCP OAuth without DCR: client ID metadata documents and issuer checks
MCP 2026-07-28 deprecates dynamic client registration for Client ID Metadata Documents and requires clients to validate iss. What it means for Sume.
- Python MCP SDK 2.3 subscriptions=False: a Sume wrapper that pulls
MCPServer(subscriptions=False) turns off push subscriptions in the Python SDK. A wrapper over Sume jobs can do without them by waiting in bounded slices.
- Python MCP SDK v1 now gets security fixes only: use v2 for new clients
The Python MCP SDK v1.x line gets security fixes only; v2 added MRTR and the 2026-07-28 spec. What that means when you connect a client to Sume's hosted MCP.
- MCP tasks/cancel vs Sume jobs_cancel: cancel works only before start
TypeScript SDK 2.3.0 adds tasks/get and tasks/cancel. Sume's jobs_cancel is narrower: it succeeds only before generation starts, then returns 409.
Written by Sume