Skip to main content
Glama
deenesjakoruzh
VrtxOmega

Ollama-Omega

by VrtxOmega
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

OLLAMA-OMEGA

MCP server — Ollama bridge for any IDE. Sovereign compute. No cloud dependency.

Status Version Stack License Tests

Ollama-Omega MCP server

Ecosystem Canon

Ollama-Omega is the compute interface layer of the VERITAS & Sovereign Ecosystem (Omega Universe). It surfaces every locally installed Ollama model — and any cloud-hosted model accessible through an Ollama daemon — as a structured MCP tool set inside any MCP-compatible IDE or agent runtime.

Within the Omega Universe, governance flows downward from omega-brain-mcp (the VERITAS gate and approval pipeline) to Ollama-Omega (the inference transport). Ollama-Omega is the final execution node: it issues the prompt, receives model output, and returns a validated, schema-typed response. No inference executes before the upstream gate approves the request.

Ollama-Omega does not perform memory, authentication, persistence, or policy enforcement. Those responsibilities belong to the operators above it in the stack. This node does one thing: connect IDE to Ollama, reliably and without information loss.

Related MCP server: Mcp-Omega-Brain

Overview

What it is:

  • A single-file MCP server (ollama_mcp_server.py) that bridges Ollama into any MCP-compatible client

  • Six validated tools covering health, model listing, chat, generation, model inspection, and model pull

  • Compatible with Claude Desktop, VS Code + Continue, Cursor, Antigravity IDE, and any other client that speaks MCP over stdio

What it is not:

  • A full AI platform, memory layer, or policy engine

  • A replacement for the Ollama daemon — it wraps the daemon's HTTP API over MCP stdio transport

  • A cloud service — all inference is local or routed through your own Ollama daemon

Features

Feature

Detail

6 MCP tools

Health check, list models, chat, generate, show model info, pull model

Stdio transport

JSON-RPC 2.0 over stdin/stdout — no network ports opened by this server

Typed output schemas

Every tool carries a full outputSchema for structured agent consumption

SSRF mitigation

follow_redirects=False on the singleton httpx client

Input validation

_validate_required() gate before any HTTP call; no uncaught KeyError

Safe JSON handling

_safe_json() wrapper — no crash on malformed Ollama responses

Error sanitization

_error() helper — no stack traces, no internals exposed to the client

Cloud model support

Any model accessible on your Ollama daemon is available — no config change required

Docker-ready

Dockerfile included for containerized deployment

Architecture

  IDE / MCP Client
  (Claude Desktop, VS Code + Continue, Cursor, Antigravity, ...)
         |
         |  stdio  JSON-RPC 2.0
         v
  +-----------------------------+
  |    ollama_mcp_server.py     |
  |  Validator  |   Dispatch    |
  |  Singleton httpx AsyncClient|
  +-----------------------------+
         |
         |  HTTP  (default: http://localhost:11434)
         v
  +-----------------------------+
  |       Ollama Daemon         |
  |  Local models  (GPU / CPU)  |
  |  Cloud proxy models         |
  +-----------------------------+
         |
         v
  Local model store
  (~/.ollama/models)

The server process lives for the lifetime of the IDE session. One httpx AsyncClient handles all upstream Ollama HTTP traffic. The MCP client never communicates with Ollama directly.

Quickstart

Prerequisites

  • Python 3.11 or later

  • Ollama daemon installed and running

Install Ollama

Platform

Method

Windows

Download the installer from ollama.com/download/windows and run it. Ollama starts automatically as a system tray service.

macOS

Download from ollama.com/download/mac, or via Homebrew: brew install ollama && ollama serve

Linux

curl -fsSL https://ollama.com/install.sh | sh — starts the daemon via systemd on supported distributions

Verify the daemon is reachable before proceeding:

curl http://localhost:11434
# Expected response: Ollama is running

Install Ollama-Omega

Option A — pip (simplest):

pip install mcp httpx

Then download the server file:

# macOS / Linux
curl -O https://raw.githubusercontent.com/VrtxOmega/Ollama-Omega/master/ollama_mcp_server.py

# Windows (PowerShell)
Invoke-WebRequest -Uri https://raw.githubusercontent.com/VrtxOmega/Ollama-Omega/master/ollama_mcp_server.py -OutFile ollama_mcp_server.py

Option B — clone the repository (recommended for local development):

git clone https://github.com/VrtxOmega/Ollama-Omega.git
cd Ollama-Omega
pip install mcp httpx

Option C — uv (virtual-env isolation, recommended for production):

git clone https://github.com/VrtxOmega/Ollama-Omega.git
cd Ollama-Omega
uv sync

Option D — Docker:

git clone https://github.com/VrtxOmega/Ollama-Omega.git
cd Ollama-Omega
docker build -t ollama-omega .
# Run with stdio transport for IDE integration:
docker run -i --rm -e OLLAMA_HOST=http://host.docker.internal:11434 ollama-omega

Pull a model

ollama pull llama3.2:3b

Configure your MCP client

Edit the configuration file for your IDE and add the ollama server block. Replace /path/to/Ollama-Omega with the actual path to your clone (or the directory containing ollama_mcp_server.py).

Claude Desktop

Config file locations:

Platform

Path

Windows

%APPDATA%\Claude\claude_desktop_config.json

macOS / Linux

~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "ollama": {
      "command": "python",
      "args": ["/path/to/Ollama-Omega/ollama_mcp_server.py"],
      "env": {
        "PYTHONUTF8": "1",
        "OLLAMA_HOST": "http://localhost:11434",
        "OLLAMA_TIMEOUT": "300"
      }
    }
  }
}

