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.

4 min readSume
All posts

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.

OpenAI list caching against Sume scope gating (read 2026-10-04)
FactSourceConsequence for Sume
The tool list is not refetched while mcp_list_tools is in contextOpenAI MCP guideA read-only list stays read-only for that conversation
mcp:read is required and read-only; mcp:write is opt-in on the consent pageSume OAuth docsWrite tools only appear for a token that holds mcp:write
Hidden tools return insufficient_scope when calledSume tools and gatesA model that guesses a name still gets refused
An API key sees the full tool setSume hosted MCP docsA 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_tools item: 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

All Developers posts

Written by Sume