Which integrations are available for this server?

Provides access to Ollama's local LLM models through a Model Context Protocol server, allowing listing, pulling, and chatting with Ollama models

How do I use Ollama MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ollama MCP Server list my local models" 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.

en es ja ko zh

Ollama MCP Server

by rawveg

Overview Schema Related Servers Score Discussions

TypeScript

Local

🦙 Ollama MCP Server

Supercharge your AI assistant with local LLM access

License: AGPL-3.0 TypeScript MCP Coverage

An MCP (Model Context Protocol) server that exposes the complete Ollama SDK as MCP tools, enabling seamless integration between your local LLM models and MCP-compatible applications like Claude Desktop and Cline.

Features • Installation • Available Tools • Configuration • Retry Behavior • Development

✨ Features

☁️ Ollama Cloud Support - Full integration with Ollama's cloud platform
🔧 14 Comprehensive Tools - Full access to Ollama's SDK functionality
🔄 Hot-Swap Architecture - Automatic tool discovery with zero-config
🎯 Type-Safe - Built with TypeScript and Zod validation
📊 High Test Coverage - 96%+ coverage with comprehensive test suite
🚀 Zero Dependencies - Minimal footprint, maximum performance
🔌 Drop-in Integration - Works with Claude Desktop, Cline, and other MCP clients
🌐 Web Search & Fetch - Real-time web search and content extraction via Ollama Cloud
🔀 Hybrid Mode - Use local and cloud models seamlessly in one server

Related MCP server: Ollama MCP Server

💡 Level Up Your Ollama Experience with Claude Code and Desktop

The Complete Package: Tools + Knowledge

This MCP server gives Claude the tools to interact with Ollama - but you'll get even more value by also installing the Ollama Skill from the Skillsforge Marketplace:

🚗 This MCP = The Car - All the tools and capabilities
🎓 Ollama Skill = Driving Lessons - Expert knowledge on how to use them effectively

The Ollama Skill teaches Claude:

Best practices for model selection and configuration
Optimal prompting strategies for different Ollama models
When to use chat vs generate, embeddings, and other tools
Performance optimization and troubleshooting
Advanced features like tool calling and function support

Install both for the complete experience:

✅ This MCP server (tools)
✅ Ollama Skill (expertise)

Result: Claude doesn't just have the car - it knows how to drive! 🏎️

📦 Installation

Quick Start with Claude Desktop

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "ollama": {
      "command": "npx",
      "args": ["-y", "ollama-mcp"]
    }
  }
}

Global Installation

npm install -g ollama-mcp

For Cline (VS Code)

Add to your Cline MCP settings (cline_mcp_settings.json):

{
  "mcpServers": {
    "ollama": {
      "command": "npx",
      "args": ["-y", "ollama-mcp"]
    }
  }
}

🛠️ Available Tools

Model Management

Tool	Description
`ollama_list`	List all available local models
`ollama_show`	Get detailed information about a specific model
`ollama_pull`	Download models from Ollama library
`ollama_push`	Push models to Ollama library
`ollama_copy`	Create a copy of an existing model
`ollama_delete`	Remove models from local storage
`ollama_create`	Create custom models from Modelfile

Model Operations

Tool	Description
`ollama_ps`	List currently running models
`ollama_generate`	Generate text completions
`ollama_chat`	Interactive chat with models (supports tools/functions)
`ollama_embed`	Generate embeddings for text

Web Tools (Ollama Cloud)

Tool	Description
`ollama_web_search`	Search the web with customizable result limits (requires `OLLAMA_API_KEY`)
`ollama_web_fetch`	Fetch and parse web page content (requires `OLLAMA_API_KEY`)

Note: Web tools require an Ollama Cloud API key. They connect to https://ollama.com/api for web search and fetch operations.

⚙️ Configuration

Environment Variables

Variable	Default	Description
`OLLAMA_HOST`	`http://127.0.0.1:11434`	Ollama server endpoint (use `https://ollama.com` for cloud)
`OLLAMA_API_KEY`	-	API key for Ollama Cloud (required for web tools and cloud models)

