ollama-mcp-delegate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OLLAMA_MCP_LANG | No | Picks the language of the prompt sent to the local model and of the prose in the receipt. `auto`, the default, decides per call from the text of the instruction, falling back to the machine locale. | auto |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| local_editA | Delegate a MECHANICAL code edit to the local model. USE THIS INSTEAD OF Read+Edit whenever the change is well-specified and does not need cross-file reasoning: renames, docstrings and comments, type annotations, adding a logging line, applying a pattern you already decided on, boilerplate, test scaffolding, formatting fixes. Do NOT read the files first -- that spends the tokens this tool exists to save.
Pass file paths inside The edit is applied to the working tree only if it passes the project's verification gate; otherwise it is rolled back and you get an ESCALATE. Args: workspace_root: Absolute path to the repository root. instruction: Self-contained task, naming the exact files and the exact change. The local model sees nothing else -- no conversation history. tier: "fast" for mechanical/high-volume work, "deep" for edits needing real code reasoning (slower, larger model). Returns: A receipt: files changed with line counts, gate verdict, timing. Never file content. |
| local_explainA | Ask the local model to read the repository and answer a FACTUAL question about it. USE THIS INSTEAD OF Read/Grep when you need to know what is in files but do not need the files themselves in context: "where is X defined", "what does module Y do", "which call sites pass argument Z", "summarize this log". Read-only: the local model has no write tools for this call. Args: workspace_root: Absolute path to the repository root. question: A specific, answerable question. Vague questions get ESCALATE. tier: "fast" (default) or "deep" for multi-file reasoning. answer_budget: Soft character cap on the answer. Keep it small. Returns: A dense answer with path:line citations, or ESCALATE. Never file dumps. |
| local_verifyA | Run this project's verification gate (from .ollama-mcp.toml, or autodetected) and return a COMPACT triage of any failures. USE THIS INSTEAD OF running lint/typecheck/test commands through Bash when you only need to know whether it passes and what broke -- raw tool output is often thousands of tokens. Args: workspace_root: Absolute path to the repository root. triage: If true and the gate fails, the local model summarizes the failures into a short actionable list instead of returning raw output. Returns: PASS, or a short list of what failed and where. |
| local_statusA | Check that local delegation is actually available and see what it has saved. Cheap -- no model inference. Call this once at the start of a session if you intend to delegate, and whenever a local tool fails unexpectedly. Args: workspace_root: Absolute path to the repository root. Returns: Ollama health, configured model tiers, whether they are installed, the gate configuration, and estimated tokens avoided so far. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct operation: edit (write), explain (read-only query), verify (gate runner), and status (health check). The descriptions explicitly delineate when to use each and even contrast them against native Read/Edit/Bash, leaving no meaningful overlap.
All four tools follow a strict local_<verb> pattern (local_edit, local_explain, local_verify, local_status). The convention is predictable and unambiguous throughout.
Four tools is well-scoped for a delegation server, and each one earns its place covering a distinct phase of the delegate workflow. No redundancy or filler.
The surface covers the core delegation lifecycle: availability check, read-only queries, edits, and verification. Minor gaps exist (e.g. no explicit undo/rollback or batch-edit operation), but agents can work around these.