Dev Container devcontainer.json MCP: add Sume's hosted server

Add a mcp object under customizations.vscode in devcontainer.json and give it a servers entry of type http with url https://mcp.sume.com/mcp. VS Code's documentation says that when the Dev Container is created, VS Code writes those server configurations to the remote mcp.json file, so every contributor who opens the container gets the same Sume entry without touching their own settings.

The container behavior is from the VS Code MCP page, read on 2026-10-03. Sume's endpoint and auth are from the MCP quickstart and OAuth and API keys.

What does the devcontainer.json entry look like?

The page's example puts a servers map inside customizations.vscode.mcp, next to an image. Its example server is a local stdio one with command and args; for a remote server the same page's mcp.json example uses type http and a url, so the Sume entry below combines the two documented shapes. The block is valid JSON with no secrets in it.

{
  "image": "mcr.microsoft.com/devcontainers/typescript-node:latest",
  "customizations": {
    "vscode": {
      "mcp": {
        "servers": {
          "sume": {
            "type": "http",
            "url": "https://mcp.sume.com/mcp"
          }
        }
      }
    }
  }
}

Where does the entry end up, and who runs it?

The page states a general rule: MCP servers run wherever they are configured. Servers in your user profile run locally, and if you are connected to a remote and want a server to run there, define it in the workspace settings or the remote user settings (MCP: Open Remote User Configuration). A Dev Container is such a remote, which is why the generated file is the remote mcp.json.

For Sume this changes less than it would for a local server, because the work happens at mcp.sume.com either way. What changes is where the request originates and where credentials must be available.

How should credentials work inside the container?

Sume's OAuth path needs a sign-in on the MCP host's consent page; Read is locked on and Write is an opt-in toggle. The VS Code page does not say how an OAuth browser step behaves inside a container, so verify the sign-in works in yours. If it does not, the documented alternative is an API key: Sume accepts Authorization: Bearer <key> or x-api-key, and API-key sessions see the full tool set.

Do not put the key in devcontainer.json, which is committed. The VS Code page warns against hardcoding sensitive information and recommends input variables or environment files; keep the key in the container's environment from your secret store and confirm your VS Code version reads it for a remote entry.

How do I verify the container sees Sume?

Rebuild the container, open chat and ask for tools_list, the first call the quickstart suggests, then mcp_health. After OAuth, authenticated.auth_source should read mcp_oauth, and with a key it will show the API-key source instead. If the entry is missing, open the remote mcp.json and confirm VS Code wrote it.

Can I keep one entry for container and host?

Yes, by keeping the shape identical. The portable .mcp.json format uses mcpServers, while the dev container block uses servers inside mcp; the URL and type are the same in both. If someone opens the repository outside a container, the workspace file serves them, and inside the container the generated remote file does.

Avoid defining Sume twice with different names in the same session, because the model sees two similar tool sets and may pick either. Pick one place per environment and note it in the repository's contributing guide.