A
licenseB
qualityD
maintenanceMCP Ollama server integrates Ollama models with MCP clients, allowing users to list models, get detailed information, and interact with them through questions.
3
34
MIT
MCP Ollama Consult Server
by Atomic-Germ
This MCP server enables AI agents to consult with multiple Ollama models for diverse perspectives, collaborative reasoning, and persistent memory management.
Core Capabilities:
Consult Individual Models - Send prompts to specific Ollama models with optional system prompts for guided reasoning
List Available Models - Discover all models available on your local or remote Ollama instance
Compare Multiple Models - Run identical prompts against multiple models simultaneously for side-by-side output comparisons
Sequential Reasoning Chains - Execute complex multi-step workflows where subsequent consultations build upon previous results
Persistent Memory Storage - Save consultation results (key, prompt, model, response) to configured memory services or local file storage for cross-session retrieval
Timeout Management - Configure specific time limits (60-600 seconds) for complex reasoning tasks without losing context
Flexible Integration - Works with any MCP-compatible client (like Claude Desktop) through the Model Context Protocol
Enables consulting with Ollama models for alternative reasoning viewpoints, with tools for sending prompts to models and listing available models on the Ollama instance.
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., "@MCP Ollama Consult Servercompare llama3 and mistral on how to improve team collaboration"
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 Ollama Consult Server
An MCP (Model Context Protocol) server that allows consulting with Ollama models for reasoning from alternative viewpoints.
Features
consult_ollama: Send prompts to Ollama models and get responses
list_ollama_models: List available models on the local Ollama instance
compare_ollama_models: Run the ame prompt against multiple Ollama models and return their outputs side-by-side for comparison
remember_consult: Store the result of a consult into a local memory store (or configured memory service)
Related MCP server: Ollama MCP Server
Installation
Install the server:
npm i -g https://github.com/Atomic-Germ/mcp-consult/releases/download/v1.0.1/mcp-ollama-consult-1.0.1.tgzConfigure the server:
{ "servers": { "ollama-consult": { "type": "stdio", "command": "mcp-ollama-consult", "args": [] } }, "inputs": [] }
Usage
Make sure Ollama is running locally (default: (http://localhost:11434).
Start the MCP server:
mcp-ollama-consultOr for development:
npm run devConfiguration
Set the OLLAMA_BASE_URL environment variable to change the Ollama endpoint:
OLLAMA_BASE_URL=http://your-ollama-server:11434 npm startDocker
To run with Docker, build the image:
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY dist/ ./dist/
CMD ["node", "dist/index.js"]Requirements
Node.js 18+
Ollama running locally or accessible via HTTP
Available Tools
5 toolscompare_ollama_responsesB
Compare responses from multiple Ollama models on the same prompt to get diverse perspectives
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| models | No | List of model names to compare. If not specified, uses the first two available models. | |
| prompt | Yes | The prompt to send to all models | |
| context | No | Optional shared context for all models |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states a high-level purpose without details on behavior, such as default model selection, response format, error handling, or any side effects. This is insufficient for an agent to predict tool behavior.
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 a single sentence that is front-loaded with the core purpose. It is concise with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and no output schema, the description provides only a minimal purpose. It fails to explain how the tool works (e.g., default model behavior, output structure), leaving significant gaps for an agent to correctly invoke the tool. The sibling tools suggest more specialized alternatives, but no cross-referencing is provided.
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?
The input schema has 100% description coverage for all three parameters. The description does not add new meaning beyond what is already in the schema, so the baseline score of 3 applies. The description's mention of 'multiple models' aligns with the models parameter but does not enhance it.
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 tool compares responses from multiple Ollama models on the same prompt, with the goal of diverse perspectives. This specific verb+resource combination distinguishes it from the sibling tool consult_ollama, which is for single model queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting diverse perspectives, but provides no explicit guidance on when to use or not use this tool versus alternatives like consult_ollama or sequential_consultation_chain. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consult_ollamaB
Consult with Ollama AI models for architectural decisions, code reviews, and design discussions. Supports sequential chaining of consultations for complex multi-step reasoning.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| consultation_type | No | Type of consultation: "thinking" (uses kimi-k2-thinking:cloud for reasoning tasks), "instruction" (uses qwen3-vl:235b-instruct-cloud for instruction-following), or "general" (uses specified model or default). If specified, overrides the model parameter. | |
| model | No | Model to use (e.g., "qwen2.5-coder:7b-cloud"). If not specified and no consultation_type, uses the first available model. Must be a cloud model (ends with :cloud or -cloud) or locally installed. | |
| prompt | Yes | Your question or prompt for the AI model. Can reference previous consultation results. | |
| system_prompt | No | Optional system prompt to guide model behavior | |
| context | No | Optional context including code, previous results, and metadata | |
| temperature | No | Sampling temperature (0.0-2.0, default: 0.7) | |
| timeout_ms | No | Request timeout in milliseconds (default: 60000). Increase for complex prompts with system prompts (e.g., 120000-300000 for complex reasoning) | |
| auto_settings | No | If true, auto-suggest temperature/timeout based on model name + prompt heuristics (can also be enabled via MCP_AUTO_MODEL_SETTINGS=1). Does not override explicitly provided temperature/timeout_ms. |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses support for sequential chaining and model selection logic, but lacks information on side effects, idempotency, authentication requirements, or rate limits. The behavioral traits are partially covered.
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?
The description is concise at two sentences, covering purpose and a key feature (chaining). It is front-loaded with the primary use. However, it lacks structure such as bullet points or explicit sections that could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, nested objects, no output schema), the description offers adequate context about usage and chaining. However, it does not describe return values, error conditions, or the typical response format, leaving a completeness gap.
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%, so the baseline is 3. The description adds minimal value beyond the schema, only tying together the chaining context for the 'context.previous_results' parameter. Most parameter meaning is already clear from the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: consulting with Ollama AI models for architectural decisions, code reviews, and design discussions. It includes mention of sequential chaining, which helps differentiate from the sibling tool 'list_ollama_models' but could be confused with 'sequential_consultation_chain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reasoning tasks but does not explicitly state when to use this tool versus alternatives like 'compare_ollama_responses' or 'sequential_consultation_chain'. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ollama_modelsA
List all available Ollama models on the local system (installed or cloud-based)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It indicates the tool lists models from local system (installed and cloud-based), which is a safe read operation. However, it does not explain how the list is fetched or any potential latency.
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 a single clear sentence with no redundancy. It is appropriately sized 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 zero parameters, no output schema, and no annotations, the description fully explains what the tool does and its scope. Sibling tools cover different operations, making this complete.
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 the baseline is 4. The description adds meaning beyond schema by specifying the scope (local system, installed or cloud-based).
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 tool lists all available Ollama models on the local system, including both installed and cloud-based. It is distinct from sibling tools like compare_ollama_responses or consult_ollama.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving available models but provides no guidance on when to use versus alternatives or when not to use. No explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remember_contextB
Store context for use in future consultations within the same session
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Identifier for this context | |
| value | Yes | Context data to remember | |
| metadata | No | Optional metadata about the context |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'store context' without specifying overwrite behavior, persistence scope, size limits, or side effects, which is insufficient for a mutation operation.
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?
The description is a single sentence that is efficient and front-loaded. While it is concise, it could incorporate more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the presence of sibling tools, the description is too minimal. It lacks details on return values, error handling, session boundaries, and how the stored context interacts with other tools.
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?
The input schema provides 100% coverage with descriptions for all three parameters (key, value, metadata). The description adds no additional meaning beyond the schema, so it meets the baseline of 3.
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 action ('store'), resource ('context'), and purpose ('for use in future consultations'). It differentiates from sibling tools like 'compare_ollama_responses' and 'consult_ollama' by focusing on memory/retention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage within a session but provides no explicit guidance on when to use versus alternatives (e.g., sequential_consultation_chain). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sequential_consultation_chainB
Run a sequence of consultations where each consultant builds on previous responses, enabling complex multi-step reasoning.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| consultants | Yes | ||
| context | No | ||
| flowControl | No | ||
| memory | No |
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description hints at sequential dependency but fails to disclose error handling, memory effects, or resource usage. With no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks structure and does not earn its place for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, 4 params, no output schema, no annotations), the description is far too minimal and incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the 4 parameters (consultants, context, flowControl, memory), providing no meaning beyond the schema structure.
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 tool runs a sequence of consultations with chaining, which distinguishes it from siblings like consult_ollama (single) and compare_ollama_responses (comparison). It uses specific verbs and explains multi-step reasoning.
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?
The description implies use for complex multi-step reasoning, differentiating from single consultations, but lacks explicit when-not-to-use or direct comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.6/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: compare_ollama_models runs prompts across multiple models for comparison, consult_ollama gets a single model's response for reasoning, list_ollama_models enumerates available models, and remember_consult stores consult results. The descriptions reinforce these distinct roles, making tool selection unambiguous.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'ollama' or 'consult' as part of the noun phrase: compare_ollama_models, consult_ollama, list_ollama_models, remember_consult. This uniformity makes the set predictable and easy to understand, with no deviations in style or convention.
Tool Count4/5
With 4 tools, the count is slightly lean but reasonable for the server's purpose of consulting and comparing Ollama models. It covers core operations (consult, compare, list, store) without bloat, though a few additional tools like managing models or configuring memory might enhance completeness without being essential.
Completeness4/5
The toolset provides good coverage for the domain of consulting Ollama models, including key operations: consulting models, comparing outputs, listing available models, and storing results. Minor gaps exist, such as tools for model management (e.g., pull or delete models) or advanced memory operations, but agents can work effectively with the provided tools for core workflows.
Maintenance
ActivityInactive
ResponsivenessSyncing
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
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for generating rough-draft project plans from natural-language prompts.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables seamless integration between Ollama's local LLM models and MCP-compatible applications, supporting model management and chat interactions.131,144170AGPL 3.0
- AlicenseAqualityDmaintenanceIntegrates Ollama's local AI models with MCP clients, enabling listing models, viewing model details, and asking questions to models.3MIT
- AlicenseBqualityDmaintenanceA universal MCP server that integrates with local Ollama instances, enabling AI-powered chat, model management, and text generation from any MCP-compatible IDE or application.62263MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Atomic-Germ/mcp-consult'
If you have feedback or need assistance with the MCP directory API, please join our Discord server