Custom Ollama Host

{
  "mcpServers": {
    "ollama": {
      "command": "npx",
      "args": ["-y", "ollama-mcp"],
      "env": {
        "OLLAMA_HOST": "http://localhost:11434"
      }
    }
  }
}

Ollama Cloud Configuration

To use Ollama's cloud platform with web search and fetch capabilities:

{
  "mcpServers": {
    "ollama": {
      "command": "npx",
      "args": ["-y", "ollama-mcp"],
      "env": {
        "OLLAMA_HOST": "https://ollama.com",
        "OLLAMA_API_KEY": "your-ollama-cloud-api-key"
      }
    }
  }
}

Cloud Features:

☁️ Access cloud-hosted models
🔍 Web search with ollama_web_search (requires API key)
📄 Web fetch with ollama_web_fetch (requires API key)
🚀 Faster inference on cloud infrastructure

Get your API key: Visit ollama.com to sign up and obtain your API key.

Hybrid Mode (Local + Cloud)

You can use both local and cloud models by pointing to your local Ollama instance while providing an API key:

{
  "mcpServers": {
    "ollama": {
      "command": "npx",
      "args": ["-y", "ollama-mcp"],
      "env": {
        "OLLAMA_HOST": "http://127.0.0.1:11434",
        "OLLAMA_API_KEY": "your-ollama-cloud-api-key"
      }
    }
  }
}

This configuration:

✅ Runs local models from your Ollama instance
✅ Enables cloud-only web search and fetch tools
✅ Best of both worlds: privacy + web connectivity

🔄 Retry Behavior

The MCP server includes intelligent retry logic for handling transient failures when communicating with Ollama APIs:

Automatic Retry Strategy

Web Tools (ollama_web_search and ollama_web_fetch):

Automatically retry on rate limit errors (HTTP 429)
Maximum of 3 retry attempts (4 total requests including initial)
Request timeout: 30 seconds per request (prevents hung connections)
Respects the Retry-After header when provided by the API
Falls back to exponential backoff with jitter when Retry-After is not present

Retry-After Header Support

The server intelligently handles the standard HTTP Retry-After header in two formats:

1. Delay-Seconds Format:

Retry-After: 60

Waits exactly 60 seconds before retrying.

2. HTTP-Date Format:

Retry-After: Wed, 21 Oct 2025 07:28:00 GMT

Calculates delay until the specified timestamp.

Exponential Backoff

When Retry-After is not provided or invalid:

Initial delay: 1 second (default)
Maximum delay: 10 seconds (default, configurable)
Strategy: Exponential backoff with full jitter
Formula: random(0, min(initialDelay × 2^attempt, maxDelay))

Example retry delays:

1st retry: 0-1 seconds
2nd retry: 0-2 seconds
3rd retry: 0-4 seconds (capped at 0-10s max)

Error Handling

Retried Errors (transient failures):

HTTP 429 (Too Many Requests) - rate limiting
HTTP 500 (Internal Server Error) - transient server issues
HTTP 502 (Bad Gateway) - gateway/proxy received invalid response
HTTP 503 (Service Unavailable) - server temporarily unable to handle request
HTTP 504 (Gateway Timeout) - gateway/proxy did not receive timely response

Non-Retried Errors (permanent failures):

Request timeouts (30 second limit exceeded)
Network timeouts (no status code)
Abort/cancel errors
HTTP 4xx errors (except 429) - client errors requiring changes
Other HTTP 5xx errors (501, 505, 506, 508, etc.) - configuration/implementation issues

The retry mechanism ensures robust handling of temporary API issues while respecting server-provided retry guidance and preventing excessive request rates. Transient 5xx errors (500, 502, 503, 504) are safe to retry for the idempotent POST operations used by ollama_web_search and ollama_web_fetch. Individual requests timeout after 30 seconds to prevent indefinitely hung connections.

🎯 Usage Examples

Chat with a Model

