local-llm-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| local_askA | Send a prompt to a local model via Ollama and get the answer back immediately. Runs on this machine, so nothing leaves it and there is no API cost. Use it for work where checking the answer is cheaper than producing it: summarising long output, drafting boilerplate or commit messages, extracting fields from text. It is a small model on CPU (~16 tok/s for a 7B), so keep outputs short — |
| local_classifyA | Put a piece of text into one of the labels you supply, using a local model. The reply is validated against your label set rather than trusted: if the model answers with something outside the list, or hedges between labels, this returns matched=false with the raw reply instead of guessing. By default the model may also answer that no label fits, which comes back as declined=true. That escape hatch helps but does not hold: a small model will still pick a confident in-set label for text that belongs to none of them, so a returned label is triage, not a verdict. Set allowNone=false only when a forced choice is genuinely wanted. Good for triage — log lines, error vs warning, which files look relevant, is this diff risky. Cheap and private; use it where a wrong answer is cheap for you to detect. |
| local_modelsA | List the models Ollama has on disk, with sizes, plus which one this server uses by default. Call it when a request names a model you are not sure exists. |
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 3 tools
Each tool has a clearly distinct purpose: listing models, asking a model a prompt, and classifying text into labels. There is no overlap between querying for answers and categorizing input, and the model-listing tool is unambiguously separate from both.
All three tools follow a consistent local_ prefix with clear verb_verb-noun style (models, ask, classify). The pattern is uniform and predictable, making selection straightforward.
At three tools, this is on the low end but each earns its place for a focused local-LLM utility server. The count is appropriate for the narrow scope of running local model inference, though it borders on thin.
The server covers the core lifecycle for local model interaction: discovery (local_models), free-form prompting (local_ask), and structured classification (local_classify). A minor gap is the lack of a tool to pull or manage models, but for the stated inference-focused purpose the surface is largely complete.