codex-local-ollama-mcp
Provides a local text transformation tool that sends user-provided text to a local Ollama model for drafting translations, summaries, rewrites, extracts, and classifications.
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., "@codex-local-ollama-mcpSummarize this in two bullets: Ollama runs AI models locally."
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.
codex-local-ollama-mcp
codex-local-ollama-mcp adds one deliberately narrow MCP tool, local_text,
to Codex. It asks a local Ollama instance to draft a transformation of text
that you supplied. Codex remains the planner and must review the resulting
draft before replying.
This is a GitHub-only project release. The package is private and is not published to npm.
Capability boundary
The server exposes exactly one stdio MCP tool and accepts exactly one local
model: qwen3.5:9b at http://127.0.0.1:11434. It only supports
self-contained, read-only transformations of user-provided text:
translatesummarizerewriteextractclassify
It does not execute commands, access files, write files, make Git changes, browse the web, use non-loopback network endpoints, receive tool definitions, or make decisions. Do not use it for current facts, code or operational work, or financial, medical, legal, security-sensitive, or other high-stakes work. Use Codex's normal tools for exact calculations and deterministic work.
The output is labeled Local draft with its model and mode. Treat it as a
draft, not verified information.
For these simple draft transformations, the server deliberately sends the
fixed Ollama request option think: false to disable qwen3.5 thinking and
reduce latency. This is server-side only: callers cannot configure it, and it
does not broaden the capability or safety boundaries. It is not a latency
guarantee.
Related MCP server: mcp-ollama
Requirements
Node.js 22 or newer
Ollama available on
PATHThe exact local model
qwen3.5:9bThe Codex CLI on
PATH; it registers the server used by Codex desktop or the CLICodex desktop if you want to use the desktop interface
Keep Ollama bound to its local loopback default. Do not expose Ollama on your LAN or the public internet for this integration.
Install
Clone this repository, then fetch the required model:
git clone https://github.com/kisara174/codex-local-ollama-mcp.git
cd codex-local-ollama-mcp
ollama pull qwen3.5:9b
ollama list
node --version
codex --version
./install.shinstall.sh checks Node, Ollama, the exact model, and the local codex
command. It then runs npm ci, builds the server, and registers it as
local-ollama with the local Codex CLI. It refuses to overwrite an existing
registration of that name.
For desktop use, fully restart the Codex desktop app after installation. Then
verify that local-ollama is connected in Settings → MCP Servers or type
/mcp in Codex. CLI users can also inspect the registration with:
codex mcp get local-ollamaUsing local_text
Ask Codex for a bounded transformation of text you include in your request. It may call the tool with this schema:
mode: translate | summarize | rewrite | extract | classify
input: required text, up to 12,000 characters
instruction: optional short formatting preference, up to 500 charactersThe instruction is intentionally restrictive: use a simple output or formatting preference. These examples are accepted by the current validator:
mode: translate
input: Good morning.
instruction: Translate to Chinese and preserve formatting.
mode: summarize
input: <text you provide>
instruction: Use two bullet points.
mode: rewrite
input: <text you provide>
instruction: Use a professional tone.
mode: extract
input: <text you provide>
instruction: Return a JSON list.
mode: classify
input: Category choices: billing, technical, account. Text: I cannot sign in.
instruction: Return one line only.Put category choices and extraction criteria in the supplied input when the instruction cannot express them as a formatting preference. The service rejects blank or oversized input, unsupported modes, oversized instructions, and instructions that are not accepted as short formatting/output preferences.
Errors and troubleshooting
Tool errors start with one of these codes:
INVALID_REQUEST: Use a supported mode, non-blank input within the limit, and a short formatting preference.OLLAMA_UNAVAILABLE: Start Ollama locally and confirm it remains reachable at its loopback default (127.0.0.1:11434). Do not solve this by exposing it to a LAN.MODEL_UNAVAILABLE: Runollama pull qwen3.5:9b, then confirm the exact name appears inollama list.OLLAMA_TIMEOUT: The local request has a 60-second bounded timeout. Retry a smaller transformation after checking that the local machine is not overloaded; the bound does not promise that every request will finish within 60 seconds.OLLAMA_BAD_RESPONSE: Restart the local Ollama service and retry. If it persists, inspect the local service logs without sharing sensitive data.
If installation reports an existing local-ollama registration, remove it
only if it is the registration you intend to replace:
./uninstall.sh
./install.shPrivacy and limits
The server sends only the text passed to local_text to the local Ollama
HTTP endpoint on loopback. It does not send that request to a remote endpoint.
The cloud Codex agent still sees the request and local draft in order to route,
inspect, and answer, so this tool is not an end-to-end privacy boundary.
Using a local drafting step does not guarantee a reduction in cloud Codex or ChatGPT quota usage. The cloud agent still decides whether to call the tool and reviews the result.
Uninstall
From this checkout, run:
./uninstall.shIt first checks that the local-ollama MCP registration runs exactly
node <this-checkout>/dist/index.js, then removes that registration and this
checkout's generated dist and node_modules directories. A missing,
mismatched, or unreadable registration leaves the registration and generated
files untouched. It does not remove Ollama, the model, or unrelated Codex settings.
Roadmap
After the v0.1.0 release has been observed in real use, the planned next phase is a separate evaluation corpus and runner for fixed local-text tasks. Its results will be reviewed before considering any broader local-model authority.
Available Tools
1 toollocal_textB
Create a labeled local draft from self-contained user-provided text only; never use for facts, high-stakes or operational work.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| input | Yes | ||
| instruction | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add useful context: the result is a draft, it is local, and it should not be used for authoritative or operational purposes. However, it does not mention side effects, persistence, output format, or failure behavior, leaving meaningful transparency gaps.
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 with no filler and places the core action first, followed by an important exclusion. It earns its length, though the phrase 'labeled local draft' is somewhat opaque and could have been clarified without much additional cost.
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?
The tool has 3 parameters, no per-parameter schema descriptions, no output schema, and no annotations. The description only sketches scope and exclusions; it leaves the semantics of the five modes, the optional instruction, and the expected return value undefined. This is not enough for an agent to invoke the tool confidently beyond the simplest case.
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, but it does not explain `mode`, `input`, or `instruction`. 'User-provided text' loosely maps to `input`, yet it adds no meaning about the mode enum or how `instruction` modifies 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 a specific action ('Create a labeled local draft') and resource ('self-contained user-provided text'), which makes the tool's core function identifiable. It does not enumerate the processing modes or clarify what 'labeled' means, but it is still substantially clearer than a tautology or vague purpose.
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 an explicit negative usage boundary: 'never use for facts, high-stakes or operational work.' It also implies appropriate use through 'local draft' and 'self-contained user-provided text only.' There are no sibling tools to compare with, so the lack of alternative names is not a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
local_text
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusing it with others. The tool's purpose is clearly limited to creating a labeled local draft from user text.
With a single tool, there are no naming inconsistencies to flag. However, the name 'local_text' does not follow a clear verb_noun pattern, making it impossible to infer a broader convention.
A single tool is far too few for a server with a broad name like 'codex-local-ollama-mcp'. The tool itself appears limited and trivial relative to the implied scope, creating an extreme mismatch.
The server offers only one narrow operation, with no apparent CRUD lifecycle, retrieval, or management capabilities. The domain hinted by the server name is severely underrepresented, leaving agents without essential functionality.
Maintenance
Related MCP Connectors
- WauldoOAuthcom.wauldo
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Text generation over MCP: prose, emails, blog outlines, SQL, humanizing, text diffs, fake data.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceExposes local Ollama instances as tools for Claude Code, allowing users to offload code generation, text drafting, and embedding tasks to local GPUs. It supports multi-turn conversations and model management through the Model Context Protocol.MIT
- AlicenseNot gradedqualityBmaintenanceMCP server wrapping local Ollama models for offload from API-priced orchestrators. Nine stdio tools - generation, summarisation, analysis, drafting, code tasks (docstring/test/explain/review/types/refactor-suggest), diff-driven tasks (commit-message/pr-description/changelog/summary/impact), mechanical transforms, and model management (list/pull). Apache-2.0.16 npmApache 2.0
- AlicenseAqualityBmaintenanceEnables AI agents to offload mechanical, high-token work to local Ollama models through MCP, with role-based model discovery, batch processing, and file-aware inputs.4MIT
- AlicenseBqualityBmaintenanceEnables Google Antigravity CLI to offload token-heavy workloads to local Ollama models through MCP tools for code drafting, summarization, chunked map-reduce, and JSON extraction, reducing cloud token usage.7AGPL 3.0