LABSCO SUMMARY

A config file where a codebase used to be.

The reason to pick this over writing a server is that the three things a server actually offers — content, prompts and callable functions — are all declarative here, and resource watching means the content stays live. If you already have Python functions worth exposing, pointing at their import paths is a shorter route than wrapping each one by hand.

What it is

A server that reads its whole environment from a YAML file. You declare which content the model can see, which prompts it can use, and which Python functions it can call, and the server exposes them over MCP. Building a custom server becomes editing a config file rather than writing an implementation.

What you get

Resources of several kinds — files (PathResource), inline text (TextResource), the output of a CLI command (CLIResource), Python source (SourceResource), the result of a Python callable (CallableResource), and images (ImageResource)
Resource watching and hot-reload, so a glob like ./src/**/*.py stays current as the files change, with exclusion patterns
Tools from your own code — register a Python function by its import path, or pull a whole toolset from an OpenAPI spec; parameters are validated before the call
Prompts as templates with validated arguments, defined statically, generated from a Python function, or loaded from a file, with completion suggestions for their arguments
Global settings in the same file: timeout, retry count, log level, extra paths and requirements
Transports for both cases — stdio by default, SSE or Streamable HTTP for web clients, configurable with host, port and CORS origins

Requirements

No account and no key for the server itself, though tools you wire in may need their own. Run it with uvx mcp-server-llmling start path/to/your/config.yml — that command is the whole client config for Claude Desktop or Zed. Everything else is the YAML: resources, tools, toolsets, prompts and global_settings. For OpenAPI toolsets, bundling the spec with Redocly CLI first resolves references cleanly, and it is used automatically if installed. There is also a Python API if you would rather start the server yourself. Package mcp-server-llmling at 1.0.0.

Setup effort

One command — uvx mcp-server-llmling@latest

See installation options

USE CASES

01

Giving an assistant your project's docs and source as context

Declare the globs as resources with watching on, so the model reads the current files rather than a stale paste.

02

Exposing functions you already wrote

Name the import path in the tools section instead of writing an MCP wrapper for each one.

03

Turning an existing REST API into tools

Point a toolset at its OpenAPI spec and get the operations as callable tools.

04

Standardizing how a team asks the same question

Define the prompt once with validated arguments, and everyone's version of it matches.

05

Serving the same environment to a web client

Switch the transport to SSE with a host, port and CORS origins, keeping the same YAML.

BEFORE YOU INSTALL

What to know first

Requires

uvx on PATH

Where it runs

Both documented clients run the server on your machine.

INSTALLATION

Connect your client

Server setup

TERMINAL

uvx mcp-server-llmling@latest

MCP Clients

Zed

ZED · JSON

{
  "context_servers": {
    "llmling": {
      "command": {
        "env": {},
        "label": "llmling",
        "path": "uvx",
        "args": [
          "mcp-server-llmling",
          "start",
          "<YOUR_PATH_TO_CONFIG>"
        ]
      },
      "settings": {}
    }
  }
}

Claude Desktop

CLAUDE DESKTOP · JSON

{
  "mcpServers": {
    "llmling": {
      "command": "uvx",
      "args": [
        "mcp-server-llmling",
        "start",
        "<YOUR_PATH_TO_CONFIG>"
      ],
      "env": {}
    }
  }
}

LLMling