Skip to main content
Glama

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:

  • translate

  • summarize

  • rewrite

  • extract

  • classify

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 PATH

  • The exact local model qwen3.5:9b

  • The Codex CLI on PATH; it registers the server used by Codex desktop or the CLI

  • Codex 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.sh

install.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-ollama

Using 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 characters

The 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: Run ollama pull qwen3.5:9b, then confirm the exact name appears in ollama 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.sh

Privacy 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.sh

It 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 tool
local_textB

Create a labeled local draft from self-contained user-provided text only; never use for facts, high-stakes or operational work.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYes
inputYes
instructionNo

TDQS

B3.1/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.1.0
    • First observedlocal_text

TDQS

B3/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count1/5

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.

Completeness1/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Exposes 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
  • A
    license
    Not graded
    quality
    B
    maintenance
    MCP 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 npm
    Apache 2.0