AI SDK MCP client authorization bearer header: what to send Sume
Set headers.Authorization to Bearer plus your Sume API key on the AI SDK http transport, and send only one credential header. An OAuth token is not an API key.
Put the key in the transport's headers as Authorization: Bearer <key> and send nothing else. Sume accepts a Bearer header or an x-api-key header, but a request carrying both is rejected with 401 unauthorized, so choose one. That key must live on your server, and it is a different credential from an OAuth access token.
Where does the header go in the AI SDK?
Vercel's AI SDK page builds the client with createMCPClient, an http transport, a url, and an Authorization header holding the word Bearer and the token. Point url at https://mcp.sume.com/mcp and fill the header from an environment variable such as SUME_API_KEY. The full snippet is in AI SDK 7 createMCPClient with Sume.
Can I send both Authorization and x-api-key?
No. Sume's authentication page says a request with both headers gets 401 unauthorized and the message Send only one API key credential. Neither header wins. The page names gateways and fetch wrappers that add their own Authorization header on top of a client that already sends x-api-key as the usual cause, so strip one.
Is an OAuth token a valid substitute for the key?
Both are bearer credentials on the same endpoint, but Sume's docs say they are not interchangeable, and the capabilities differ.
| Credential | How it reaches the client | Sees |
|---|---|---|
| API key | You set the header yourself | Full hosted tool set |
| OAuth token | The client runs the MCP OAuth flow and consent | Read-only tools; write tools only if Write was granted |
What should I never do with the token or key?
Sume's OAuth page says an OAuth token is not a Sume API key, and lists three things to avoid: storing OAuth tokens in CLI config, pasting them into prompts, and forwarding them to third-party providers. It also says not to mint API keys for hosted OAuth clients as a workaround. If a key shows up in logs or chat history, rotate it.
The authentication page adds that keys belong on trusted servers or CI secret stores, not in frontend JavaScript. Keep the AI SDK call in a server route, and let the browser talk to your route.
What does the key see once connected?
An API-key session sees write and paid tools. Execution still requires idempotency_key on mutating and paid calls, and max_spend_usd caps spend only when you pass it. See MCP OAuth and API keys before handing the tool list to a model.
How do I test the header safely?
Call mcp_health first. Sume's docs say it reports the auth source, and for OAuth sessions they name mcp_oauth as the value to expect. An API-key session should show a different source, which tells you which credential the server actually saw.
Then call tools_list. With a key you should see write and paid tools such as generate_image; a read-only OAuth session would not. Keep the key out of the prompt and out of any log line you print while debugging, and rotate it if it ever appears in one.
Sources
Related posts
More in Developers
- AI vendor risk assessment: questions and where to look
An AI vendor risk assessment adds training, model providers and spend to a SaaS review. The questions, and where Sume's public pages answer them.
- API audit log: what you can trace on Sume's media API
Sume's docs describe no audit-log endpoint. Job records, the usage ledger and request ids give a trail, but not which API key made a call.
- API changelog: where Sume lists changes, and how to read it
Sume keeps a public changelog, newest first, with a version, a date and short notes. It does not mark breaking changes, so also watch the retiring list.
- API sandbox environment: test a paid API without paying
An API sandbox is a separate test environment with fake or free results. Sume has none, so test with its spec, free checks and spend caps.
Written by Sume