// MCP clients can invoke:
{
  "tool": "ollama_chat",
  "arguments": {
    "model": "llama3.2:latest",
    "messages": [
      { "role": "user", "content": "Explain quantum computing" }
    ]
  }
}

Generate Embeddings

{
  "tool": "ollama_embed",
  "arguments": {
    "model": "nomic-embed-text",
    "input": ["Hello world", "Embeddings are great"]
  }
}

Web Search

{
  "tool": "ollama_web_search",
  "arguments": {
    "query": "latest AI developments",
    "max_results": 5
  }
}

🏗️ Architecture

This server uses a hot-swap autoloader pattern:

src/
├── index.ts          # Entry point (27 lines)
├── server.ts         # MCP server creation
├── autoloader.ts     # Dynamic tool discovery
└── tools/            # Tool implementations
    ├── chat.ts       # Each exports toolDefinition
    ├── generate.ts
    └── ...

Key Benefits:

Add new tools by dropping files in src/tools/
Zero server code changes required
Each tool is independently testable
100% function coverage on all tools

🧪 Development

Prerequisites

Node.js v16+
npm or pnpm
Ollama running locally

Setup

# Clone repository
git clone https://github.com/rawveg/ollama-mcp.git
cd ollama-mcp

# Install dependencies
npm install

# Build project
npm run build

# Run tests
npm test

# Run tests with coverage
npm run test:coverage

Test Coverage

Statements   : 96.37%
Branches     : 84.82%
Functions    : 100%
Lines        : 96.37%

Adding a New Tool

Create src/tools/your-tool.ts:

import { ToolDefinition } from '../autoloader.js';
import { Ollama } from 'ollama';
import { ResponseFormat } from '../types.js';

export const toolDefinition: ToolDefinition = {
  name: 'ollama_your_tool',
  description: 'Your tool description',
  inputSchema: {
    type: 'object',
    properties: {
      param: { type: 'string' }
    },
    required: ['param']
  },
  handler: async (ollama, args, format) => {
    // Implementation
    return 'result';
  }
};

Create tests in tests/tools/your-tool.test.ts
Done! The autoloader discovers it automatically.

🤝 Contributing

Contributions are welcome! Please follow these guidelines:

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Write tests - We maintain 96%+ coverage
Commit with clear messages (git commit -m 'Add amazing feature')
Push to your branch (git push origin feature/amazing-feature)
Open a Pull Request

Code Quality Standards

All new tools must export toolDefinition
Maintain ≥80% test coverage
Follow existing TypeScript patterns
Use Zod schemas for input validation

📄 License

This project is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).

See LICENSE for details.

Skillsforge Marketplace - Claude Code skills including the Ollama Skill
Ollama - Get up and running with large language models locally
Model Context Protocol - Open standard for AI assistant integration
Claude Desktop - Anthropic's desktop application
Cline - VS Code AI assistant

🙏 Acknowledgments

Built with:

Ollama SDK - Official Ollama JavaScript library
MCP SDK - Model Context Protocol SDK
Zod - TypeScript-first schema validation

⬆ back to top

Made with ❤️ by Tim Green

Available Tools

13 tools

ollama_chatA

Chat with a model using conversation messages. Supports system messages, multi-turn conversations, tool calling, and generation options.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Name of the model to use
`messages`	Yes	Array of chat messages
`tools`	No	Tools that the model can call (optional). Provide as JSON array of tool objects.
`options`	No	Generation options (optional). Provide as JSON object with settings like temperature, top_p, etc.
`format`	No		json

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description should disclose behavioral traits. It states capabilities but does not mention side effects, authentication, rate limits, or whether the tool is read-only (it is not, as it creates chat history). Basic transparency but insufficient depth.

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?

A single sentence listing key features. It is concise and includes the main action. However, it could be front-loaded with a clearer verb (e.g., 'Send a chat message to a model') and structured with bullet points for readability.

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 tool's complexity (5 params, 2 required) and no output schema, the description mentions supported features but does not detail response format or how to interpret results. It provides enough context for basic use but lacks completeness for advanced scenarios.

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 80% (high), so the description does not need to add much. It mentions features that map to parameters (e.g., 'system messages' relates to role enum) but does not explain parameter details beyond the schema. Baseline score 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?