With uv (virtual-env isolation):

{
  "mcpServers": {
    "ollama": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/Ollama-Omega",
        "run",
        "python",
        "ollama_mcp_server.py"
      ],
      "env": {
        "PYTHONUTF8": "1",
        "OLLAMA_HOST": "http://localhost:11434",
        "OLLAMA_TIMEOUT": "300"
      }
    }
  }
}

VS Code + Continue / Cursor

Most MCP-compatible VS Code extensions follow the same JSON structure under their own config key. Substitute the command and args block from the Claude Desktop example above. Consult your extension's documentation for the exact config file path.

Antigravity IDE

Config file: ~/.gemini/antigravity/mcp_config.json

{
  "mcpServers": {
    "ollama": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/Ollama-Omega",
        "run",
        "python",
        "ollama_mcp_server.py"
      ],
      "env": {
        "PYTHONUTF8": "1",
        "OLLAMA_HOST": "http://localhost:11434"
      }
    }
  }
}

Restart your IDE after saving the configuration file. Verify connectivity by calling the ollama_health tool from your IDE.

Configuration

Variable

Default

Description

OLLAMA_HOST

http://localhost:11434

Base URL of the Ollama daemon. Override to point at a remote or containerized daemon.

OLLAMA_TIMEOUT

300

HTTP request timeout in seconds. Increase for large model pulls or slow cloud inference.

PYTHONUTF8

(unset)

Set to 1 on Windows to prevent Unicode encoding errors in stdio transport.

Cloud-hosted models exposed by your Ollama daemon (e.g., qwen3.5:397b-cloud via API proxy) are accessible through the same 6 tools with no configuration change. Authenticate first with ollama login.

Troubleshooting

Ollama daemon not running

# Start the daemon
ollama serve

# Verify
curl http://localhost:11434

If OLLAMA_HOST is set to a non-default value, confirm the URL and port match the daemon's bind address.

Port conflict — daemon fails to start

Ollama binds to port 11434 by default. If that port is occupied:

# macOS / Linux — find the occupying process
lsof -i :11434

# Windows (PowerShell)
netstat -ano | findstr :11434

Set OLLAMA_HOST to an alternate port once you have reconfigured the daemon.

Model not found / HTTP 404

The referenced model has not been pulled. Pull it first:

ollama pull <model-name>

# Cloud-hosted models require authentication:
ollama login
ollama pull qwen3.5:397b-cloud

Alternatively, call ollama_pull_model from your IDE once the server is connected.

Tools do not appear in the IDE

  1. Confirm the command path resolves to a working Python 3.11+ interpreter.

  2. Confirm mcp and httpx are installed in that interpreter's environment.

  3. Restart the IDE — MCP servers are discovered at startup, not while running.

  4. Check IDE logs for JSON-RPC handshake errors.

Windows: UnicodeEncodeError or garbled output

Set PYTHONUTF8=1 in the server's env block. This is already shown in the configuration examples above.

Docker: cannot reach localhost:11434

