VS Code 1.140 shared MCP config files: what goes in the Sume entry
VS Code 1.140 lets MCP servers live in portable config files shared across Copilot tools. For Sume the entry is one URL, and no key belongs in the file.

A shared MCP config file for Sume needs one thing: the URL https://mcp.sume.com/mcp. With OAuth, the sign-in happens in the client, so no API key has to sit in a file that several Copilot tools, and your repository, can read.
The VS Code updates page says 1.140 (Sep 30, 2026) supports MCP servers in portable config files shared across Copilot tools, on top of a Copilot harness built on the Agent Host Protocol.
What 1.140 lists
| Change | Why it matters for a media MCP server |
|---|---|
| Copilot harness on Agent Host Protocol | The agent may run outside the editor process; verify the server from there. |
| Multi-folder sessions | One session spans folders, so a single entry should serve all of them. |
| Remote task delegation | A delegated task runs with some credential; know which. |
| MCP servers in portable config files shared across Copilot tools | One Sume entry can serve several tools. |
What belongs in the file
Sume's quickstart shows the minimal remote entry for a client that uses an mcpServers map. The only required value is the URL.
{
"mcpServers": {
"sume": {
"url": "https://mcp.sume.com/mcp"
}
}
}What should stay out
Hosted OAuth is the preferred path for interactive clients. The client discovers Sume's protected-resource metadata from the endpoint, sends you to the consent page on the MCP host, and exchanges a PKCE code for a token. None of that touches the file.
An API key is the other option, sent as Authorization: Bearer or x-api-key. It sees the full tool set, so treat it as a secret and keep it out of any file that is committed or shared between tools. The docs also say an OAuth token is not an API key and must not be stored in CLI config or pasted into prompts.
Check it from each tool that reads the file
A shared file does not guarantee that each tool signs in or shows the same tools. After adding the entry, run the same read-only calls in every tool that uses it.
mcp_healthto confirm the endpoint and the auth source.tools_listto see which tools that session can use.- A paid tool with
dry_run=trueto confirm write scope without spending.
Scope is per sign-in, not per file
Each tool that completes OAuth gets its own consent. The default grants mcp:read only, and Write is a toggle on the consent page that is off by default. One tool may therefore show paid tools while another shows only read tools, even though both read the same entry.
If a tool reports insufficient_scope on generate_image, the fix is on that tool's consent, not in the shared file.
Sources
Related posts
More in Developers
- Abort waitForJob on SIGTERM, then resume from the stored job id
On a deploy, abort waitForJob with an AbortController on SIGTERM, keep the Sume job id, and resume the wait after restart. Aborting stops the wait, not the job.
- waitForJob throws on a failed poll: resume by job id in TypeScript
Unlike waitForRun, waitForJob has no transient-failure budget: one failed status read after the client's retries throws. Wrap it and resume by job id.
- waitForRun maxTransientFailures: how many bad polls it absorbs
waitForRun absorbs 6 consecutive 429, 5xx or network read failures before it throws. How the streak resets, backoff works, and onTransientError fits in.
- Wan 3.0 at 30 fps and 2 to 30 s: the Sume model id
Model Studio lists Wan 3.0 at 480P to 1080P, 2 to 30 s, 30 fps. On Sume the id is wan-3.0, 2 to 30 s; first and last frames go in frame_images.
Written by Sume