← Back to blog

Zed MCP Setup for Social Posting: context_servers, Tool Permissions and a Locked-Down Profile

·Zed MCPcontext_serversZed agent panelMCP auto publishZed remote MCP server

Zed MCP Setup for Social Posting: context_servers, Tool Permissions and a Locked-Down Profile

TL;DR: Zed keeps MCP servers under context_servers in settings.json, not mcpServers. A remote server needs only a url (plus optional headers). Zed picks the transport from the entry’s shape. Keep the default tool approval at confirm for anything that publishes, and use a custom agent profile if the model keeps reaching for built-in tools instead of the server.

Most MCP guides are written for the mcpServers JSON shape. Paste that into Zed and, per third-party reports, the wrong key is simply ignored, with no error. Everything below comes from Zed’s official MCP page; settings move between releases, so check it against your version.

What you are connecting

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 arguments. The design is covered in how an MCP server for content publishing works.

On your side: install the PublishPort desktop client, log in to the platforms you want, and copy the connection address from the AI integration page. Treat that address like a password, since it can run commands on your machine.

Adding the server

You can use Settings → AI → MCP Servers → Add Server → Add Remote Server, or open the file with zed: open settings file. Per the docs, the UI writes the same entries:

{
  "context_servers": {
    "publishport": {
      "url": "<your connection address>"
    }
  }
}

The docs show two remote shapes. One has "headers": { "Authorization": "Bearer <token>" }. The other has only a url, and the docs note that when no Authorization header is configured, Zed prompts you to authenticate through the standard MCP OAuth flow. Which one applies depends on how your PublishPort address authenticates, so check the PublishPort docs instead of guessing.

There is no type field to set. A You.com setup guide says the transport is inferred: command means a local stdio process, url means a remote connection. That is a third-party description, not Zed’s own wording.

Check it worked

Zed’s docs say to watch the indicator dot beside the server name in the MCP Servers settings. Green with the tooltip “Server is active” means it is running. Anything else, search the command palette for the logs action (Grafana’s Zed guide cites zed: open logs) and look for the connection error. Some guides recommend a restart after hand-editing the file; I have not confirmed that it is always needed.

Make sure the model uses it

Zed’s docs are candid that “how reliably MCP tools get called can vary from model to model”, and suggest naming the server in your prompt. If that is not enough, create a custom profile where the built-in tools that could conflict are off and only the server’s tools are on. The docs’ own example (for a different server) sets "enable_all_context_servers": false and then lists the specific server’s tools under context_servers. For PublishPort that means enabling just list_capabilities and local_bash. A publishing-only profile also has a side benefit: the agent cannot edit your files in the same session it is posting.

Approvals: keep the default

For the native Zed agent, agent.tool_permissions.default controls approval (from v0.224.0; earlier versions used the agent.always_allow_tool_actions boolean):

For publishing, I leave confirm on and read the post text before approving. That is my practice, not a Zed requirement. The docs also describe per-tool rules with keys like mcp:<server>:<tool_name>, so you could auto-allow list_capabilities (read-only) while keeping local_bash on confirm. Server names here are whatever you called the entry, e.g. mcp:publishport:local_bash. I’d test that rule on a harmless call first, since the docs say pattern-based rules match an empty string for MCP tools and the default key is the main mechanism.

External agents

The docs say Zed forwards configured MCP servers to External Agents over the Agent Client Protocol, and that those agents may also read their own native config. If you run Claude or Gemini inside Zed, you may therefore get the server twice. If tools appear duplicated, check both places. The standalone setups are in Gemini CLI and Codex CLI guides.

Example: a release note to two platforms

I ask: “Summarise the latest changelog entry in this repo and publish it to Dev.to and Bluesky.” The agent calls list_capabilities(), reads each publish command’s --help, drafts, and waits for approval. Platform quirks differ, which is why the details live in automating Dev.to posts and posting to Bluesky. For other editors see Cursor, VS Code Copilot and Windsurf. If the agent has never published for you, rehearse with a throwaway post first.

Limits

Checklist

FAQ

Why does my server not appear after pasting a Claude Desktop config?

Probably the key. Zed reads context_servers.

Should the address go in project settings?

No. Project settings are normally committed, and the address can run commands on your machine. Use your user settings file. If it leaked, regenerate it in the client.

Does it work with any model in Zed?

Tool-calling reliability varies by model, per Zed’s own docs. Pick one with solid tool use and name the server in the prompt.

Is this the same address as in Claude or ChatGPT?

Same address, different config format per client. Connecting AI to social media posting covers the general picture.

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