Docker containers run in an isolated network namespace. Replace localhost with host.docker.internal:

docker run -i --rm -e OLLAMA_HOST=http://host.docker.internal:11434 ollama-omega

On Linux hosts, --network=host may be required instead.

Request timed out after 300s

Cold inference on large models (70B+) or cloud-proxied models can exceed the default timeout. Increase it in your MCP client config:

"env": { "OLLAMA_TIMEOUT": "600" }

Security and Sovereignty

Ollama-Omega runs exclusively on localhost by default, communicating with the Ollama daemon over the loopback interface. No data leaves the machine unless your Ollama daemon is configured to proxy to a cloud endpoint.

Hardening applied to this server:

Control

Implementation

SSRF prevention

follow_redirects=False on the httpx singleton

Input sanitization

Required-argument validation before any outbound HTTP call

Error sanitization

Internal errors are never forwarded to the MCP client

Non-root Docker

Container process runs as a dedicated ollama user

Limitations and out-of-scope items:

  • Authentication between the MCP client and this server is not implemented. MCP stdio transport is inherently scoped to the local process boundary.

  • This server does not validate the content of prompts or model outputs. Content policy enforcement is the responsibility of the upstream operator (see omega-brain-mcp).

  • Network isolation, host-level security, and key management are outside the scope of this component.

Omega Universe

Ollama-Omega is one node in the VERITAS & Sovereign Ecosystem. Cross-references:

Repository

Role in the stack

omega-brain-mcp

VERITAS gate + cryptographic audit ledger + Cortex approval pipeline. The governance layer above Ollama-Omega.

veritas-vault

Long-term retention substrate. Stores artifacts, attestations, and approved outputs.

Aegis

Security enforcement layer. Threat surface scanning and sovereign boundary enforcement.

drift

Drift detection and configuration integrity monitoring across Omega operators.

SovereignMedia

Media processing and content pipeline within the Omega framework.

sovereign-arcade

Operator sandbox and demonstration environment for Omega Universe components.

🌐 VERITAS Omega Ecosystem

This project is part of the VERITAS Omega Universe — a sovereign AI infrastructure stack.

License

MIT — see LICENSE.

Available Tools

6 tools
ollama_chatA
Read-only

Send a multi-turn chat completion request to an Ollama model. Use this tool for conversational interactions where message history matters — for example, follow-up questions, multi-step reasoning, or dialogue with context. Do not use this for single-prompt completions without history; use ollama_generate instead to avoid the overhead of the messages array. Prerequisites: The 'model' must already be installed locally. Call ollama_list_models to verify availability; use ollama_pull_model to download if missing. Behavior: Read-only (no state changes on the server), not idempotent — each call generates a new response even with identical inputs. No authentication required. No rate limits. Network-dependent; response time varies from seconds to minutes based on model size and prompt length. Safe to retry on timeout. On model-not-found error, returns an error object without throwing.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesExact Ollama model identifier. Must match a 'name' value from ollama_list_models output (e.g., 'llama3.1:8b', 'qwen2.5:7b'). Cloud-hosted models use a '-cloud' suffix (e.g., 'deepseek-v3:671b-cloud'). If unsure which models are available, call ollama_list_models first.
systemNoSystem prompt prepended before the messages array. Use this as a shortcut to set model behavior without adding a system-role message to the 'messages' array. If both this field and a system-role message are provided, this field takes precedence.
messagesYesOrdered conversation history sent to the model. Place system instructions first (role 'system'), then alternate user/assistant turns. The model sees all messages in order. If you only need a system prompt with one user message, consider using the 'system' parameter instead of a system-role message.
max_tokensNoMaximum number of tokens to generate in the response. Maps to Ollama's internal 'num_predict' parameter. Use -1 for unlimited generation (model stops at its natural end token). Default is model-dependent, typically ~2048.
temperatureNoSampling temperature controlling output randomness. 0.0 = deterministic (always pick the most likely token), 2.0 = maximum creativity. Default is model-dependent, typically ~0.7. Use low values (0.0–0.3) for factual tasks, higher (0.7–1.0) for creative tasks.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoError message if the request failed (e.g., model not found). Only present on failure.
modelYesThe model that generated the response.
messageNoThe assistant's response message.
eval_countNoNumber of tokens generated in the response.
total_durationNoTotal time in nanoseconds including load and inference.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, non-idempotent, non-destructive), the description adds: 'Read-only (no state changes on the server)', 'not idempotent', 'No authentication required', 'No rate limits', 'Network-dependent; response time varies', 'Safe to retry on timeout', and error behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: purpose, usage, prerequisites, behavior notes. Each sentence serves a clear purpose, no redundant or filler content. Front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 params, 2 required), high schema coverage, and existence of output schema, the description covers all essential aspects: purpose, usage context, prerequisites, behavioral quirks, and parameter hints. Return values are not needed due to output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds contextual meaning: explains 'system' field as a shortcut with precedence, describes 'messages' array ordering, and gives temperature guidance (low for factual, high for creative). While schema already defines parameters, the description enriches operational understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Send'), resource ('multi-turn chat completion request to an Ollama model'), and specifies the use case (conversational interactions with history). It explicitly differentiates from sibling tool 'ollama_generate' by advising against single-prompt usage, making the purpose distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when to use (multi-turn, follow-up, multi-step reasoning) and when not to use (single-prompt, use ollama_generate). Includes prerequisites: model must be installed, with references to ollama_list_models and ollama_pull_model. Also describes error behavior (returns error without throwing on model-not-found), guiding safe handling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ollama_generateA
Read-only

