Provides tools for interacting with local Ollama instances across a fleet of hosts, enabling model listing, prompt generation, fleet health monitoring, multi-model comparison, smart routing to loaded models, and model pulling.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ollama-fleet-mcp check fleet health across all hosts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that exposes the local Ollama fleet (mac-studio, corsair, alien18) as tools for Claude Code.
Rewritten 2026-08-08 — the original was lost with the X10 Pro_A SSD; no backup or GitHub remote existed. This is a fresh implementation covering the same purpose (fleet-aware Ollama routing/inspection from inside Claude Code), not a recovery of the original code.
list_models(host=None) — installed models per host, or all hosts if omitted.
generate(host, model, prompt, timeout_sec=120) — send a prompt to a specific host+model, return the response.
fleet_health() — reachability, latency, and model count for every host.
compare_models(prompt, targets) — send the same prompt to multiple {host, model} pairs in parallel, return responses side by side.
smart_generate(model, prompt, timeout_sec=120) — routes to whichever host already has model loaded in memory (checks /api/ps), falling back to any host that has it installed. Avoids cold-load latency.
pull_model(host, model, timeout_sec=900) — pull/verify a model on a specific host.
Related MCP server: MCP-Demo
Configured in hosts.json (Tailscale IPs):
{
"mac-studio": "http://100.68.94.14:11434",
"corsair": "http://100.94.117.48:11434",
"alien18": "http://100.87.2.47:11434"
}mac mini is intentionally excluded — its local Ollama is loopback-only, used internally by ollaroute/ollafifo/ollasecret, not a fleet compute node.
uv run python main.pyclaude mcp add ollama-fleet -s user -- uv run --directory ~/ollama-fleet-mcp python main.py-s user registers it at user scope, so it's available in every project, not just when your cwd happens to match wherever it was registered from.
Send the same prompt to multiple host/model pairs in parallel and return responses side by side.
Args:
prompt: the prompt text to send to every target.
targets: list of {"host": ..., "model": ...} dicts, e.g.
[{"host": "corsair", "model": "qwen3:32b"}, {"host": "mac-studio", "model": "qwen3.6:27b-coding-mxfp8"}]
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| targets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses parallel execution and side-by-side response format, but does not mention failure handling, error behavior, or any constraints (e.g., rate limits). This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single purpose sentence followed by a well-formatted Args block. Each line earns its place, with no redundant information. The structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description only vaguely mentions 'side by side' without specifying the return format. It also does not cross-reference sibling tools for discovering hosts/models or mention potential errors. Given its simplicity, it covers the basics but leaves gaps in return structure and operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description compensates well by explaining 'prompt' clearly and defining the 'targets' structure with an example. It adds meaningful semantics beyond the minimal schema types, though it could be more exhaustive about possible target keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: send the same prompt to multiple host/model pairs in parallel and return responses side by side. It distinguishes from sibling tools like generate (single model) and list_models (listing), focusing on parallel comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (comparing multiple models) and the parallel execution model, providing clear context. However, it does not explicitly state when not to use this tool or mention alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check reachability and model count for every host in the fleet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It implies a read-only operation via 'check' and specifies the metrics (reachability, model count), but it does not mention potential side effects, authentication needs, or how unreachable hosts are handled, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase ('reachability', 'model count', 'every host', 'fleet') carries essential information, making it maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, annotations, or output schema, the description is nearly complete. It explains what is checked and the scope, but it does not describe the return format or error behavior. Given the low complexity, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema is empty. Baseline 4 applies for zero-parameter tools; the description already conveys the full meaningful action, so no additional parameter elaboration is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking reachability and model count for every host in the fleet. It uses a specific verb ('check') and resource, and it distinguishes itself from sibling tools like list_models and pull_model by focusing on fleet-wide health rather than model operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no mentions of use cases, prerequisites, or contextual triggers, leaving the agent to infer that it is for fleet monitoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a prompt to a specific model on a specific fleet host and return its response.
Args:
host: fleet host name (e.g. "mac-studio", "corsair", "alien18").
model: model name as reported by list_models (e.g. "qwen3:32b").
prompt: the prompt text to send.
timeout_sec: max seconds to wait for a response (default 120).
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| model | Yes | ||
| prompt | Yes | ||
| timeout_sec | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention potential side effects, permissions, rate limits, timeout behavior, error handling, or the structure of the response. The timeout_sec parameter is documented but not explained in terms of what happens when it expires.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a single, clear purpose sentence followed by a structured Args list. Every sentence provides necessary information without redundancy, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and all parameters, but omits return value format, error cases, and execution constraints such as token limits or streaming behavior. Given the lack of annotations and output schema, this is a noticeable gap, though the tool is simple enough that the description is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully. Each parameter is explained with meaningful context: host examples, model source from list_models, prompt intent, and a clear definition of timeout_sec. This adds real value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a prompt to a specific model on a specific fleet host and returns the response. The verb 'send' and resource 'model on a fleet host' are specific, and it distinguishes itself from siblings like list_models and smart_generate by emphasizing 'specific' in both host and model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing 'model name as reported by list_models', suggesting a prerequisite call to list_models. However, it does not explicitly state when to choose this tool over smart_generate or other alternatives, nor does it provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List installed Ollama models per fleet host.
Args:
host: optional host name (e.g. "corsair"). If omitted, lists all fleet hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It implies a read-only action with 'list', but does not explicitly state that no changes are made, nor does it describe error behavior or output format. It does add value by explaining the host scoping (per host or all hosts).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-sentence docstring with a clear first line and a concise Args section. There is no redundancy or extraneous information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description covers core behavior and parameter semantics well. However, there is no output schema, and the description does not explicitly describe the return format (e.g., list of model names per host), which is a minor gap given the lack of structured output info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage (0%), but the description fully compensates by explaining the host parameter with an example ('corsair') and stating the default behavior when omitted (lists all fleet hosts). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List installed Ollama models per fleet host', which is a specific verb-resource-scope combination. It is distinct from sibling tools like pull_model, generate, and compare_models, so an agent can easily differentiate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like compare_models or pull_model. It only explains the host parameter behavior, not the usage context or exclusions, leaving the agent to infer when listing models is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull (download/verify) a model onto a specific fleet host.
Args:
host: fleet host name.
model: model name to pull (e.g. "qwen3:32b").
timeout_sec: max seconds to wait — large models can take a while (default 900).
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| model | Yes | ||
| timeout_sec | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses that downloads can take time and defaults timeout_sec to 900, but it does not mention permissions, side effects, or behavior if the model already exists. This is moderate disclosure for a simple download tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one introductory sentence and a short Args block with field explanations. Every sentence contributes new information, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the core functionality and parameters, including a timeout consideration. It does not explain return values or error possibilities, which is a minor gap for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists parameter names and types, with 0% description coverage. The description compensates by explaining each parameter's purpose, including an example model name and the meaning of timeout_sec, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Pull (download/verify) a model onto a specific fleet host,' which clearly states the action and resource. It distinguishes itself from sibling tools like list_models or generate by specifying the model download/verify operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to download a model to a specific host. However, it does not explicitly state when not to use it or mention alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a response for model, routed to whichever fleet host already has it loaded
in memory (skips cold-load latency). Falls back to any host that has it installed but not
loaded, and errors if no host has the model at all.
Args:
model: model name (e.g. "qwen3:32b").
prompt: the prompt text to send.
timeout_sec: max seconds to wait for the generate call (default 120).
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| prompt | Yes | ||
| timeout_sec | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the smart routing behavior, fallback to installed-but-not-loaded hosts, and the error condition when no host has the model. The timeout_sec default is also mentioned. This adds significant behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a compact Args list. Every sentence is necessary: the first explains the core behavior, the second the fallback/error, and the Args list covers parameters. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, routing logic, fallback, errors, and all parameters. The only gap is the lack of any mention of the return value, but given the simple generate response nature and no output schema, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, but the Args section covers all three parameters: model with an example ('qwen3:32b'), prompt with purpose, and timeout_sec with default. This fully compensates for the 0% schema coverage, though it could add more detail on constraints or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate a response for `model`' with a specific routing behavior. It distinguishes itself from the sibling 'generate' by explaining the smart routing to a host with the model already loaded, making the purpose specific and unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when you want to avoid cold-load latency by routing to a loaded host. It also describes fallback and error conditions. However, it does not explicitly name alternatives like 'generate' or provide exclusions, so it lacks a full when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have clearly distinct purposes: list_models for inventory, fleet_health for status, pull_model for downloading, compare_models for side-by-side comparison. However, generate and smart_generate both perform text generation and differ only in routing logic (explicit host vs auto-route), which could cause misselection.
Naming conventions are mixed: list_models and pull_model use verb_noun, generate is a bare verb, fleet_health is a noun phrase, smart_generate is adjective_verb. The names are readable but do not follow a single consistent pattern.
Six tools is a well-scoped set for an Ollama fleet management server, covering the essential operations of listing models, generating responses, checking health, comparing models, and pulling models without unnecessary bloat.
The tool surface covers the core workflows: inventory (list_models), generation (generate, smart_generate), comparison (compare_models), health monitoring (fleet_health), and model acquisition (pull_model). Missing operations like delete_model or model detail inspection are minor gaps that agents can work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Obrais-cloud/ollama-fleet-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
