OpenAI remote MCP does not store authorization: resend a Sume key
OpenAI does not store the MCP authorization value, so resend it on every request. Sume accepts a bearer API key or OAuth; keep either one server-side only.

OpenAI's remote MCP tool does not keep your authorization value between requests, so your code has to send it again on every request. With Sume's hosted MCP at https://mcp.sume.com/mcp, the value you would send is an OAuth access token or a Sume API key, and both stay on your server. The Sume docs have no OpenAI-specific guide, so the steps below combine the OpenAI page with Sume's auth matrix.
What each page says
| Item | OpenAI | Sume |
|---|---|---|
| Credential storage | authorization value is not stored; resend every request | Not applicable; your server holds the key |
| Connector style | Legacy connectors for older models; new work uses server_url or tunnel_id | One URL: https://mcp.sume.com/mcp |
| Accepted credentials | Your server passes what the MCP server expects | OAuth access token, or API key as Authorization: Bearer or x-api-key |
| Default capability | Approval controlled by require_approval | OAuth mcp:read sees read-only tools; mcp:write is a consent toggle; API key sees the full set |
What this means for your build
Because the value is not stored, every request your backend builds for the Responses API must include the credential. That puts a long-lived Sume API key in your request builder, which is fine on a server and wrong in a browser or mobile bundle. The Sume docs say an API key spends credits and there is no browser-safe variant.
An API key gives the full hosted tool set. Paid and write calls still need an idempotency_key, and spend is governed by wallet and admission. OAuth is the preferred path for interactive clients, and it starts read-only, so paid tools such as generate_image return insufficient_scope until the user grants mcp:write. There is no mcp:paid scope.
Checklist
- Keep the key in a secret store and build the MCP tool entry per request.
- Do not paste keys into chat or logs. The Sume docs list API keys and signed URLs as unsafe to log.
- Start with a read-only discovery call,
tools_listormcp_health, before any paid tool. - Rotate the key if it ever appears in a log line or error message.
Request flow
A single user turn can involve several requests: one to list tools, one per tool call, and a final answer. If each is a separate Responses API request, each needs the credential. Build the tool entry in one function that reads the key from your secret store, so the key is not copied into prompts, templates or logs. Sume's docs list API keys and signed URLs as unsafe in logs, and they ask you to share request ids instead.
For a multi-tenant product, resolve the credential per customer at request time. Because Sume's key selects the workspace, the right key means the right workspace and the right wallet, with no workspace argument to get wrong.
Sources
Related posts
More in Integrations
- OpenAI remote MCP does not store authorization: resend your Sume key
OpenAI's remote MCP tool does not keep the authorization value, so every Responses call must carry it. What that means for a Sume key and how to rotate it.
- OpenAI remote MCP is third-party: what a Sume tool call sends
OpenAI says remote MCP servers are third-party services with their own retention. Here is what a Sume tool call carries, and what to keep out of its arguments.
- Pinterest bulk upload: 200 Pins per CSV with Sume media URLs
Pinterest bulk creation takes up to 200 images or videos per upload from a CSV with Title, Media URL and board. Fill the Media URL column from Sume renders.
- Pub/Sub push ack codes and a Sume webhook relay with a signature check
Pub/Sub treats only 102, 200, 201, 202 and 204 as acks. Verify Sume's sume-v1 signature at the edge, publish, return 2xx, and let Pub/Sub retry the workers.
Written by Sume