Skip to main content
Glama

check_ollama

Verify the LLM backend is running and the configured embedding or chat model is installed before calling semantic search or symbol explanation tools.

Instructions

Check whether the LLM backend is running and the configured embedding/chat model is installed.

Read-only: yes. No side effects. Call before smart_search, semantic_search, or explain_symbol (when on-demand fallback is expected — pre-computed analysis returns instantly without the LLM backend).

Args: project_root: Project root. Auto-detected if omitted. Used to locate the project's LLM configuration. project: Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.

Returns: dict: {ollama_enabled (bool), status (str — "ok"|"disabled"| "not_configured"|"model_missing"|"embedding_unavailable"|"error"), ollama_running (bool), ollama_url (str), configured_model (str), num_ctx (int), installed_models (list[str]), chat_api (dict — {configured (bool), model (str)}: whether an external chat API replaces Ollama, and the model it names; a configured one adds endpoint, format, and compliance_warning for an external host), configured_embed_model (str), embedding_installed (bool), embedding_backend (str — "ollama", or "local" for a sentence-transformers or ft:// model, which needs no Ollama: it counts as installed, and with chat on an external API a stopped Ollama still gives "ok"), message (str, when status is not "ok"), model_details (list[dict]), suggest_cloud (bool), vec_available (bool), vec_error (str, optional), debug_log (str, optional — only when debug logging is enabled)}

The chat model is looked for on the Ollama server of the chat
calls: ``ollama_url``, or the Ollama server that ``chat_api_base``
names.  An OpenAI-compatible ``chat_api_base`` runs the model
itself, and no Ollama server is asked for it.  ``"model_missing"``:
``message`` names a command for each missing model, which sets
``OLLAMA_HOST`` to the server that must hold the model.
``"error"`` also means that the Ollama server of ``chat_api_base``
gives no model list.  When the server of ``ollama_url`` does not
answer, the chat model is not looked for.

ollama_url, num_ctx, installed_models, model_details,
configured_embed_model, and embedding_installed are present only
when Ollama runs; configured_model also needs chat on Ollama.
``"disabled"`` gives only status, ollama_enabled,
ollama_running, configured_model, num_ctx, and message;
embedding_backend is present on every other status.

Input Schema

NameRequiredDescriptionDefault
projectNoProject name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.
project_rootNoProject root. Auto-detected if omitted. Used to locate LLM config. Falls back to auto-detection when omitted. This field also accepts a project name or a project_id, but project is the clear field for those.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.30.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / project
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.",
      +  "title": "Project"
      +}
    • changedInput schema / properties / project_root / description
      Previous value: -"Project root. Auto-detected if omitted. Used to locate LLM config. Falls back to auto-detection when omitted."New value: +"Project root. Auto-detected if omitted. Used to locate LLM config. Falls back to auto-detection when omitted. This field also accepts a project name or a project_id, but project is the clear field for those."
  2. Changed1 schema field changedv0.25.3
    • changedInput schema / properties / project_root / description
      Previous value: -"Project root. Auto-detected if omitted. Ignored by this tool."New value: +"Project root. Auto-detected if omitted. Used to locate LLM config. Falls back to auto-detection when omitted."
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does it well: it declares read-only/no-side-effects, enumerates every status value ('ok'|'disabled'|'not_configured'|'model_missing'|...), explains per-status field presence, describes the chat_api_base/OpenAI-compatible fallback, and documents ''model_missing'' and ''error'' semantics. This is unusually rich behavioral disclosure.

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?

It is long, but front-loads purpose and safety, then uses clear Args/Returns sections. Nearly every sentence earns its place given there is no output schema, though the Returns section is dense enough that it edges toward overload for a two-parameter check.

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 no annotations and no output schema, the description must supply both the safety profile and the return contract, and it does: it enumerates statuses, conditional field presence, fallback backends, and error cases. An agent has everything needed to interpret the result correctly.

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 description coverage is 100% and the Args section in the description largely restates the schema text for project_root and project, including the mutual-exclusivity note that is already in the schema. It adds essentially no meaning beyond the structured field descriptions, so the baseline 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 opening sentence states a specific verb and resource — 'Check whether the LLM backend is running and the configured embedding/chat model is installed' — which is unambiguous and clearly distinct from siblings like check_dependencies or configure_llm. An agent can tell what this tool answers without opening the schema.

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?

It explicitly states when to call it ('Call before smart_search, semantic_search, or explain_symbol') and even carves out the exception where pre-computed analysis returns instantly without the backend, so the agent knows when NOT to call it. This is routing-level guidance, not mere implication.

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