Generate a single-turn text completion from an Ollama model without conversation history. Use this tool for one-shot tasks: code generation, text transformation, summarization, translation, or any prompt that does not require prior context. Do not use this for multi-turn conversations where message history matters; use ollama_chat instead. Prerequisites: The 'model' must already be installed. Call ollama_list_models to verify; use ollama_pull_model to download if missing. Behavior: Read-only, not idempotent — each call produces a different generation even with identical inputs. No authentication required. No rate limits. Network-dependent; response time varies with model size and prompt length. Safe to retry on timeout. On model-not-found error, returns an error object without throwing.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesExact Ollama model identifier. Must match a 'name' from ollama_list_models (e.g., 'llama3.1:8b', 'codellama:13b'). If unsure, call ollama_list_models first.
promptYesThe input text prompt to generate a completion from. Can be any length — the model's context window is the only limit.
systemNoSystem prompt to set model behavior, persona, or output format constraints for this generation.
max_tokensNoMaximum tokens to generate. Maps to Ollama 'num_predict'. Use -1 for unlimited (model stops at its natural end token).
temperatureNoSampling temperature. 0.0 = deterministic, 2.0 = maximum randomness. Default is model-dependent. Use low values for factual/code tasks.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoError message if the request failed. Only present on failure.
modelYesThe model that generated the response.
responseNoThe generated text completion.
eval_countNoNumber of tokens generated.
total_durationNoTotal time in nanoseconds including load and inference.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description states read-only, not idempotent (each call produces different output), no authentication, no rate limits, network-dependent, safe to retry on timeout, and error handling. This adds significant context beyond annotations (readOnlyHint: true, etc.) and does not contradict them.

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?

Description is a single paragraph but well-structured: starts with purpose, then use cases, prerequisites, behavioral details. Every sentence adds unique value. Slightly longer than minimal but no redundancy, and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 params), presence of output schema, and sibling tools, the description covers purpose, usage guidelines, prerequisites, behavior, and error handling. With output schema existing, it doesn't need to explain return values. Complete for selecting and invoking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds valuable context: suggests calling ollama_list_models for model parameter, explains prompt length is context-window limited, maps max_tokens to Ollama 'num_predict', and gives usage tips for temperature. Goes beyond schema but is not essential since schema already covers basics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Generate a single-turn text completion from an Ollama model without conversation history.' Uses specific verb and resource, lists use cases (code generation, etc.), and explicitly distinguishes from sibling ollama_chat (multi-turn).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (one-shot tasks) and when not to (multi-turn conversations), directing to ollama_chat. Also provides prerequisites: model must be installed, with instructions to verify via ollama_list_models and pull via ollama_pull_model.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ollama_healthA
Read-onlyIdempotent

