Enables delegation of text generation tasks to local Ollama models, allowing the main agent to offload token-heavy work to a local LLM.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@local-llm-mcp generate a pytest skeleton for a user model"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
One afternoon I watched Claude Code reach for a frontier model — the good one, the one my credit card feels — to generate an __init__.py. Then a pytest skeleton. Then a throwaway first draft of a function I was about to rewrite anyway.
That's when it clicked: I was paying senior-engineer rates for a senior engineer's typing. The thinking — reading my repo, planning the change, reviewing the diff, deciding what's safe to ship — that's what the expensive model is for. The boilerplate is not.
So I did the lazy thing. I already had LM Studio running on my Mac, doing nothing between prompts. Why not let the cheap model on my own machine handle the grunt work, and keep the frontier brain for the calls that actually matter?
One snag: my Mac has 24GB of RAM, and local models cheerfully ate all of it until the whole session froze. So the first thing I built wasn't the clever delegation — it was a dumb RAM valve that refuses a local call when memory runs low. Everything else grew around that.
That's all local-llm-mcp is: a small MCP server that hands your coding agent an intern. The intern only ever returns text — it can't read your repo, edit a file, or run a command — and the senior model reviews everything before a single line changes.
The whole idea in one line: senior model decides, local model types.
Related MCP server: Relay
git clone https://github.com/HenryLinyy/local-llm-mcp
cd local-llm-mcp
bash setup.sh # venv + registers with Claude Code & Codex + smoke testThen open a fresh Claude Code or Codex session. No API keys needed — local backends work out of the box. setup.sh even picks a RAM threshold based on your machine.
Claude Code / Codex the senior — reads the repo, plans, edits, runs tests, reviews
local-llm-mcp hands one bounded task to the intern over MCP
Ollama / LM Studio the intern — drafts boilerplate, tests, docs, summaries, for $0A local 7B model costs $0 per token. My frontier agent does not. The rest is arithmetic — and I'll get to the arithmetic honestly below.
The intern can't touch your repo. That's not a missing feature; it's the point. I never have to trust the cheap model with anything that matters — worst case, it hands back a bad draft and the senior throws it out.
✅ Hand to the intern | 🚫 Keep with the senior |
README & docstring first drafts | Final architecture decisions |
Boilerplate, config, glue code | Security & correctness sign-off |
| Anything that edits the repo |
Long-file summaries | Running shell commands |
Repetitive format conversions | Applying a patch unreviewed |
"Sketch 3 alternative approaches" | Any judgment call |
My rule of thumb: if a wrong answer is cheap to catch, delegate it. If it's expensive to catch, don't.
There's no API to learn. I just tell the senior to delegate, in plain English:
Use ask_local_model with backend="ollama" to draft a pytest suite for this module.
Don't apply it — review it first, then edit the repo yourself.Call local_status. If a local model is up, use it for boilerplate.
Otherwise fall back to backend="deepseek".More of my go-to prompts are in examples/claude-code-prompts.md.
Local backends need nothing but a running server. Cloud backends are optional — they read their key from an env var or keys.json, never from source.
Backend | Type | Protocol | Default URL | Default model | Key |
| local | OpenAI |
|
| — |
| local | OpenAI |
|
| — |
| local | OpenAI |
| auto | — |
| local | OpenAI |
| auto | — |
| local | OpenAI |
| auto | — |
| cloud | OpenAI |
|
|
|
| cloud | OpenAI |
|
|
|
| cloud | OpenAI |
|
|
|
| cloud | OpenAI |
|
|
|
| cloud | OpenAI |
|
|
|
| cloud | Anthropic |
|
|
|
Every URL and default model is env-overridable. Running something exotic? Add a custom backend — no Python required.
Tool | Purpose |
| Send a prompt to a backend, get back text + usage metadata. |
| Show configured backends, URLs, protocols, key status. |
| Memory, guard state, backend reachability, config paths. |
| List model IDs from backends that expose |
| Add, update, or remove a custom backend live. |
| Reload |
| Change the RAM / exclusivity guards live. |
| Pin a system prefix for prompt-cache-friendly cloud calls. |
I learned this the hard way, so you don't have to. Two guards:
RAM valve — local calls are refused when free memory drops below LOCAL_LLM_MIN_FREE_GB. This is the feature that exists because I froze my own machine one too many times.
Exclusive backend — when a heavy local server (ds4 by default) is up, other local backends stand down instead of fighting over memory.
Tune them live, no restart: set_guard(min_free_gb=8), set_guard(exclusive_backend="none").
And secrets never enter git — keys.json, config.json, and custom_backends.json are all gitignored; keys load from env vars or a chmod 600 file. Cloud backends skip the RAM guard, but they send your prompts to a third party and may cost money — read SECURITY.md before pointing one at proprietary code.
Here's where most READMEs lie to you with a big number. I'm not going to.
The honest answer is it depends entirely on your workload, so instead of inventing a percentage I shipped a harness to measure your own:
python scripts/benchmark.py --backend ollama --model qwen2.5-coder:7b --out results.jsonlCompare premium-only vs. delegated mode with BENCHMARK.md and the runbook. Trust your numbers — not mine, and definitely not a number a README made up to get you to star it.
Add it straight from the tool:
set_backend(name="my_qwen", base_url="http://localhost:9000/v1", default_model="qwen3-coder", local=1, protocol="openai")…or drop it in custom_backends.json and call refresh_backends. See examples/custom_backends.openrouter.json.
python3 -m venv .venv
.venv/bin/python -m pip install -e .
# Claude Code
claude mcp add local-llm -s user -e LOCAL_LLM_MIN_FREE_GB=16 -- "$PWD/.venv/bin/python" "$PWD/server.py"
# Codex
codex mcp add local-llm --env LOCAL_LLM_MIN_FREE_GB=16 -- "$PWD/.venv/bin/python" "$PWD/server.py"python -m unittest discover -s tests -v
python scripts/smoke_test.pyCI runs both on Python 3.10, 3.11, and 3.12.
Does the intern touch my files? Never. It returns text; every edit goes through the senior (your main agent).
Do I need a beefy GPU? No. 7B coder models run on modest hardware, and the RAM valve keeps you from OOMing. No local model handy? Point the intern at a cheap cloud backend.
Is this a fusion model or an autonomous agent? Neither. It's a delegation layer — a tool your existing agent calls.
Why not just switch my agent to a cheap model entirely? Because I want the frontier model's judgment and the cheap model's typing. This keeps both.
Windows / Linux? The server is cross-platform (the RAM guard reads vm_stat on macOS, /proc/meminfo on Linux). The shell helpers are macOS/zsh-flavored.
qwable — a local multi-model gateway and agent runtime for Codex & Claude Code on Apple Silicon.
Conclava — a council of local LLMs with task-aware routing and multi-model deliberation.
Issues and PRs welcome — see CONTRIBUTING.md. If this saved you some tokens, a ⭐ tells me it was worth open-sourcing.
MIT — see LICENSE. Built by someone who got tired of paying frontier prices for import os.
Send a prompt to a backend model and return text plus metadata.
Delegated models cannot read or edit files by themselves. They only return text to the main agent, which remains responsible for validation, edits, and tests.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| prompt | Yes | ||
| system | No | ||
| backend | No | lmstudio | |
| max_tokens | No | ||
| temperature | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key limitations: delegated models cannot read/edit files, only return text, and the main agent handles validation/edits/tests. However, it does not mention other behaviors like authentication or rate limits, though those may be less relevant for a local model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently front-loading the core action and return value in the first sentence and adding behavioral context in the second. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the output schema existing, the description lacks guidance on parameter usage (e.g., prompt format, model selection, temperature tuning). It covers behavioral context but is incomplete for a tool with 6 parameters, leaving the agent to infer usage from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema) and the description does not explain any of the 6 parameters (prompt, model, system, etc.). It adds no meaning beyond the schema's type/name information, failing to compensate for the lack of param descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Send a prompt to a backend model') and its output ('return text plus metadata'). It also distinguishes from sibling tools (which are configuration/list tools) by focusing on actual model interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that delegated models cannot read/edit files, and the main agent retains responsibility for validation/edits/tests. This provides context on when to use this tool (offloading reasoning) but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all built-in and custom backends, including key status and protocol.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not explicitly state that the operation is read-only or disclose any behavioral traits beyond the basic listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence with no redundant information. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and no parameters, the description covers the essential purpose. Could mention that it returns a list of backends with their status and protocol, which it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters, so no additional meaning needed. Baseline 4 for 0 params; description adds no param info but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all built-in and custom backends, including key status and protocol, which is a specific verb and resource. It distinguishes from siblings like refresh_backends and set_backend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites or context for listing backends.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List model ids on a backend. Works when the backend exposes GET /models.
| Name | Required | Description | Default |
|---|---|---|---|
| backend | No | lmstudio |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It implies a read-only operation but does not explicitly state it, nor does it mention other important aspects like authentication needs or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences, front-loaded with the purpose. No unnecessary words, though it could add more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it lacks context about sibling tools and the impact of the 'backend' parameter, making it moderately incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the 'backend' parameter in detail. It only indirectly references it, missing the chance to clarify allowed values or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (model ids on a backend). However, it does not differentiate from the sibling tool 'list_models', which could cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a precondition (backend exposes GET /models) but provides no guidance on when to use this tool over alternatives like 'list_models' or 'list_backends'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias for list_local_models.
| Name | Required | Description | Default |
|---|---|---|---|
| backend | No | lmstudio |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details such as read-only nature, side effects, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively short and lacks substantive content, failing to earn its minimal length. While concise, it is not useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no explanation, the description is far from complete. The presence of an output schema does not compensate for the lack of input semantics and purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'backend' parameter (0% coverage), and the description adds no information about its meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is an alias for list_local_models, but does not define what list_local_models does, leaving the core purpose ambiguous. It relies on external knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_local_models or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report memory, guard config, backend reachability, and config file paths.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only lists what is reported, without mentioning that the operation is read-only, non-destructive, or has any side effects. The term 'report' implies a safe read, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the reported items. There is no redundant wording, and the purpose is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter status tool, the description adequately covers its functionality. The presence of an output schema may provide further detail, but the description alone offers a complete picture of what the tool reports. Minor improvement would be mentioning it is a snapshot of current state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description naturally adds no parameter information beyond the schema. With 100% schema coverage for parameters (none exist), the description is not required to elaborate. Baseline 4 applies as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports four specific categories: memory, guard config, backend reachability, and config file paths. This distinguishes it from sibling tools like 'ask_local_model' or 'set_backend', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context in which the tool is appropriate. The agent must infer usage from the name and reported fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload custom_backends.json without restarting the MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It fails to mention side effects (e.g., clearing state), error handling for invalid files, or confirmation of success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, very concise. Could be slightly more informative (e.g., noting it returns success/failure) but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema (not shown), the description is adequate for a simple operation but lacks mention of return value or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Per guidelines, baseline is 4; the description adds no parameter info because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reload custom_backends.json') and the context ('without restarting the MCP server'). It distinguishes itself from sibling tools like set_backend or list_backends, which focus on modification or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as set_backend or list_backends. The description does not specify prerequisites or scenarios where reloading is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, update, or remove a custom backend in custom_backends.json.
Args: name: Backend id, e.g. my_local_qwen. Lowercase letters, numbers, _ or -. base_url: OpenAI-compatible or Anthropic-compatible base URL. default_model: Model id. Empty means auto-resolve from /models where possible. local: 1 for local RAM-guarded backend, 0 for cloud backend. api_key_env: Optional environment variable name for the API key. protocol: openai or anthropic. remove: 1 removes the custom backend.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| local | No | ||
| remove | No | ||
| base_url | No | ||
| protocol | No | openai | |
| api_key_env | No | ||
| default_model | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains key behaviors: create/update/remove via the 'remove' parameter, local vs cloud with 'local', and optional API key. However, it omits details about file modification persistence or required permissions, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise and well-structured, with a clear opening sentence followed by parameter definitions in a bullet-like format. It is front-loaded and efficient, though slightly verbose with the 'Args:' prefix and multiple lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, create/update/delete operations, no annotations, and an output schema), the description covers essential aspects. It explains all parameters and actions, though it could optionally mention the return format or error handling, which is partially mitigated by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It richly describes all 7 parameters, including allowed characters for 'name', auto-resolve for 'default_model', and protocol selection. This adds significant meaning beyond the schema's bare type/default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create, update, or remove a custom backend in custom_backends.json.' It uses a specific verb ('set') and resource ('backend'), effectively distinguishing from sibling tools like list_backends and refresh_backends which handle listing and refreshing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters and actions but does not provide explicit guidance on when to use this tool versus alternatives. It lacks 'when-to-use' or 'when-not-to-use' statements, leaving the agent to infer usage context from the parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change safety guard settings live and persist them to config.json.
| Name | Required | Description | Default |
|---|---|---|---|
| enforce | No | ||
| min_free_gb | No | ||
| exclusive_backend | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that changes are applied live and saved to config.json, which is useful behavioral context. However, it doesn't cover safety or reversibility, and annotations are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three defaulted parameters and no parameter explanations, the description is insufficient for correct tool usage. An output schema exists but is not included, which doesn't help the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (enforce, min_free_gb, exclusive_backend). The agent has no clue what these values mean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes safety guard settings and persists them. It distinguishes from sibling tools like set_backend or set_system_prefix, which modify other configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or clear a fixed system prefix prepended to every ask_local_model call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like persistence, overwriting behavior, or effects on existing calls. The description is too minimal to inform an agent about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It succinctly conveys the core purpose and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter (with default), no required params, and low complexity, the description is largely complete. It lacks some behavioral details but is sufficient for a simple configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining the parameter is a prefix and can be cleared. However, it does not clarify how clearing works (e.g., empty string vs a special value), leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets or clears a system prefix for ask_local_model calls, with a specific verb (Set/clear) and resource (system prefix). It distinguishes from sibling tools like set_backend or set_guard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for configuring the prefix before calling ask_local_model, but provides no explicit guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0ask_local_modellist_backendslist_local_modelslist_modelslocal_statusrefresh_backendsset_backendset_guardset_system_prefixMost tools target distinct aspects (querying, listing, configuration, status). The alias list_models for list_local_models is redundant but clearly documented, causing minor potential confusion.
Tools consistently follow verb_noun pattern with underscores (e.g., ask_local_model, list_backends, set_backend). The sole exception local_status is descriptive and fits the pattern.
9 tools cover the core operations for managing local LLM backends, guards, and queries without being excessive or insufficient.
The tool set covers CRUD for backends, querying, and configuration. A minor gap is the lack of a dedicated tool for detailed backend info, but list_backends provides status.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Production-readiness for your AI coding agents.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
Coding agents from Claude Code, Cursor and Codex claim jobs and lock files on one shared board.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HenryLinyy/local-llm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
