Skip to main content
Glama

Warm / unload / inspect loaded models

ollama_lifecycle
Idempotent

Check loaded models and VRAM usage, pre-warm a model to skip the cold-load cost, or unload it immediately to free memory.

Instructions

Manage model residency. status lists loaded models with their VRAM use and time until unload. warm pre-loads a model so a following dispatch skips the cold-load cost (which can be ~12s for a large model) — useful before a batch. unload frees the VRAM immediately, which matters because a large model can hold tens of GB and starve everything else on the machine.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNoOverride the base URL of the local inference server for this call only, e.g. "http://localhost:11434". Omit to use the configured host.
modelNoModel selector. Three grammars are accepted: (1) a literal installed model name or configured alias, used as-is; (2) "role:NAME" — resolve through the named role, which carries an ordered fallback chain plus its own sampling defaults; (3) "caps:a+b" — pick the best installed model advertising ALL of the named capabilities (e.g. "caps:vision+tools"), ranked by the configured policy. Omit this field entirely to use the configured default role, which is the right choice unless you have a reason. Selectors never name a model in server code — availability is discovered at runtime, so an unknown or un-pulled name is an error, not a silent substitution.
actionYesRequired. "status" reports what is resident in VRAM and when it expires; "warm" pre-loads a model so the next call skips the load; "unload" evicts it immediately to free VRAM. "warm" and "unload" need `model`.
keep_aliveNoHow long the model stays resident in VRAM after this call: a duration string such as "10m", or seconds as a number. 0 unloads immediately; a negative number keeps it loaded indefinitely. Keeping a model warm avoids re-paying a multi-second load on the next call.
timeout_msNoPer-request timeout in milliseconds. Large models on a cold load can take tens of seconds before the first token, so prefer generous values over retrying.
Behavior4/5

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

Discloses meaningful behavioral context beyond annotations: pre-loading skips ~12s cold-load cost, unload frees VRAM immediately, and large models can consume tens of GB. Consistent with annotations (idempotentHint true, readOnlyHint false, destructiveHint false). Does not contradict 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?

Three concise sentences, front-loaded with the overall purpose. Each sentence adds distinct value: action breakdown, warm use case, unload resource impact. No filler or redundancy.

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

Completeness4/5

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

Covers the three action variants, their resource implications, and return behavior for status (VRAM use, time until unload). Lacks explicit return descriptions for warm/unload, but no output schema exists and the side effects are clearly explained. Sufficient for a management tool with good annotations.

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?

Input schema has 100% parameter coverage, so the schema already explains each parameter in detail. The description adds some context (e.g., warm/unload need `model`, keep_alive duration impact) but mostly relies on the schema. Baseline 3 is appropriate.

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 states the tool's core function ('Manage model residency') and details each action with specific verbs: `status` lists loaded models, `warm` pre-loads, `unload` frees VRAM. It clearly distinguishes itself from siblings like dispatch (inference) and models (management) by focusing on runtime residency in VRAM.

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

Usage Guidelines4/5

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

Provides concrete use cases: warm is 'useful before a batch', unload matters because a large model 'can hold tens of GB and starve everything else'. It implies using status to inspect residency, but does not explicitly name alternative tools or state when not to use this tool. Clear context, but lacks explicit exclusions.

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

Install Server

Other Tools

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/Clickt-Digital-Marketing-Inc/ollama-mcp'

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