Provides a side-channel to a local Ollama instance, enabling tools to list available local models, send prompts to a local LLM, and redact sensitive output before returning answers over MCP.
Click on "Deploy 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 summarize this email draft using the local 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.
Small MCP side-channel so an orchestrator (e.g. Grok Bot) can ask a local LLM (Ollama) without replacing its own cloud model.
Typical layout:
[Grok Bot / Cursor] --MCP--> [this server]
|
Tailscale / LAN
|
[your PC: Ollama :11434]Is: ask_local / list_local_models / redact_text for drafts, summaries, and output-only DLP on text returned over MCP.
Is not: a full replacement for Grok Bot’s brain, nor a guarantee that every secret format is caught by heuristics.
Related MCP server: query-sanitizer-mcp
Prompts to the local model may include secrets / PII. That is intentional: the prompt stays on your machine (Ollama) and is not the leak path this server hardens.
Answers returned via MCP to Grok Bot / cloud must be filtered. Redaction applies to the model’s response before it leaves this server — not to the inbound local prompt.
Mechanism | Behavior |
No-echo system hint | Prefixed into |
| Regex masks IBAN, card-like digit runs, rodné číslo, email, phone, API-key-ish tokens, Bearer, AKIA… on returned text |
| Same redaction without calling the model |
| Default: redact |
Limits: heuristics miss novel formats. Treat redaction as defense-in-depth on the outbound MCP answer, not as a reason to scrub the local prompt. Hard secrets that must never leave the box still belong in env / secret forms on the MCP host when practical — but putting sensitive context in the local prompt is allowed.
Node.js 20+
Ollama on your machine with at least one model pulled
Optional: Tailscale so the host running this MCP can reach Ollama at a stable Tailscale IP
cp .env.example .env
# set OLLAMA_BASE_URL=http://100.x.y.z:11434 # Tailscale IP of the PC with Ollama
# set OLLAMA_MODEL=llama3.2
# set REDACT_OUTPUT=true
npm install
npm startTool | Purpose |
| List models known to Ollama |
| Prompt local model (secrets/PII in the prompt OK); redacts the answer before MCP return by default |
| Redact text only (no LLM call) — for outbound/MCP-bound text |
Run this MCP somewhere reachable (same Tailscale network as Ollama, or on the PC itself).
Add it as a custom MCP (stdio or HTTP URL, depending on how you run it).
Keep OLLAMA_BASE_URL / model name in env on the MCP host. Sensitive context may go in the local ask_local prompt; rely on output redaction for what comes back to the cloud orchestrator.
{
"mcpServers": {
"local-llm": {
"command": "node",
"args": ["/path/to/local-llm-mcp/src/index.js"],
"env": {
"OLLAMA_BASE_URL": "http://127.0.0.1:11434",
"OLLAMA_MODEL": "llama3.2",
"REDACT_OUTPUT": "true"
}
}
}
}Local prompts may contain secrets/PII; they stay on the Ollama host. The critical boundary is the MCP return path to Grok Bot / cloud.
Prefer Tailscale ACLs so only your Grok Bot host / laptop can reach :11434.
Do not expose Ollama to the public internet.
Output redaction is defense-in-depth, not a vault — leave REDACT_OUTPUT=true unless you intentionally need raw answers.
Draft scaffold for experimentation. APIs and packaging may change.
MIT
Ask the local Ollama model. Secrets/PII in the prompt are allowed (stay on Ollama). By default appends a no-echo system hint and redacts the answer before returning it over MCP (output-only DLP).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Override default OLLAMA_MODEL | |
| prompt | Yes | User prompt / question (may include secrets/PII; processed only on local Ollama) | |
| redact | No | Redact answer before MCP return (default: env REDACT_OUTPUT, usually true). Does not scrub the inbound prompt. | |
| system | No | Optional system instruction (merged with no-echo policy) | |
| allow_echo | No | If true, skip the built-in no-echo system add-on (weakens output DLP; not recommended) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden but does so well: it discloses the no-echo system hint, that the *answer* (not the prompt) is redacted before returning over MCP (output-only DLP), and by implication that the inbound prompt is not scrubbed. It omits error behavior, timeouts, or model context limits, preventing a 5.
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?
Three tight sentences with the core action and the key security trait front-loaded, and no redundant restatement of the name. Dense and mostly waste-free, though the parenthetical and asterisk emphasis are slightly informal.
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 5-parameter tool with no annotations and no output schema, this covers the operationally critical facts: locality, default no-echo behavior, and output-only redaction. It stops short of describing the return shape or failure modes, but the essential invocation context is present.
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 100%, so all five parameters including the redact/allow_echo defaults are already documented in the schema. The description reinforces the DLP/default behavior but adds no syntax or format detail beyond what the schema provides, so baseline 3 is correct.
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?
States a specific verb and resource ("Ask the local Ollama model"), clearly positioning it as the query/inference tool distinct from sibling list_local_models (enumeration) and redact_text (scrubbing). It never names those siblings to differentiate explicitly, so it lands at 4 rather than 5.
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?
It implies usage context by noting secrets/PII are allowed because processing stays local, which is a meaningful hint about when this tool is appropriate. However, it gives no explicit when-not guidance and does not route the agent to redact_text for standalone redaction, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List models available on the configured Ollama instance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation with no side effects, which is useful, but the description does not explicitly state read-only behavior, authentication requirements, or return format details.
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 clear sentence that is front-loaded with the core action and resource. It contains no wasted words and is appropriately sized for a simple listing tool.
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 low complexity, zero parameters, and lack of annotations or output schema, the description is nearly complete. It could specify the return format or read-only nature more explicitly, but the essential information is present.
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 baseline score is 4 per the rubric. The description adds no parameter information, but none is needed since the input schema is empty.
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 a specific verb (List) and resource (models available on the configured Ollama instance). It is unambiguous and clearly distinct from sibling tools like redact_text and ask_local, which serve 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. It does not mention the sibling tools or any conditions that would select this tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redact likely sensitive patterns from outbound/MCP-bound text (IBAN, cards, emails, tokens, etc.). Heuristic output DLP only — not for scrubbing local prompts.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Rule ids to skip, e.g. email, phone_eu, card | |
| text | Yes | Text to redact |
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 discloses an important behavioral trait: the redaction is 'heuristic output DLP only', which sets expectations about reliability and false positives/negatives. However, it does not state whether redaction is reversible, what the output looks like (replacement tokens vs removal), or whether the operation is side-effect free.
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?
Two short, dense sentences with no waste. The primary purpose and critical limitation are both front-loaded and easy to parse.
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 no annotations and no output schema, the description should ideally cover what the redacted output looks like and any limits of the heuristic. It covers the use case well but leaves return-format and reliability details unstated. Adequate but with clear gaps.
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 100%, so both parameters are already documented in the schema, including examples for skip rule ids. The description adds no parameter-level detail beyond what the schema provides. Baseline 3 is appropriate.
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?
States a specific verb (redact) and resource (sensitive patterns) with an explicit scope: 'outbound/MCP-bound text'. The parenthetical examples clarify what counts as sensitive. It doesn't explicitly differentiate from siblings, but siblings (list_local_models, ask_local) are unrelated, so no differentiation is needed.
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?
Gives clear context of when to use it (outbound/MCP-bound text) and explicitly says when not to use it ('not for scrubbing local prompts'). No named alternatives, but the use-case boundary is well defined.
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.
v0.2.0ask_locallist_local_modelsredact_textScored across 3 tools
The three tools target distinct actions: listing models, redacting text, and asking the model. However, redact_text overlaps with ask_local's built-in output redaction, which could leave an agent unsure when to invoke redact_text directly versus relying on ask_local's automatic DLP.
All three names are verb-first and snake_case, which is predictable. list_local_models follows verb_adjective_noun while ask_local is verb_adjective and redact_text is verb_noun, a minor structural deviation but still readable and consistent in style.
Three tools is on the lean side but appropriate for a narrow local-LLM proxy whose purpose is model discovery, inference, and output DLP. Each tool earns its place, though the surface is minimal.
The core workflow (list models, ask, redact) is covered, but there are notable gaps: no model lifecycle operations (pull/delete), no conversation/session management, and no history handling. These are plausible for the scope but leave the surface thin for sustained use.
Deterministic trust gate for AI output: leaked-secret, prompt-injection & PII in one call.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Redact PII from text before it reaches a model. Nothing stored, no third-party AI.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
