Commit Graph

4 Commits

Author SHA1 Message Date
David Soria Parra
5bae6eb493
context_servers: Completion support for context server slash commands (#17085)
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.
2024-08-29 16:56:58 -04:00
David Soria Parra
cf0a8a7a1a
context_servers: Add ability to provide labels for prompt outputs (#17077)
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.
2024-08-29 08:13:03 -04:00
Kyle Kelley
0fdc9d0f05
context_servers: Log errors from detached context server tasks (#16377)
Logged several of the detached tasks that before would silently fail if
the context server wasn't in compliance.

Release Notes:

- N/A
2024-08-16 13:50:19 -07:00
David Soria Parra
02ea6ac845
context_servers: Add initial implementation (#16103)
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>
2024-08-15 10:49:30 -04:00