The description clearly states the tool chats with a model using conversation messages, and lists supported features (system messages, multi-turn, tool calling, options). This differentiates it from sibling tools like ollama_generate, which is likely for single-turn generation.

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 mentions features but does not provide explicit guidance on when to use this tool vs siblings like ollama_generate. It implies usage for conversational scenarios but lacks exclusion criteria or alternative recommendations.

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

ollama_copyC

Copy a model. Creates a duplicate of an existing model with a new name.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	Name of the source model
`destination`	Yes	Name for the copied model
`format`	No		json

TDQS

C2.9/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 the action without explaining side effects (e.g., disk usage, permissions required, whether the original is affected) or any constraints.

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?

Very concise at one sentence, front-loading the action. However, it could include a brief note on output or usage 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?

No output schema exists, so the description should explain return values (e.g., success confirmation). It also lacks behavioral details to help an agent decide between sibling tools, given the simple task.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67% (source and destination have basic descriptions, format lacks description). The tool description adds no additional meaning beyond the schema, and the format parameter is not explained despite having enum options.

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's action: 'Copy a model' and specifies the resource (model) and result ('duplicate with new name'). This distinguishes it from siblings like ollama_create or ollama_delete.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like ollama_create or ollama_pull. The description does not mention scenarios, prerequisites, or exclusions.

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

ollama_createB

Create a new model with structured parameters. Allows customization of model behavior, system prompts, and templates.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Name for the new model
`from`	Yes	Base model to derive from (e.g., llama2, llama3)
`system`	No	System prompt for the model
`template`	No	Prompt template to use
`license`	No	License for the model
`format`	No		json

TDQS

B3.3/5.0

Behavior2/5

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

No annotations; description does not disclose side effects (e.g., overwrites existing model, requires pulling base model, or modifies local storage).

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?

Two sentences, no redundancy, efficient. Could add a bit more context without losing conciseness.

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?

No output schema, no annotations; description omits important context like conflict behavior, required permissions, or outcome (e.g., local file creation). Incomplete for a tool with 6 parameters.

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 83%; description adds 'structured parameters' but not much beyond what schema already provides. Baseline 3 applicable.

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 'Create a new model with structured parameters' and distinguishes from sibling tools like ollama_copy, ollama_delete, etc.

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?

Implies usage for creating a new model, but no explicit guidance on when to use vs alternatives or prerequisites (e.g., base model must exist).

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

ollama_deleteB

Delete a model from local storage. Removes the model and frees up disk space.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Name of the model to delete
`format`	No		json

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It states the destructive action and disk space effect, which is adequate but lacks details like irreversibility or any side effects.

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?

Two concise sentences with no fluff. Every word adds value.

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 low complexity (2 params, no output schema), the description is fairly complete but could mention that deletion is permanent or explain the format parameter's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (only 'model' has a description). The description does not add meaning for the 'format' parameter (enum with defaults) beyond the schema.

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 ('Delete a model from local storage') and the effect ('removes the model and frees up disk space'). This distinguishes it from siblings like ollama_chat or ollama_list.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., when to delete vs push/pull). No prerequisites or warnings about the model being in use.

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

ollama_embedA

Generate embeddings for text input. Returns numerical vector representations.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Name of the model to use
`input`	Yes	Text input. For batch processing, provide a JSON-encoded array of strings, e.g., ["text1", "text2"]
`format`	No		json

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description should disclose behaviors. It states the output type but lacks details on side effects (none expected), permissions, or rate limits. Adequate for a simple read-like operation.

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?

Two sentences, concise and front-loaded with purpose. Every word is necessary.

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?

No output schema; description could mention vector dimensions, normalization, or use cases. Lacks detail on return format but is minimally sufficient.

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 67%, description adds no extra meaning beyond what schema already provides for model and input. Format parameter has enum and default in schema. Baseline 3 since description is not incorrect but adds minimal value.

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 the action (generate), resource (embeddings), and output (numerical vector representations). It distinguishes from siblings like ollama_chat and ollama_generate which produce text.

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

