de en es ja ko ru zh

Ollama-Omega

Name: Ollama-Omega
Author: VrtxOmega

by VrtxOmega

Overview Schema Related Servers Score Discussions

Python

Hybrid

Ollama-Omega MCP server

Усиленный MCP-сервер, который связывает полную экосистему Ollama — как локальные модели, так и облачные гиганты — с любой IDE, поддерживающей MCP. Никаких скриптов-оберток. Никаких раздутых SDK. Только один файл Python с двумя зависимостями.

ПРИНЦИП ПРОЕКТИРОВАНИЯ: Ollama-Omega не абстрагирует Ollama. Он предоставляет полный API Ollama через 6 проверенных инструментов с обработкой ошибок без потери информации.

Архитектура

┌─────────────────────────────────────────────────────┐
│                    MCP Client (IDE)                  │
│         Claude Desktop / Antigravity / etc.          │
└──────────────────────┬──────────────────────────────┘
                       │ stdio (JSON-RPC 2.0)
┌──────────────────────▼──────────────────────────────┐
│              ollama_mcp_server.py                     │
│  ┌──────────┐ ┌──────────┐ ┌───────────────────┐    │
│  │ Validator│ │ Dispatch │ │ Singleton httpx   │    │
│  │ + Schema │→│ Router   │→│ AsyncClient       │    │
│  └──────────┘ └──────────┘ │ (no redirects)    │    │
│                             └─────────┬─────────┘    │
└───────────────────────────────────────┼──────────────┘
                                        │ HTTP
┌───────────────────────────────────────▼──────────────┐
│                  Ollama Daemon                        │
│    Local models (GPU) │ Cloud models (API proxy)      │
└───────────────────────────────────────────────────────┘

Related MCP server: Mcp-Omega-Brain

Инструменты (6)

Инструмент	Назначение
`ollama_health`	Проверка соединения и список запущенных/загруженных моделей
`ollama_list_models`	Список всех доступных моделей с размером, статусом загрузки и датой изменения
`ollama_chat`	Отправка запроса на завершение чата с историей сообщений и системным промптом
`ollama_generate`	Генерация ответа на заданный промпт без истории чата
`ollama_show_model`	Отображение подробной информации о конкретной модели (лицензия, параметры)
`ollama_pull_model`	Загрузка модели из библиотеки Ollama

Аудит безопасности

#	Категория	Мера защиты
1	SSRF	Перенаправления отключены в клиенте httpx (`follow_redirects=False`)
2	Утечка ресурсов	Синглтон `AsyncClient` — один пул соединений на время жизни сервера
3	Валидация ввода	Проверка `_validate_required()` для каждого инструмента перед любым HTTP-вызовом
4	Безопасность JSON	Обертка `_safe_json()` — никогда не падает при некорректных ответах
5	Структурированное логирование	Весь вывод stderr через модуль `logging`, а не через обычный `print()`
6	DRY-полезные нагрузки	`_build_options()` централизует маппинг температуры/токенов
7	Санитизация ошибок	Хелпер `_error()` — никаких трассировок стека, внутренние данные не утекают клиенту

Быстрый старт

Требования

Python 3.11+
pip install mcp httpx

Настройка в Claude Desktop / Antigravity

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

Переменные окружения

Переменная	По умолчанию	Описание
`OLLAMA_HOST`	`http://localhost:11434`	URL демона Ollama
`OLLAMA_TIMEOUT`	`300`	Тайм-аут запроса в секундах (длительный для загрузки больших моделей/облачного вывода)
`PYTHONUTF8`	—	Установите в `1` для безопасности Unicode в Windows

Облачные модели

Ollama-Omega не зависит от версии. Если ваш демон Ollama предоставляет доступ к облачным моделям (например, qwen3.5:397b-cloud через API-прокси), они доступны через те же 6 инструментов — изменение конфигурации не требуется.

Структура файлов

Ollama-Omega/
  ollama_mcp_server.py     # MCP server (~307 lines) — hardened, single-file
  pyproject.toml            # Package metadata, CLI entry, PyPI classifiers
  requirements.txt          # mcp>=1.0.0, httpx>=0.27.0
  glama.json                # Glama MCP directory registration
  LICENSE                   # MIT
  CHANGELOG.md              # Version history
  tests/
    test_server.py           # 48 tests — tools, dispatch, errors, SSRF, config
  examples/
    basic_usage.py           # Programmatic MCP client example
  docs/
    BUILD_SPEC.md            # Internal build specification

