VS Code Copilot MCP Setup for Social Posting: mcp.json, Input Variables and Trust Prompts

TL;DR: VS Code reads MCP servers from mcp.json, and the top-level key is servers, not mcpServers. A remote server needs "type": "http" and a url. Keep the connection address out of the repo by referencing a ${input:...} variable with "password": true, and leave tool confirmations on for anything that publishes.

If you have set up MCP in other editors, VS Code has two traps. The first is that its own format uses servers where most other clients use mcpServers. The second is that a workspace file is meant to be committed, which is exactly wrong for something that can run commands on your machine. This post covers a remote publishing server in VS Code with GitHub Copilot’s agent, and how to avoid both.

Config details below come from the VS Code docs on adding and managing MCP servers and the MCP configuration reference. Where I give a preference rather than a documented fact, I say so.

What the model gets

PublishPort exposes two generic tools instead of one plugin per platform. list_capabilities() reports which platforms are logged in on your computer. local_bash(cmd) runs a command there through the relay, using your own browser sessions, and the model reads each command’s --help to learn the arguments. The design is covered in how an MCP server for content publishing works.

Setup on your side: install the PublishPort desktop client, log in to the accounts you want to post from, and copy the connection address from the AI integration page. Treat that address as a credential, because it can run commands on your computer.

Where the file lives

The docs list several locations. The ones that matter here:

• .vscode/mcp.json in a workspace, using a top-level servers object (VS Code format).
• .mcp.json at the workspace root, using mcpServers (portable format shared with other tools).
• The user profile file, opened with the MCP: Open User Configuration command, available in every workspace.

The docs also say the guided MCP: Add Server flow lists the .vscode/mcp.json and user-profile destinations as deprecated-for-compatibility and recommends the portable destinations for new servers. That is a recent shift, so check which one your VS Code version offers.

My preference for a publishing server is the user-level file. Workspace files are meant to go into source control (“Include workspace configuration in source control to share MCP servers with your team”, per the docs), and a connection address does not belong in source control. If a repo is public and the address was committed, regenerate it in the client so the old one stops working.

The entry

A remote server uses type and url:

{
  "servers": {
    "publishport": {
      "type": "http",
      "url": "<your connection address>"
    }
  }
}

The reference says VS Code tries the HTTP Stream transport first and falls back to SSE if HTTP isn’t supported, so you normally don’t need to think about transport. If your setup expects a header, the optional headers object sits next to url. Check the PublishPort docs for what your setup needs, since I can’t know your auth method from here.

Compared with the other clients I have covered, this is the same shape as Cursor but with a different top-level key and an explicit type. Gemini CLI and Codex CLI each have their own variations.

Keep the address out of the file with an input variable

VS Code has a native mechanism for secrets. Declare an entry in inputs, then reference it as ${input:id}. The docs show ${input:...} working in headers, and say VS Code prompts for the value the first time the server starts and stores it for later use. Whether url accepts input variables is something the reference doesn’t spell out, so I would put the secret in a header if your address supports that, and test the URL case before relying on it. A pattern the docs do show explicitly:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "publishport-token",
      "description": "PublishPort connection token",
      "password": true
    }
  ],
  "servers": {
    "publishport": {
      "type": "http",
      "url": "<server URL>",
      "headers": {
        "Authorization": "Bearer ${input:publishport-token}"
      }
    }
  }
}

password: true masks what you type. With this layout a committed .vscode/mcp.json carries no secret, and each teammate supplies their own value. Treat the exact header your PublishPort setup uses as something to confirm in its docs; the Bearer form here is the VS Code docs’ example, not a statement about our relay.

One caveat from the docs: the Agent Host does not read .vscode/mcp.json directly, and VS Code forwards servers to it except those that need interactive input such as ${input:...}. If you run sessions on the Agent Host, an input-variable server may not be forwarded. In that case the docs point to the portable .mcp.json or ~/.copilot/mcp-config.json, with the secret supplied another way.

Trust prompts and approvals

Two separate gates apply:

1. Trust. Workspace servers inherit Workspace Trust. Trust the workspace and servers in .vscode/mcp.json can start without a separate prompt, even after their config changes. The docs warn you to review a repository’s MCP config before trusting it, since local servers run code. Servers from other sources get their own dialog when they first start or change. MCP: Reset Trust clears those decisions.
2. Tool confirmation. The quickstart notes you may be asked to confirm each tool invocation, and the Configure Tools button in the chat input lets you toggle individual tools on or off.

Publishing is public and awkward to retract, so I leave confirmations on and read the text before approving. This is my habit, not a requirement.

Example: release notes to two platforms

With the server running, I open the Chat view in agent mode and type: “Summarize the commits on this branch as a short post and publish it to Dev.to and LinkedIn.” The agent calls list_capabilities() to confirm both are online, reads each publish command’s --help, drafts the text and asks to confirm each call. Platform specifics differ, which is why they live in separate guides: automating Dev.to posts and scheduling LinkedIn posts.

If you have never let an agent publish for you, rehearse with a throwaway post first.

Limits

• The desktop client must be running and logged in when the agent posts.
• Using your own sessions doesn’t exempt you from platform rules. Near-identical text pushed to many places in a burst can still be throttled or treated as spam.
• VS Code’s MCP config is changing quickly (note the moved docs pages and the deprecated destinations above). Treat the official docs as the source of truth over this article.
• You are responsible for content quality and each platform’s terms.

Checklist

• servers.publishport with type: "http" and url, in the user-level file or with secrets via ${input:...}
• Server shows as running in the MCP servers list, with its tools listed
• Tool confirmations left on
• Connection address stored like a password, regenerated if exposed

FAQ

Why does my mcpServers config not work in .vscode/mcp.json?

That file uses servers. The mcpServers key belongs to the portable .mcp.json format. Use whichever matches the file.

Can I reuse my Cursor or Claude Desktop config?

VS Code has an automatic discovery setting (chat.mcp.discovery.enabled) that can read configs from sources including Claude Desktop, Cursor and Windsurf, per the docs. Explicit config is easier to reason about for something that publishes.

Is it safe to commit the workspace file?

Only if it holds no secret. Use an input variable so each person enters their own value.

What is the general picture across clients?

See connecting AI to social media posting.

Ready to try it? See PublishPort pricing and connect your first platform.