Usage Guidelines2/5

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

No guidance on when to use embeddings vs other tools like chat or generation. No mention of use cases such as semantic search or when not to use.

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

ollama_generateA

Generate completion from a prompt. Simpler than chat, useful for single-turn completions.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Name of the model to use
`prompt`	Yes	The prompt to generate from
`options`	No	Generation options (optional). Provide as JSON object with settings like temperature, top_p, etc.
`format`	No		json

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'generate completion' without disclosing behavioral traits like whether it is read-only, destructive, or any side effects. Lacks information on synchronous vs streaming 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?

Two short, front-loaded sentences with no superfluous information. Every word adds value.

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?

No output schema and no description of return values. Lacks behavioral context that would help agent understand outcomes. For a single-turn generation tool, details like response format or streaming are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75% (context signal), but description adds no additional meaning beyond what input schema already provides. Does not elaborate on parameters or how 'options' or 'format' affect generation.

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 the verb 'generate' and resource 'completion from a prompt'. Distinguishes from sibling 'ollama_chat' by noting it's simpler and for single-turn completions.

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 mentions when to use this tool: for single-turn completions. Contrasts with 'chat' (sibling ollama_chat) which implies multi-turn, providing clear guidance on alternatives.

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

ollama_listA

List all available Ollama models installed locally. Returns model names, sizes, and modification dates.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format (default: json)	json

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It states the return fields (names, sizes, dates) but lacks detail on read-only nature, authentication needs, or edge cases like empty results. For a simple listing tool, this is adequate but not thorough.

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, front-loaded sentence that conveys all essential information. No unnecessary words, making it highly efficient for an AI agent to parse.

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 low complexity, one optional parameter, and no output schema required, the description fully covers what the agent needs: the action, the result contents, and the optional format. No gaps are evident.

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 one parameter ('format') with complete description in the schema itself (enum and default). The tool description adds no extra semantic value beyond what the schema already provides, so 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?

The description clearly states the action ('List'), the resource ('all available Ollama models installed locally'), and the returned information ('model names, sizes, and modification dates'). It effectively distinguishes from sibling tools like ollama_show or ollama_ps by focusing on listing local models.

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 the usage context (listing installed models) but does not provide explicit guidance on when to use this tool versus alternatives like ollama_show for details or ollama_ps for running models. 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.

ollama_psB

List running models. Shows which models are currently loaded in memory.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No		json

TDQS

B3.3/5.0

Behavior3/5

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

Description accurately states behavior but does not disclose additional traits like authorization or side effects. Since no annotations, agent must infer safety.

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?

Single sentence, front-loaded with key action and resource, no extraneous words.

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?

Adequate for a simple list tool with one optional parameter and no output schema. Could mention that the output is in JSON or markdown as per the format parameter.

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 description coverage is 0% and the tool description does not mention the format parameter or its allowed values (json, markdown). Thus adds no meaning beyond schema.

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 the tool lists running models currently in memory. Distinguishes from sibling ollama_list which likely lists all models.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like ollama_list or ollama_show.

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

ollama_pullB

Pull a model from the Ollama registry. Downloads the model to make it available locally.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Name of the model to pull
`insecure`	No	Allow insecure connections
`format`	No		json

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries full burden for behavioral disclosure. It states the tool downloads a model, implying network usage and local storage. However, it does not mention whether it overwrites existing models, handles authentication, or any rate limits. The description is basic but not misleading.

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 extremely concise: two sentences that directly convey the action and effect. Every word serves a purpose, and the primary verb appears first. There is no unnecessary elaboration.

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 simplicity of the tool (pull a model), the description covers the main intent. However, it lacks details on return format, progress indication, error handling, or prerequisites (e.g., Ollama server running). With no output schema, the agent may not know what to expect from the call.

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 moderate description coverage (67% per context signals). The description does not add any parameter-level information beyond the schema. Since schema descriptions are fairly clear for 'model' and 'insecure', and 'format' has an enum, the lack of extra context in the tool description is acceptable but not improved.

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 states the tool's purpose: pulling a model from the Ollama registry and making it available locally. The verb 'pull' matches the tool name, and the resource 'model' is explicit. However, it does not explicitly distinguish from siblings like 'ollama_push' or 'ollama_copy', though the action is sufficiently different.

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