Check Ollama daemon connectivity and list currently running models. Use this tool as the first call to verify the Ollama service is reachable before calling any other tool in this server. Do not use this to list all installed models — use ollama_list_models instead. Behavior: Read-only, idempotent, safe to retry. No authentication required. No rate limits. Makes a single HTTP GET to the Ollama daemon. On connection failure returns an error object without throwing.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
hostYesThe Ollama host URL that was checked (e.g., 'http://localhost:11434').
errorNoError message if connection failed. Only present on failure.
connectedNoTrue if the Ollama daemon responded to the health check.
running_modelsNoModels currently loaded in GPU/CPU memory. Empty array if none are loaded.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds behavioral traits beyond annotations: 'Read-only, idempotent, safe to retry. No authentication required. No rate limits. Makes a single HTTP GET... On connection failure returns an error object without throwing.' This provides rich context for safe usage.

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?

Four sentences with clear front-loading. Could be slightly trimmed but all information earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, rich annotations, and an output schema, the description fully covers usage context, behavior, and error handling. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline 4 applies. Description does not need to add param details as there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it checks Ollama daemon connectivity and lists running models. Explicitly distinguishes from ollama_list_models by specifying it does not list all installed models.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends using this as the first call to verify service reachability before other tools. Also states to not use for listing all installed models, with alternative provided (ollama_list_models).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ollama_list_modelsA
Read-onlyIdempotent

List all Ollama models installed on the local machine with their memory load status. Use this tool to discover available model names before calling ollama_chat, ollama_generate, or ollama_show_model. Do not use this to check if the Ollama daemon is running — use ollama_health instead. Behavior: Read-only, idempotent, safe to retry. No authentication required. No rate limits. Returns an empty models array if no models are installed.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
modelsYesAll locally installed models. Empty array if none are installed.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds context beyond annotations: 'No authentication required. No rate limits. Returns an empty models array if no models are installed.' This fully discloses behavior and aligns with annotations (readOnlyHint, idempotentHint).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences each serving a distinct purpose: function, usage guidance, and behavioral note. No redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with good annotations and an output schema, the description covers all necessary aspects: purpose, when to use, behavior, and return states. Complete for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has 0 parameters, baseline is 4. Description clarifies no input needed, and schema is empty. No further parameter detail required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'List' and resource 'Ollama models installed on the local machine with their memory load status.' It distinguishes from sibling tools by specifying its role in discovering model names before using other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises when to use (before ollama_chat, ollama_generate, etc.) and when not to use (for checking daemon status, recommends ollama_health instead). Also notes idempotency and safe retry.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ollama_pull_modelA
Idempotent

Download a model from the Ollama library to the local machine. Use this tool when a model is needed but not yet installed locally. Do not use this if the model is already available — call ollama_list_models first to check. Do not use this to run inference — use ollama_chat or ollama_generate after pulling. Behavior: WRITE operation — downloads large files (1–100+ GB) and stores them on disk. Idempotent — re-pulling an already-installed model is safe and verifies integrity. No authentication required. No rate limits. Execution time ranges from seconds to hours depending on model size and network bandwidth. Not destructive (does not delete existing data). On network failure, returns an error object without throwing.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesModel identifier to download from the Ollama library. Use the format 'name:tag' (e.g., 'llama3.1:8b', 'mistral:latest', 'codellama:13b-instruct'). The tag selects a specific size or quantization variant. Omitting the tag defaults to ':latest'.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoError message if the download failed (e.g., network error, model not found in library). Only present on failure.
statusNoDownload result status (e.g., 'success'). Indicates the model is now available for inference.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate write, idempotent, non-destructive. Description adds file size range, idempotency verification, authentication, rate limits, execution time, error behavior. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is eight sentences, each adding value, with front-loaded purpose and clear structure. No redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers usage, behavior, constraints, and error handling. Output schema exists, so return value details are not required. Comprehensive for a download tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed parameter description. The tool description does not add meaning beyond the schema, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies downloading a model from the Ollama library to the local machine, using a clear verb and resource. It distinguishes from sibling tools by stating when not to use it (e.g., for inference or when model is already present).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (model needed but not installed) and when not to use (if already installed, use ollama_list_models first; for inference, use ollama_chat or ollama_generate). Provides clear alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ollama_show_modelA
Read-onlyIdempotent

