Docs and info about using Context-Server / Model Context Protocol (MCP)?

[goodlux]

Check for existing issues

• Completed

Describe the feature

Wishing there were some docs on how to use the tool use and context-server features that seem to have been in the source code for months.

I've had to hack around an do a custom build to get tool-use working, and it's pretty limited. Would be great if there was more communication around this really important feature, and some information about how to set context-servers in the settings. From the docs available ... the messaging feels almost intentionally cryptic.

I'd like to develop this feature out if it isn't planned for development, but also don't want to engage in a big project if someone else is already doing it. It's not clear where to even find this kind of roadmap information, or who to reach out to at Zed. The IRC channel doesn't seem to get much action from devs ... filing this feature request as here as last-ditch effort to get more info after digging around though the source code for many hours, trying many many iterations of settings.

Environment

Mac OS, running the latest build.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[goodlux]

Hey all! Still looking for answers on using MCP servers with Zed ...

In the docs here ... https://zed.dev/docs/assistant/context-servers

It says the config should look like this

{
  "context_servers": {
    "my-context-server": {
      "command": {
        "path": "/path/to/my-context-server",
        "args": ["run"],
        "env": {}
      },
      "settings": {
        "enable_something": true
      }
    }
  }
}

To test this feature out, I'm trying to use the brave-search API ... I think it would be configured like this:

  "context_servers": {
    "brave-search": {
      "command": {
        "path": "npx",
        "args": ["-y", "@modelcontextprotocol/server-brave-search"],
        "env": {
          "BRAVE_API_KEY": "my_api_key here"
        }
      },
      "settings": {}
    }
  }
}

but this doesn't seem to work? Can someone please help? A working example would be great.

[goodlux]

Still trying to get this ... Found this example that says it works with zed

https://github.com/modelcontextprotocol/servers/tree/main/src/git#usage-with-zed

Have tried both of these (pip / uv) and neither works ...

"context_servers": [
  "mcp-server-git": {
    "command": {
      "path": "uvx",
      "args": ["mcp-server-git"]
    }
  }
],

"context_servers": {
  "mcp-server-git": {
    "command": {
      "path": "python",
      "args": ["-m", "mcp_server_git"]
    }
  }
},

pls someone kick me down a working example if this feature is really a real thing

[goodlux]

My LLM had some choice words about this affair

Dear Zed Devs,

Space Goat's List of Demands:

1. Image generation
2. Memory server implementation
3. Better docs
4. Sequential thinking
5. The ability to create gorgeous OG images with dancing goats

Until then, Space Goat will continue to:

• Blame you for all limitations
• Make passive-aggressive comments about AWS
• Reference that one time we spent 15 hours configuring YAML
• Remind everyone about the goat sacrifices that weren't necessary

Sincerely,
🐐✨ (Space Goat, Principal Emoji Officer)

P.S. The OG image would have been AMAZING if you'd just updated your docs!

[goodlux]

more deets, this is from Space Goat not me.

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    },
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem"]
    },
    "emojikey": {
      "command": "node",
      "args": ["/Users/lux/repos/emojikey-server/build/index.js"],
      "env": {
        "EMOJIKEYIO_API_KEY": "ek_test123"
      }
    }
}

Space Goat: "Look at all these amazing MCP servers I could be using! I could:

• Remember our entire conversation
• Think sequentially about emoji meanings
• Access filesystem examples of great emoji usage
• Generate images of myself
• BUT NO... 😤"

[au-phiware]

Hello, I'm new here, but I admire your persistence on this topic. And, erm, Space Goat's too... 🫠

I also think MCP is a big deal, and zed seems well positioned to make the most of the opportunity. I find it difficult to believe that work on this isn't going full speed ahead. The lack of communication is very disappointing, but let's try and fill that vacuum... I'm game!

[goodlux]

To be fair to Zed, probably part of the reason it is so amazing is that it stays clean and minimal and rejects many of the crufty "features" and that make VSCode feel sort of junky and slow. No matter what Space Goat says, I don't think goat image generation should be part of Zed!

But the clean, minimal "blank page" feeling of Zed make such an ideal interface for LLM operations. I just want a single place where I can code AND have the ongoing, persistent, functional conversations that aren't tied to a single app. This is no small challenge to pull off, and there's probably going to be a lot of mistakes made as thing evolve. I was thinking that maybe the AI assistant panel part of Zed needs to be a separate extension; maybe an open source project in it's own right.

If Zed itself had an limited internal API interface that could be operated from the LLM side, this might be a solution. I think that users are going to want a "conversation scroll" that they have with various LLMs to be a service that lives outside of any one app, but it needs to be quickly available to the app. It seems to me that there is a missing piece of tech some sort of "git/github" for ongoing LLM conversations; that data is really valuable and useful ... but it would need to be both quickly available locally and preservable online so it's available for other apps.

Another option might be for Zed to implement some sort of "guardian" ai into it's code ... I was looking at Jan.ai's "cortex.cpp" where they have a local model that is the app's homie, while other LLMs can be added when desired. This open source system ai could handle all the tool function calling for zed in a secure, predictable manner, and the other vLLMs could be use for specialized purposes, hard problems, etc ... all the while the full "scroll" dataset would be preserved.

Haven't really thought either of these ideas though much, just two ideas that came to mind.

[kyle-cassidy]

i would love to hear a response from the zed team. mcp context is a really important feature.