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.

4 min readSume
All posts

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

VS Code 1.140, Sep 30, 2026 (read 2026-10-03)
ChangeWhy it matters for a media MCP server
Copilot harness on Agent Host ProtocolThe agent may run outside the editor process; verify the server from there.
Multi-folder sessionsOne session spans folders, so a single entry should serve all of them.
Remote task delegationA delegated task runs with some credential; know which.
MCP servers in portable config files shared across Copilot toolsOne 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_health to confirm the endpoint and the auth source.
  • tools_list to see which tools that session can use.
  • A paid tool with dry_run=true to 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

All Developers posts

Written by Sume