Retrieve detailed metadata about a specific installed Ollama model. Use this tool to inspect a model's architecture, license, quantization level, prompt template, and default parameters before using it with ollama_chat or ollama_generate. Do not use this to list all models — use ollama_list_models instead. Do not use this to download new models — use ollama_pull_model instead. Prerequisites: The model must already be installed locally (verify with ollama_list_models). Behavior: Read-only, idempotent, safe to retry. No authentication required. No rate limits. Returns the same metadata for the same model every time. On model-not-found error, returns an error object without throwing.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesExact Ollama model identifier to inspect (e.g., 'llama3.1:8b', 'mistral:latest'). Must match a 'name' from ollama_list_models output. If unsure which models are installed, call ollama_list_models first.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoError message if the model was not found. Only present on failure.
detailsNoModel architecture details.
templateNoGo template string used for prompt formatting.
modelfileNoThe full Modelfile content defining this model's configuration.
parametersNoRuntime parameter defaults (e.g., temperature, context length) as a formatted string.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive. Description adds read-only, idempotent, safe to retry, no auth, no rate limits, consistent returns, and error handling behavior. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, well-structured, front-loaded with purpose, bullet-like guidelines, every sentence adds value. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, prerequisites, behavior, error handling. With good annotations and output schema, nothing missing. Complete for a simple inspection tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by explaining the parameter is an exact identifier from ollama_list_models, provides examples, and suggests calling that tool first if unsure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it retrieves detailed metadata about a specific installed Ollama model, including architecture, license, etc. It clearly distinguishes from sibling tools like ollama_list_models and ollama_pull_model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (before ollama_chat/generate), when not to use (listing or downloading models), prerequisites (model installed), and alternative tool names are provided.

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. Dates show when Glama detected each change.

  1. 6 tool updates
    • Addedollama_chat
    • Addedollama_generate
    • Addedollama_health
    • Addedollama_list_models
    • Addedollama_pull_model
    • Addedollama_show_model
  2. 6 tool updatesv1.0.4
    • Removedollama_chat
    • Removedollama_generate
    • Removedollama_health
    • Removedollama_list_models
    • Removedollama_pull_model
    • Removedollama_show_model
  3. 6 tool updatesv1.0.3
    • Changedollama_chat16 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / max_tokens / description
        Previous value: -"Max tokens to generate (maps to num_predict)"New value: +"Maximum number of tokens to generate in the response. Maps to Ollama's internal 'num_predict' parameter. Use -1 for unlimited generation (model stops at its natural end token). Default is model-dependent, typically ~2048."
      • addedInput schema / properties / max_tokens / minimum
        Added value: +-1
      • changedInput schema / properties / messages / description
        Previous value: -"List of message objects with 'role' and 'content'"New value: +"Ordered conversation history sent to the model. Place system instructions first (role 'system'), then alternate user/assistant turns. The model sees all messages in order. If you only need a system prompt with one user message, consider using the 'system' parameter instead of a system-role message."
      • addedInput schema / properties / messages / items / additionalProperties
        Added value: +false
      • addedInput schema / properties / messages / items / properties / content / description
        Added value: +"The text content of this message."
      • addedInput schema / properties / messages / items / properties / role / description
        Added value: +"Message author: 'system' for instructions, 'user' for queries, 'assistant' for prior model responses."
      • addedInput schema / properties / messages / items / properties / role / enum
        Added value: +[
+  "user",
+  "assistant",
+  "system"
+]
      • addedInput schema / properties / messages / minItems
        Added value: +1
      • changedInput schema / properties / model / description
        Previous value: -"Model name (e.g., 'llama3')"New value: +"Exact Ollama model identifier. Must match a 'name' value from ollama_list_models output (e.g., 'llama3.1:8b', 'qwen2.5:7b'). Cloud-hosted models use a '-cloud' suffix (e.g., 'deepseek-v3:671b-cloud'). If unsure which models are available, call ollama_list_models first."
      • addedInput schema / properties / model / minLength
        Added value: +1
      • changedInput schema / properties / system / description
        Previous value: -"System prompt"New value: +"System prompt prepended before the messages array. Use this as a shortcut to set model behavior without adding a system-role message to the 'messages' array. If both this field and a system-role message are provided, this field takes precedence."
      • changedInput schema / properties / temperature / description
        Previous value: -"Sampling temperature"New value: +"Sampling temperature controlling output randomness. 0.0 = deterministic (always pick the most likely token), 2.0 = maximum creativity. Default is model-dependent, typically ~0.7. Use low values (0.0–0.3) for factual tasks, higher (0.7–1.0) for creative tasks."
      • addedInput schema / properties / temperature / maximum
        Added value: +2
      • addedInput schema / properties / temperature / minimum
        Added value: +0
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "error": {
+      "description": "Error message if the request failed (e.g., model not found). Only present on failure.",
+      "type": "string"
+    },
+    "eval_count": {
+      "description": "Number of tokens generated in the response.",
+      "type": "integer"
+    },
+    "message": {
+      "description": "The assistant's response message.",
+      "properties": {
+        "content": {
+          "description": "The generated text content of the response.",
+          "type": "string"
+        },
+        "role": {
+          "description": "Always 'assistant' for chat responses.",
+          "enum": [
+            "assistant"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "role",
+        "content"
+      ],
+      "type": "object"
+    },
+    "model": {
+      "description": "The model that generated the response.",
+      "type": "string"
+    },
+    "total_duration": {
+      "description": "Total time in nanoseconds including load and inference.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "model"
+  ],
+  "type": "object"
+}
    • Changedollama_generate12 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / max_tokens / description
        Previous value: -"Max tokens to generate"New value: +"Maximum tokens to generate. Maps to Ollama 'num_predict'. Use -1 for unlimited (model stops at its natural end token)."
      • addedInput schema / properties / max_tokens / minimum
        Added value: +-1
      • changedInput schema / properties / model / description
        Previous value: -"Model name"New value: +"Exact Ollama model identifier. Must match a 'name' from ollama_list_models (e.g., 'llama3.1:8b', 'codellama:13b'). If unsure, call ollama_list_models first."
      • addedInput schema / properties / model / minLength
        Added value: +1
      • changedInput schema / properties / prompt / description
        Previous value: -"The prompt to generate from"New value: +"The input text prompt to generate a completion from. Can be any length — the model's context window is the only limit."
      • addedInput schema / properties / prompt / minLength
        Added value: +1
      • changedInput schema / properties / system / description
        Previous value: -"System prompt"New value: +"System prompt to set model behavior, persona, or output format constraints for this generation."
      • changedInput schema / properties / temperature / description
        Previous value: -"Sampling temperature"New value: +"Sampling temperature. 0.0 = deterministic, 2.0 = maximum randomness. Default is model-dependent. Use low values for factual/code tasks."
      • addedInput schema / properties / temperature / maximum
        Added value: +2
      • addedInput schema / properties / temperature / minimum
        Added value: +0
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "error": {
+      "description": "Error message if the request failed. Only present on failure.",
+      "type": "string"
+    },
+    "eval_count": {
+      "description": "Number of tokens generated.",
+      "type": "integer"
+    },
+    "model": {
+      "description": "The model that generated the response.",
+      "type": "string"
+    },
+    "response": {
+      "description": "The generated text completion.",
+      "type": "string"
+    },
+    "total_duration": {
+      "description": "Total time in nanoseconds including load and inference.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "model"
+  ],
+  "type": "object"
+}
    • Changedollama_health2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "connected": {
+      "description": "True if the Ollama daemon responded to the health check.",
+      "type": "boolean"
+    },
+    "error": {
+      "description": "Error message if connection failed. Only present on failure.",
+      "type": "string"
+    },
+    "host": {
+      "description": "The Ollama host URL that was checked (e.g., 'http://localhost:11434').",
+      "type": "string"
+    },
+    "running_models": {
+      "description": "Models currently loaded in GPU/CPU memory. Empty array if none are loaded.",
+      "items": {
+        "properties": {
+          "expires_at": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "size": {
+            "type": "integer"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "host"
+  ],
+  "type": "object"
+}
    • Changedollama_list_models2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "models": {
+      "description": "All locally installed models. Empty array if none are installed.",
+      "items": {
+        "properties": {
+          "digest": {
+            "description": "SHA256 digest of the model blob.",
+            "type": "string"
+          },
+          "loaded": {
+            "description": "True if the model is currently loaded in GPU/CPU memory.",
+            "type": "boolean"
+          },
+          "modified_at": {
+            "description": "ISO 8601 timestamp of last modification.",
+            "type": "string"
+          },
+          "name": {
+            "description": "Model identifier — use this exact value as the 'model' parameter in other tools.",
+            "type": "string"
+          },
+          "size": {
+            "description": "Model size in bytes on disk.",
+            "type": "integer"
+          }
+        },
+        "required": [
+          "name",
+          "size",
+          "modified_at"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "models"
+  ],
+  "type": "object"
+}
    • Changedollama_pull_model4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / model / description
        Previous value: -"Model name to pull"New value: +"Model identifier to download from the Ollama library. Use the format 'name:tag' (e.g., 'llama3.1:8b', 'mistral:latest', 'codellama:13b-instruct'). The tag selects a specific size or quantization variant. Omitting the tag defaults to ':latest'."
      • addedInput schema / properties / model / minLength
        Added value: +1
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "error": {
+      "description": "Error message if the download failed (e.g., network error, model not found in library). Only present on failure.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Download result status (e.g., 'success'). Indicates the model is now available for inference.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
    • Changedollama_show_model4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / model / description
        Previous value: -"Model name"New value: +"Exact Ollama model identifier to inspect (e.g., 'llama3.1:8b', 'mistral:latest'). Must match a 'name' from ollama_list_models output. If unsure which models are installed, call ollama_list_models first."
      • addedInput schema / properties / model / minLength
        Added value: +1
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "details": {
+      "description": "Model architecture details.",
+      "properties": {
+        "families": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "family": {
+          "description": "Model family (e.g., 'llama', 'qwen2').",
+          "type": "string"
+        },
+        "format": {
+          "description": "Model format (e.g., 'gguf').",
+          "type": "string"
+        },
+        "parameter_size": {
+          "description": "Human-readable parameter count (e.g., '8B', '70B').",
+          "type": "string"
+        },
+        "quantization_level": {
+          "description": "Quantization format (e.g., 'Q4_K_M', 'F16').",
+          "type": "string"
+        }
+      },
+      "required": [
+        "family",
+        "parameter_size",
+        "quantization_level"
+      ],
+      "type": "object"
+    },
+    "error": {
+      "description": "Error message if the model was not found. Only present on failure.",
+      "type": "string"
+    },
+    "modelfile": {
+      "description": "The full Modelfile content defining this model's configuration.",
+      "type": "string"
+    },
+    "parameters": {
+      "description": "Runtime parameter defaults (e.g., temperature, context length) as a formatted string.",
+      "type": "string"
+    },
+    "template": {
+      "description": "Go template string used for prompt formatting.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  4. 6 tool updatesv1.0.2
    • First observedollama_chat
    • First observedollama_generate
    • First observedollama_health
    • First observedollama_list_models
    • First observedollama_pull_model
    • First observedollama_show_model
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.8/5.0
Disambiguation5/5

Each tool targets a distinct operation: multi-turn chat, single-turn generation, health check, model listing, model pulling, and model metadata. No two tools overlap in purpose.

Naming Consistency5/5

All tools follow the 'ollama_' prefix with snake_case and clear verb_noun pattern (chat, generate, health, list_models, pull_model, show_model). Consistent and predictable.

Tool Count5/5

Six tools cover the essential operations for interacting with the Ollama service: health check, model management, and inference in two modes. The count is well-scoped for the domain.

Completeness4/5

The set covers read operations (health, list, show), inference (chat, generate), and model download. Missing a delete or update tool for models, which is a minor gap but doesn't hinder basic workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Ollama MCP Server

    NightTrek
    A
    license
    B
    quality
    F
    maintenance
    A bridge that enables seamless integration of Ollama's local LLM capabilities into MCP-powered applications, allowing users to manage and run AI models locally with full API coverage.
    10
    1,144
    74
    AGPL 3.0

  • Mcp-Omega-Brain

    VrtxOmega
    A
    license
    A
    quality
    C
    maintenance
    AI agent provenance, trust, and auditability layer. VERITAS multi-gate scoring, Cortex approval gates, S.E.A.L. hash-chain audit ledger, and semantic RAG with cryptographic provenance tracking for every decision an agent makes.
    27
    5
    MIT

  • mcp-ollama

    true-alter
    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.
    20
    Apache 2.0

  • mcp-ollama-python

    pblagoje
    A
    license
    Not graded
    quality
    A
    maintenance
    A Python MCP server that exposes local Ollama models as tools for AI assistants, enabling chat, generation, embeddings, and model management without cloud APIs.
    5
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/VrtxOmega/Ollama-Omega'

If you have feedback or need assistance with the MCP directory API, please join our Discord server