Usage Guidelines2/5

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. It does not mention prerequisites, exclusions, or compare to sibling tools such as 'ollama_create' or 'ollama_download' (if existed). The agent is left to infer usage context.

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

ollama_pushB

Push a model to the Ollama registry. Uploads a local model to make it available remotely.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Name of the model to push
`insecure`	No	Allow insecure connections
`format`	No		json

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. Describes upload action but omits details about overwrite behavior, authentication, rate limits, or the effect of the 'insecure' parameter. Significant gaps.

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?

Two concise sentences with no redundant information. Could be slightly improved by front-loading key info, but overall efficient.

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 3 parameters, no output schema, and no annotations, the description is insufficient. Missing error cases, return format, prerequisites, and detailed usage steps.

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 67% (2 of 3 params described). Description adds no extra meaning beyond the schema—repeats 'push' and 'local to remote' but doesn't explain model naming, insecure usage, or format output.

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 uses a specific verb ('push') and resource ('model to the Ollama registry'), clearly indicating the action. It distinguishes from sibling tools like ollama_pull (download) and ollama_list.

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?

Implies usage: uploading a local model for remote availability. However, lacks explicit when-to-use vs alternatives, prerequisite (model must exist locally), or context about when to choose this over ollama_copy.

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

ollama_showA

Show detailed information about a specific model including modelfile, parameters, and architecture details.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Name of the model to show
`format`	No	Output format (default: json)	json

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. The verb 'show' strongly implies a read-only operation with no side effects, and the listed details indicate the scope. However, it does not explicitly confirm non-destructiveness or mention any required permissions or rate limits.

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 15-word sentence. It front-loads the action and resource, and every word contributes meaning. No unnecessary details.

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?

For a simple information-retrieval tool with two parameters and no output schema, the description covers the essential purpose and scope. It could specify that the output format is configurable and mention the response style, but the format parameter and sibling context make it adequate.

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 baseline is 3. The description adds no extra meaning beyond the schema for the two parameters ('model' and 'format'). It mentions 'modelfile, parameters, and architecture' but does not tie these to parameters.

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 ('Show detailed information') and the resource ('specific model'), and lists included details (modelfile, parameters, architecture). This distinguishes it from sibling tools like ollama_list (lists models) or ollama_chat (conversation).

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 model details, but does not explicitly state when to use this tool over alternatives (e.g., ollama_list for brief info, ollama_pull for downloading). No when-not or sibling comparisons are provided.

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

ollama_web_fetchA

Fetch a web page by URL using Ollama's web fetch API. Returns the page title, content, and links. Requires OLLAMA_API_KEY environment variable.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to fetch
`format`	No		json

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description covers basic behavioral traits: it fetches a web page, returns specific fields, and requires an API key. However, it omits details like rate limits, error handling, or authentication specifics beyond the key.

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?

Two concise sentences that front-load the purpose. Every sentence adds value; no redundancy.

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 only 2 parameters and no output schema, the description covers the basic return fields but lacks details on output structure variations per format, pagination, or size limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only 'url' has a description). The description adds no extra meaning beyond the schema, such as explaining when to use json vs markdown for the 'format' parameter.

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 ('fetch'), the resource ('web page by URL'), and the return values ('page title, content, and links'). This distinguishes it from sibling tools like ollama_web_search.

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?

It mentions the prerequisite 'Requires OLLAMA_API_KEY environment variable' but does not specify when to use this tool versus alternatives (e.g., ollama_web_search) or provide exclusions.

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

ollama_web_searchA

