Skip to main content
Glama
kaijfox

delegations-mcp

by kaijfox
README.md
# delegations-mcp

An MCP server that exposes a library of **delegation prompts** as tools. A smart
orchestrator LLM uses these tools to hand off bounded tasks to a reduced LLM or
coding agent, which receives a fully-constructed, self-contained prompt requiring
no broader context.

## Configuration

Config is discovered by walking up from the working directory, then merged with
`~/.delegations.toml`. Project config extends global; library blocks merge
field-by-field (project overrides global per field).

```toml
# .delegations.toml

[agent]
executable = "copilot"
args = ["--model", "gpt-4o-mini", "--prompt", "Instructions in: {prompt_path}"]

output_dir = "/tmp"   # where prompts and transcripts are written

[library.devteam]
path = "./library/devteam"
test_executable = "/usr/bin/python3"
test_args = ["-m", "pytest"]
```

`{prompt_path}` in agent args is replaced with the path to the rendered prompt file.

## Running

The server must run on the host filesystem — the agent it spawns edits files
directly and needs access to your project.

### stdio mode — recommended, zero config

The MCP client spawns the server automatically, inheriting its working directory.
Config is discovered from there. No setup required beyond installing the package.

MCP client config (e.g. Claude Desktop):

```json
{
  "mcpServers": {
    "delegations": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/delegations-mcp", "delegations-mcp"]
    }
  }
}
```

### HTTP mode — persistent session server

Useful when multiple agents share a session: the registry is loaded once, and
the async lock for `lock: true` delegations is shared across all connections.

Run from your project directory (so config discovery finds `.delegations.toml`):

```bash
cd /your/project
delegations-mcp --transport http --port 8000
# or: uv run --directory /path/to/delegations-mcp delegations-mcp --transport http
```

Connect your MCP client to `http://localhost:8000/mcp`. One server instance per
project — the working directory at startup determines which config and libraries
are used.

## Tools exposed

| Tool | Description |
|------|-------------|
| `list_delegations()` | Lists available delegations; refreshes registry from disk |
| `get_delegation(name)` | Returns full details and merged input schema for a delegation |
| `run_delegation(name, inputs)` | Runs a delegation; returns `summary`, `prompt_path`, `transcript_path` |

Delegation names are `library:delegation` (e.g. `devteam:implement`).

## Libraries

See [`library/devteam/README.md`](library/devteam/README.md) for the bundled
devteam library. See [`docs/library-implementation.md`](docs/library-implementation.md)
to author your own.

TDQS

B3.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_delegation retrieves details for a specific delegation, list_delegations lists all delegations and refreshes the registry, and run_delegation executes a delegation and returns results. There is no overlap in functionality, making tool selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: get_delegation, list_delegations, run_delegation. The naming is predictable and readable, with no deviations in style or convention.

Tool Count3/5

With only 3 tools, the set feels thin for a delegations management server, as it lacks operations like create, update, or delete delegations. However, the tools cover basic retrieval, listing, and execution, which might be sufficient for a minimal scope.

Completeness3/5

The tools provide read and execute capabilities (get, list, run), but there are notable gaps in lifecycle management, such as creating, updating, or deleting delegations. This could limit agent workflows that require full CRUD operations, though the existing tools support core usage.

Maintenance

ActivityInactive
ResponsivenessNo issues