Тестирование

pip install pytest
python -m pytest tests/ -v

48 тестов, охватывающих:

Определения инструментов — валидация схемы, обязательные поля, описания
Вспомогательные функции — построитель опций, валидация, безопасность JSON, форматирование ошибок
Диспетчер — все 6 путей инструментов с мокированными HTTP-ответами
Обработка ошибок — соединение, тайм-аут, HTTP-статус, санитизация исключений
Конфигурация — значения по умолчанию, защита от SSRF, идентификация сервера

Сопутствующий сервер

Ollama-Omega является транспортным уровнем для Omega Brain MCP — эпизодическая память между сессиями + 10-шлюзовый конвейер сборки VERITAS. Вместе они образуют суверенный стек интеллекта.

Лицензия

MIT

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

Name	Required	Description
`model`	Yes	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.
`system`	No	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.
`messages`	Yes	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.
`max_tokens`	No	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.
`temperature`	No	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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Error message if the request failed (e.g., model not found). Only present on failure.
`model`	Yes	The model that generated the response.
`message`	No	The assistant's response message.
`eval_count`	No	Number of tokens generated in the response.
`total_duration`	No	Total 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

Name	Required	Description
`model`	Yes	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.
`prompt`	Yes	The input text prompt to generate a completion from. Can be any length — the model's context window is the only limit.
`system`	No	System prompt to set model behavior, persona, or output format constraints for this generation.
`max_tokens`	No	Maximum tokens to generate. Maps to Ollama 'num_predict'. Use -1 for unlimited (model stops at its natural end token).
`temperature`	No	Sampling temperature. 0.0 = deterministic, 2.0 = maximum randomness. Default is model-dependent. Use low values for factual/code tasks.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Error message if the request failed. Only present on failure.
`model`	Yes	The model that generated the response.
`response`	No	The generated text completion.
`eval_count`	No	Number of tokens generated.
`total_duration`	No	Total 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

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`host`	Yes	The Ollama host URL that was checked (e.g., 'http://localhost:11434').
`error`	No	Error message if connection failed. Only present on failure.
`connected`	No	True if the Ollama daemon responded to the health check.
`running_models`	No	Models 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

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`models`	Yes	All 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

Name	Required	Description	Default
`model`	Yes	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'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Error message if the download failed (e.g., network error, model not found in library). Only present on failure.
`status`	No	Download 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

Name	Required	Description	Default
`model`	Yes	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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Error message if the model was not found. Only present on failure.
`details`	No	Model architecture details.
`template`	No	Go template string used for prompt formatting.
`modelfile`	No	The full Modelfile content defining this model's configuration.
`parameters`	No	Runtime 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.

6 tool updatesApr 30, 2026
- Addedollama_chat
- Addedollama_generate
- Addedollama_health
- Addedollama_list_models
- Addedollama_pull_model
- Addedollama_show_model
6 tool updatesv1.0.4Apr 30, 2026
- Removedollama_chat
- Removedollama_generate
- Removedollama_health
- Removedollama_list_models
- Removedollama_pull_model
- Removedollama_show_model

6 tool updatesv1.0.3Apr 16, 2026

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"
+}

6 tool updatesv1.0.2Apr 15, 2026
- 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

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

MCP Aggregation Gateway — 22k+ MCP search & call A
cn.pianam.mcp
One AI endpoint to search and call 22k+ MCP servers; 50+ hosted tools work instantly, no key.
31
OpenAI Tools MCP Server B
ai.com.mcp
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Image & Video Processing Audio Processing Multimedia Processing
927
royal-mcpOAuth
com.royalplugins
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Content Management Systems Developer Tools
29
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2

Related MCP Servers

Ollama MCP Server
Code Execution Developer Tools
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.
Updated 2 years ago (2025-01-01 22:43 UTC)
10
1,144
74
AGPL 3.0
Mcp-Omega-Brain
Autonomous Agents AI & Machine Learning Security
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.
Updated 3 months ago (2026-06-11 22:05 UTC)
27
5
MIT
mcp-ollama
AI & Machine Learning Code Execution Developer Tools
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.
Updated 12 days ago (2026-08-26 03:05 UTC)
20
Apache 2.0
mcp-ollama-python
AI & Machine Learning Developer Tools
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.
Updated 15 days ago (2026-08-22 23:18 UTC)
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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