Perform a web search using Ollama's web search API. Augments models with latest information to reduce hallucinations. Requires OLLAMA_API_KEY environment variable.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The search query string
`max_results`	No	Maximum number of results to return (1-10, default 5)
`format`	No		json

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool accesses an external API and requires a key, but does not discuss potential side effects, rate limits, or data persistence. For a read-only search tool, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action, and includes a key requirement. No unnecessary words or repetition.

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?

The description lacks information about the output format (e.g., what fields are returned in JSON or markdown). Without an output schema, the agent may not know how to parse results. For a tool with a simple interface, it is marginally complete.

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 already describes all three parameters (query, max_results, format) with high coverage. The description adds no new semantic detail beyond the schema, earning a baseline score 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 tool's function: performing a web search using Ollama's API. It explicitly distinguishes from sibling tools like ollama_chat and ollama_web_fetch by specifying it searches the web, not chat or single-page fetch.

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?

It mentions the prerequisite (OLLAMA_API_KEY) and the benefit (reducing hallucinations), implying use when current information is needed. However, it doesn't explicitly state when not to use it or provide direct comparisons to alternatives like ollama_web_fetch.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: chat vs generate, list vs ps, copy/create/delete/pull/push for model management, embed for embeddings, show for details, web_fetch and web_search for web operations. No overlapping functionality.

Naming Consistency4/5

All tools use the 'ollama_' prefix and generally follow a verb_noun pattern (chat, copy, create, etc.). Minor deviations: 'ps' is an abbreviation but standard, and 'web_fetch'/'web_search' place the noun first, but overall consistent.

Tool Count5/5

13 tools is well-scoped for an Ollama server. Covers model management, text generation/chat, embeddings, and web augmentation without being excessive or sparse.

Completeness5/5

The tool set provides comprehensive CRUD for models, plus chat/generate, embeddings, and web search/fetch. No obvious gaps for the intended functionality.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

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

jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
mcp-aichat
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
SandBase
io.github.sandbaseai
Connect MCP clients to 2,000+ AI models without managing provider API keys.
AI & Machine Learning Agent Orchestration
170
Writingmate MCP
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1

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
Ollama MCP Server
Autonomous Agents RAG Systems
hyzhak
A
license
C
quality
D
maintenance
A bridge that integrates Ollama's local LLM capabilities into MCP-powered applications, enabling users to run, manage, and interact with AI models locally with full control and privacy.
Updated a year ago (2025-07-07 03:17 UTC)
9
488
5
MIT
MCP Ollama Consult Server
Autonomous Agents RAG Systems
Atomic-Germ
A
license
A
quality
C
maintenance
Enables consulting with local Ollama models for reasoning from alternative viewpoints. Supports sending prompts to Ollama models and listing available models on your local Ollama instance.
Updated 8 months ago (2026-01-12 22:08 UTC)
5
1
MIT
MCP Ollama
AI & Machine Learning Developer Tools
fastmcp-me
A
license
A
quality
D
maintenance
Integrates Ollama's local AI models with MCP clients, enabling listing models, viewing model details, and asking questions to models.
Updated a year ago (2025-09-30 13:32 UTC)
3
MIT

Appeared in Searches

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/rawveg/ollama-mcp'

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

🦙 Ollama MCP Server

✨ Features

💡 Level Up Your Ollama Experience with Claude Code and Desktop

The Complete Package: Tools + Knowledge

📦 Installation

Quick Start with Claude Desktop

Global Installation

For Cline (VS Code)

🛠️ Available Tools

Model Management

Model Operations

Web Tools (Ollama Cloud)

⚙️ Configuration

Environment Variables

Custom Ollama Host

Ollama Cloud Configuration

Hybrid Mode (Local + Cloud)

🔄 Retry Behavior

Automatic Retry Strategy

Retry-After Header Support

Exponential Backoff

Error Handling

🎯 Usage Examples

Chat with a Model

Generate Embeddings

Web Search

🏗️ Architecture

🧪 Development

Prerequisites

Setup

Test Coverage

Adding a New Tool

🤝 Contributing

Code Quality Standards

📄 License

🔗 Related Projects

🙏 Acknowledgments

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API