This PR overhauls extension registration in order to make it more
modular.
The `extension` crate now contains an `ExtensionHostProxy` that can be
used to register various proxies that the extension host can use to
interact with the rest of the system.
There are now a number of different proxy traits representing the
various pieces of functionality that can be provided by an extension.
The respective crates that provide this functionality can implement
their corresponding proxy trait in order to register a proxy that the
extension host will use to register the bits of functionality provided
by the extension.
Release Notes:
- N/A
This PR fixes an issue where the `settings` field for a context server
would not show up in the completions when editing the Zed settings.
It seems that `schemars` doesn't like the `serde_json::Value` as a
setting type when generating the JSON Schema. To address this, we are
using a custom schema of an empty object (as we don't yet have any other
information as to the structure of a given context server's settings).
Release Notes:
- context_servers: Fixed `settings` field not being suggested in
completions when editing `settings.json`.
This optimizes and fixes bugs in our logic for maintaining a set of
running context servers, based on the combination of the user's
`context_servers` settings and their installed extensions.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR exposes context server settings to extensions.
Extensions can use `ContextServerSettings::for_project` to get the
context server settings for the current project.
The `experimental.context_servers` setting has been removed and replaced
with the `context_servers` setting (which is now an object instead of an
array).
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This PR adds support for context servers provided by extensions.
To provide a context server from an extension, you need to list the
context servers in your `extension.toml`:
```toml
[context_servers.my-context-server]
```
And then implement the `context_server_command` method to return the
command that will be used to start the context server:
```rs
use zed_extension_api::{self as zed, Command, ContextServerId, Result};
struct ExampleContextServerExtension;
impl zed::Extension for ExampleContextServerExtension {
fn new() -> Self {
ExampleContextServerExtension
}
fn context_server_command(&mut self, _context_server_id: &ContextServerId) -> Result<Command> {
Ok(Command {
command: "node".to_string(),
args: vec!["/path/to/example-context-server/index.js".to_string()],
env: Vec::new(),
})
}
}
zed::register_extension!(ExampleContextServerExtension);
```
Release Notes:
- N/A
There are two issues with too/list and prompt/list at the moment. We
serialize params to `null`, which is not correct according to
context_server spec. While it IS allowed by JSON RPC spec to omit
params, it turns out some servers currently missbehave and don't respect
this. So we do two things
- We omit params if it would be a null value in json.
- We explicitly set params to {} for tool/list and prompt/list to avoid
it being omitted.
Release Notes:
- N/A
This PR reworks how the Assistant Panel references slash commands,
context servers, and tools.
Previously we were always reading them from the global registries, but
now we store individual collections on each Assistant Panel instance so
that there can be different ones registered for each project.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This PR depends on #19547
This PR adds support for tools from context servers. Context servers are
free to expose tools that Zed can pass to models. When called by the
model, Zed forwards the request to context servers. This allows for some
interesting techniques. Context servers can easily expose tools such as
querying local databases, reading or writing local files, reading
resources over authenticated APIs (e.g. kubernetes, asana, etc).
This is currently experimental.
Things to discuss
* I want to still add a confirm dialog asking people if a server is
allows to use the tool. Should do this or just use the tool and assume
trustworthyness of context servers?
* Can we add tool use behind a local setting flag?
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
We sadly have to change the underlying protocol once again. This will
likely be the last change to the core protocol without correctly
handling older versions. From here on out, we want to get better with
version handling. To do so, we introduce the notion of a string protocol
version to be explicit of when the underlying protocol last changed.
The change also changes the return values of prompts. For now we only
allow User messages from servers to match the current behaviour. We will
change this once #19222 lands which will allow slash commands to insert
user and assistant messages.
Release Notes:
- N/A
This PR does two things. It fixes some minor inconsistencies in the
protocol. This is mostly about handling JSON RPC notifications correctly
and skipping fields when set to None.
Second part is about improving the rendering of context server commands,
by passing on the description
of the command to the slash command UI and showing the name of the
argument as a CodeLabel.
Release Notes:
- N/A
Users can now pass an env dictionary of string: string mappings to a
context server binary.
Release Notes:
- context_servers: Settings now allow the configuration of env variables
that are passed to the server process
This PR adds support for completions via MCP. The protocol now supports
a new request type "completion/complete"
that can either complete a resource URI template (which we currently
don't use in Zed), or a prompt argument.
We use this to add autocompletion to our context server slash commands!
https://github.com/user-attachments/assets/08c9cf04-cbeb-49a7-903f-5049fb3b3d9f
Release Notes:
- context_servers: Added support for argument completions for context
server prompts. These show up as regular completions to slash commands.
Server can now include an optional description in a `prompts/get`
response. Zed will displayed the description as label of the slash
command.
Release Notes:
- context_servers: Servers can provide an optional description in
`prompts/get` responses that is displayed as the slash command label.
This commit proposes the addition of "context serveres" and the
underlying protocol (model context protocol). Context servers allow
simple definition of slash commands in another language and running
local on the user machines. This aims to quickly prototype new commands,
and provide a way to add personal (or company wide) customizations to
the assistant panel, without having to maintain an extension. We can
use this to reuse our existing codebase, with authenticators, etc and
easily have it provide context into the assistant panel.
As such it occupies a different design space as extensions, which I
think are
more aimed towards long-term, well maintained pieces of code that can be
easily distributed.
It's implemented as a central crate for easy reusability across the
codebase
and to easily hook into the assistant panel at all points.
Design wise there are a few pieces:
1. client.rs: A simple JSON-RPC client talking over stdio to a spawned
server. This is
very close to how LSP work and likely there could be a combined client
down the line.
2. types.rs: Serialization and deserialization client for the underlying
model context protocol.
3. protocol.rs: Handling the session between client and server.
4. manager.rs: Manages settings and adding and deleting servers from a
central pool.
A server can be defined in the settings.json as:
```
"context_servers": [
{"id": "test", "executable": "python", "args": ["-m", "context_server"]
]
```
## Quick Example
A quick example of how a theoretical backend site can look like. With
roughly 100 lines
of code (nicely generated by Claude) and a bit of decorator magic (200
lines in total), one
can come up with a framework that makes it as easy as:
```python
@context_server.slash_command(name="rot13", description="Perform a rot13 transformation")
@context_server.argument(name="input", type=str, help="String to rot13")
async def rot13(input: str) -> str:
return ''.join(chr((ord(c) - 97 + 13) % 26 + 97) if c.isalpha() else c for c in echo.lower())
```
to define a new slash_command.
## Todo:
- Allow context servers to be defined in workspace settings.
- Allow passing env variables to context_servers
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
