Which integrations are available for this server?

Provides tools to generate text, chat, embed text, generate code, summarise text, list models, and pull models using locally running Ollama models.

How do I use Claude Sidekick?

1. Click on "Deploy 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., "@Claude Sidekick generate a simple email template for customer onboarding using Ollama" 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.

Claude Sidekick

by andrewbrereton

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Claude Sidekick

A Model Context Protocol (MCP) server that connects Claude to your local Ollama models, allowing you to offload simpler tasks and save your Claude tokens for complex work.

Quick Start

1. Install Ollama

First, install Ollama on your system:

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.ai/install.sh | sh

# Windows
# Download from https://ollama.ai/download

Start Ollama:

ollama serve

2. Pull Some Models

Download useful models for different tasks:

# General purpose models
ollama pull gpt-oss           # OpenAI's open-weight model
ollama pull llama3.2          # Fast, capable model
ollama pull qwen2.5           # High-quality text generation

# Specialised models
ollama pull deepseek-coder    # Code generation
ollama pull nomic-embed-text  # Text embeddings
ollama pull llama3.2:1b       # Lightweight for simple tasks

3. Set Up the MCP Server

Create a new directory and install dependencies:

mkdir mcp-ollama-server
cd mcp-ollama-server

# Copy the files (index.ts, package.json, tsconfig.json)
# Then install dependencies:
npm install

# Create src directory and move index.ts there
mkdir src
mv index.ts src/

# Build the project
npm run build

4. Configure Claude Desktop

Add the server to your Claude Desktop configuration:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "ollama": {
      "command": "node",
      "args": ["/absolute/path/to/your/mcp-ollama-server/dist/index.js"],
      "env": {}
    }
  }
}

5. Restart Claude Desktop

Restart Claude Desktop to load the new MCP server. You should see the Ollama tools available in Claude.

Related MCP server: LMStudio-MCP

Available Tools

`ollama_generate_text`

Generate text for simple writing tasks, basic summaries, or straightforward content creation.

Best for: Simple writing, basic explanations, content generation

`ollama_chat`

Have conversations with local models for Q&A, explanations, or dialogue-based tasks.

Best for: Q&A sessions, explanations, interactive tasks

`ollama_embed_text`

Generate text embeddings for semantic similarity, clustering, or search.

Best for: Document similarity, semantic search, clustering

`ollama_code_generation`

Generate code using specialised coding models.

Best for: Simple scripts, boilerplate code, basic programming tasks

`ollama_summarise`

Summarise text content with different length options.

Best for: Document summaries, article condensation

`ollama_list_models`

List all available models on your Ollama installation.

`ollama_pull_model`

Download new models to Ollama.

Usage Examples

Once configured, Claude can use these tools like this:

Text Generation:

"Use Ollama to generate a simple email template for customer onboarding"

Code Generation:

"Have DeepSeek Coder create a Python script to parse CSV files"

Embeddings:

"Generate embeddings for these document titles using Nomic"

Summarisation:

"Use Llama to create a brief summary of this article"

Model Recommendations

For Text Generation

gpt-oss - Excellent balance of speed and quality
llama3.2 - Good balance of speed and quality
qwen2.5 - Higher quality but slower
llama3.2:1b - Very fast for simple tasks

For Coding

gpt-oss - Excellent code generation
deepseek-coder - Great code generation
qwen2.5-coder - Alternative coding model

For Embeddings

nomic-embed-text - Fast, high-quality embeddings
mxbai-embed-large - Larger embedding model

Configuration

Customising the Server

Edit src/index.ts to modify:

Base URL: Change Ollama endpoint (default: http://localhost:11434)
Timeout: Adjust request timeout (default: 5 minutes)
Default Models: Modify which models are used by default
Temperature Settings: Adjust creativity/randomness

Environment Variables

You can override settings with environment variables:

export OLLAMA_BASE_URL=http://localhost:11434
export OLLAMA_TIMEOUT=300000

Troubleshooting

"Failed to connect to Ollama"

Ensure Ollama is running: ollama serve
Check if it's accessible: curl http://localhost:11434/api/tags
Verify no firewall blocking port 11434

"Model not found"

List available models: ollama list
Pull the missing model: ollama pull model-name

"MCP server not appearing in Claude"

Check the config file path is correct
Verify the absolute path to the built JavaScript file
Restart Claude Desktop completely
Check Claude Desktop logs for errors

Performance Tips

Use smaller models for simple tasks:
- llama3.2:1b for basic text generation
- qwen2.5:0.5b for very simple tasks

Keep frequently used models warm:

# Pre-load models to keep them in memory
ollama run llama3.2 "hello"
ollama run deepseek-coder "print hello"

Adjust temperature based on task:
- Low (0.1-0.3) for factual/coding tasks
- Medium (0.5-0.8) for creative writing
- High (0.9-1.2) for very creative tasks

Development

Running in Development

npm run dev        # Run with hot reload
npm run watch      # Watch mode
npm run type-check # Check TypeScript types
npm run lint       # Lint code

Adding New Tools

To add new capabilities:

Define the tool in setupHandlers()
Add the handler method
Update the Ollama client if needed
Rebuild and restart

Extending Model Support

To support new model types:

Add model configuration in the constructor
Create specific handler methods
Add appropriate prompting strategies

Example Workflow

Here's how you might use this in practice:

Initial analysis with Claude: "I need to analyse this dataset and create a comprehensive report"
Delegate simple tasks: "Use Ollama to generate basic descriptions for each data column"
Complex analysis with Claude: Claude does the sophisticated statistical analysis and insights
Offload summarisation: "Use Llama to summarise each section of findings"
Final review with Claude: Claude assembles everything into a polished report

This approach maximises your Claude token efficiency while still getting comprehensive results.

Security Notes

This server runs locally and doesn't send data externally
All model inference happens on your machine
No API keys or external services required
Your data stays completely private

Contributing

Feel free to extend this server with additional capabilities:

Image generation support
Model fine-tuning integration
Performance monitoring
Model switching strategies
Custom prompt templates

Available Tools

7 tools

ollama_chatA

Have a conversation with local Ollama for SIMPLE Q&A, factual questions, or basic explanations that don't require deep reasoning. Prefer for routine queries to save Claude tokens. AVOID for complex analysis, nuanced discussions, or tasks requiring sophisticated reasoning.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No	Ollama model name	gpt-oss
`messages`	Yes	Array of chat messages with role and content
`temperature`	No

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 full burden. It discloses that the tool is intended for simple tasks and explicitly warns against complex reasoning, which is a key behavioral limitation. It also mentions the token-saving rationale. However, it doesn't describe output format or error behavior, which would enhance transparency further.

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 composed of two sentences, front-loading the primary purpose and then providing usage guidance. It is concise and every sentence earns its place, though the use of ALL CAPS for emphasis is slightly distracting but does not harm clarity.

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?

The tool has no output schema and no annotations, so the description must provide context. It sufficiently covers purpose, usage boundaries, and the reason for preferring this tool. It doesn't explicitly mention prerequisites like local Ollama being installed or running, but the name and description imply this. Overall, adequate for a chat tool.

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 description does not mention any parameters, leaving parameter semantics entirely to the schema. Schema description coverage is 67% (model and messages are described, temperature is not). The description adds no extra meaning for parameters, so a baseline score of 3 is appropriate given the moderate schema coverage.

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 purpose: 'Have a conversation with local Ollama for SIMPLE Q&A, factual questions, or basic explanations.' This uses a specific verb ('have a conversation') and resource ('local Ollama'), and the scope ('SIMPLE Q&A...') distinguishes it from sibling tools like code generation or summarization.

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?

Explicit guidance is provided: 'Prefer for routine queries to save Claude tokens' and 'AVOID for complex analysis, nuanced discussions, or tasks requiring sophisticated reasoning.' This gives clear when-to-use and when-not-to-use instructions, even though specific sibling alternatives are not named.

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

ollama_code_generationA

Generate SIMPLE code like getters/setters, basic CRUD operations, validation rules, boilerplate code, or routine functions. Use for mechanical coding tasks that follow established patterns. AVOID for architectural decisions, complex business logic, or code requiring sophisticated design patterns.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	Coding task description
`model`	No	Coding model name	gpt-oss
`language`	No	Programming language	python
`temperature`	No

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It discloses a capability boundary (only simple/mechanical code) and defines scope, but does not describe return format, error behavior, or other runtime characteristics beyond that boundary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three sentences, front-loaded with action and examples. Every sentence provides distinct value, and the AVOID clause is a compact clear exclusion.

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, low-complexity tool with no output schema, the description provides adequate context about scope and boundaries. It lacks explicit output return details but the examples and use cases make the intended result obvious.

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 covers 3 of 4 params (task, model, language), and temperature lacks a description. The description does not elaborate on parameter semantics beyond the schema, so it neither adds nor detracts; baseline applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Generate SIMPLE code' and lists concrete examples (getters/setters, CRUD, validation, boilerplate), making the tool's purpose unmistakable. The 'mechanical coding tasks' phrasing differentiates it from sibling text generation and chat tools.

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 explicitly states 'Use for mechanical coding tasks that follow established patterns' and 'AVOID for architectural decisions, complex business logic...' providing clear when/when-not guidance. However, it does not name a specific alternative sibling to route complex code requests to.

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

ollama_embed_textA

Generate text embeddings using local embedding models like nomic-embed-text. Ideal for batch embedding tasks, semantic search, similarity comparisons, and clustering. Use this for routine embedding generation to save Claude tokens.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text to embed
`model`	No	Embedding model name	nomic-embed-text

TDQS

A4/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 burden. It discloses that the tool uses local models and saves Claude tokens, which are useful behavioral traits. However, it does not mention prerequisites like model availability, return format, or rate limits. This is moderate disclosure, neither bare nor 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 three sentences, each providing distinct value: what it does, use cases, and when to use it. It is concise, front-loaded with the primary action, and avoids redundancy.

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

Completeness4/5

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

For a simple two-parameter tool with no output schema, the description covers the purpose, use cases, and a benefit. It implicitly conveys the return type (embeddings) through the name and context. Minor gap: no mention of model management prerequisites, but sibling tools like ollama_list_models and ollama_pull_model suggest that.

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 100%, with both 'text' and 'model' parameters clearly described in the schema. The description adds no additional parameter details beyond mentioning the default model in an example, which the schema already covers. 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 tool's function: generate text embeddings using local models. It distinguishes from siblings like ollama_generate_text and ollama_chat by specifying embedding generation and provides concrete use cases (semantic search, similarity, clustering).

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 gives explicit context on when to use the tool: ideal for batch embedding tasks, semantic search, similarity comparisons, and clustering, and for routine embedding generation to save tokens. It lacks explicit alternatives or exclusions, but the usage context is clear and helpful.

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

ollama_generate_textA

Generate text using local Ollama for SIMPLE, token-efficient tasks like basic content, error messages, placeholder text, boilerplate code, or routine documentation. Use instead of Claude for non-analytical text generation. AVOID for complex reasoning, analysis, or creative writing that requires nuanced understanding.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No	Ollama model name (e.g., gpt-oss, llama3.2, qwen2.5)	gpt-oss
`prompt`	Yes	Text prompt for generation
`max_tokens`	No	Maximum tokens to generate
`temperature`	No	Sampling temperature (0.0-2.0)

TDQS

A4/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 for behavioral disclosure. It discloses that the tool runs locally, is token-efficient, and is not suited for complex reasoning. However, it lacks details on execution behavior such as streaming, latency, error handling, or output format, which would be valuable for an agent.

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 only two sentences, front-loaded with the primary purpose, and each sentence delivers distinct, useful information without redundancy. It is appropriately sized and easy to parse.

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 generation tool with no output schema or annotations, the description covers the core purpose, use cases, and limitations. It could mention the expected return value or explicitly differentiate from ollama_chat, but overall it provides sufficient context for an agent to decide when and how to invoke it.

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 four parameters (prompt, model, max_tokens, temperature). The description adds no parameter-specific meaning beyond what the schema already offers, so the baseline score of 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 tool generates text using local Ollama, specifies the scope (SIMPLE, token-efficient tasks) and provides concrete examples (basic content, error messages, placeholder text, boilerplate code, routine documentation). This specificity differentiates it from broader generation tools and implies its place among the sibling tools.

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

Usage Guidelines4/5

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

Provides explicit when-to-use guidance ('Use instead of Claude for non-analytical text generation') and strong when-not-to-use guidance ('AVOID for complex reasoning, analysis, or creative writing...'). However, it does not explicitly reference sibling tools like ollama_chat or ollama_code_generation as alternatives, leaving some ambiguity within the Ollama tool family.

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

ollama_list_modelsA

List all available Ollama models on the local system

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/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 for behavioral disclosure. It states the operation is a 'List' of models and clarifies 'local system', implying a read-only action, but it does not add additional behavioral context such as return format, potential network calls, or side effects. For a simple list operation, this is adequate but not rich.

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 concise, front-loaded with the action ('List'), and contains no superfluous information. It is highly efficient and easy to parse.

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 list tool with no parameters and no output schema, the description covers the core purpose and scope ('all available models on the local system'). It is complete enough for an agent to understand what the tool does, though it does not explicitly state the return format, which is implied by 'List'. Given the simplicity, this is reasonable completeness.

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?

The tool has zero parameters, and the input schema is an empty object with 100% schema coverage. Since there are no parameters to explain, the description adds no parameter semantics, but the baseline for 0 parameters is 4, and the description does not need to compensate for any missing parameter information.

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 verb 'List' and the resource 'all available Ollama models on the local system', which precisely defines the tool's function. It distinguishes itself from sibling tools (like ollama_generate_text or ollama_pull_model) by specifying it lists models rather than performing generation or pulling.

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 explicit guidance on when to use this tool versus alternatives. It does not mention scenarios like 'Use this before generating to see available models' or any exclusions. The only implication is via the verb 'List', but no concrete usage context is provided.

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

ollama_pull_modelA

Download and install a new model to Ollama

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Model name to pull (e.g., gpt-oss, llama3.2, qwen2.5:14b)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only says 'Download and install,' which essentially restates the tool's name. It does not disclose potential side effects like large downloads, time requirements, network dependence, or idempotency.

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, focused sentence with no wasted words. It conveys the core purpose efficiently.

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?

For a simple one-parameter tool, the description is minimally adequate but lacks important context such as network requirements, storage considerations, and return behavior. Since no annotations or output schema exist, this is a clear gap preventing a higher score.

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 100% with a clear parameter description and examples. The description adds no extra meaning 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 ('Download and install') and the target resource ('a new model to Ollama'), using a specific verb and distinguishing it from siblings like ollama_generate_text or ollama_list_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 context is clear (needed when a new model is required), but no explicit alternatives or exclusions are provided. The tool does not mention when NOT to use it or point to related tools like ollama_list_models.

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

ollama_summariseA

Create BRIEF summaries for logs, documentation, or simple content. Use for factual condensation and routine document processing that doesn't require deep analysis or insight. Ideal for batch summarization tasks to save Claude tokens. AVOID for content requiring interpretation or analytical summarization.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text to summarise
`model`	No		gpt-oss
`length`	No	Summary length preference	medium

TDQS

A3.8/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 for behavioral disclosure. It adds useful capability boundaries (not for interpretation/analytical) and mentions token-saving for batch tasks, but it does not disclose return format, whether an external model call is made, or any other side effects/limitations.

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 compact, front-loaded with the primary action, and every sentence adds distinct value: purpose, use cases, batch/token-saving benefit, and an explicit avoidance warning. No wasteful filler.

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 is adequate for a simple summarization tool, covering purpose, usage, and restrictions. However, it omits model parameter semantics and return/output behavior, which is notable given there is no output schema and no annotations to fill those gaps.

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 covers text and length descriptions, but the 'model' parameter has no schema description and is not mentioned in the tool description. The description's 'BRIEF' emphasis may conflict with the length parameter's default 'medium,' and no guidance is given for choosing among model or length values.

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 opens with 'Create BRIEF summaries for logs, documentation, or simple content,' which clearly states the verb, resource, and scope. It also distinguishes itself from siblings like ollama_generate_text and ollama_chat by emphasizing 'factual condensation' and 'routine document processing.'

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 explicitly says 'Use for factual condensation and routine document processing' and 'AVOID for content requiring interpretation or analytical summarization.' This provides clear when-to-use and when-not-to-use guidance, though it does not name a specific alternative sibling tool for the analytical cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0Aug 1, 2026
- First observedollama_chat
- First observedollama_code_generation
- First observedollama_embed_text
- First observedollama_generate_text
- First observedollama_list_models
- First observedollama_pull_model
- First observedollama_summarise

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-08-01 04:25 across 7 tools

Disambiguation3/5

The four text-generation tools (generate_text, chat, code_generation, summarise) have overlapping purposes and require careful reading of descriptions to distinguish. Embeddings and model management are clearly distinct.

Naming Consistency2/5

Naming mixes verb_noun (generate_text, embed_text, list_models, pull_model), bare verbs (chat, summarise), and noun_noun (code_generation). The British spelling of 'summarise' further breaks consistency.

Tool Count5/5

Seven tools is a well-scoped count for an Ollama integration, covering generation, chat, embeddings, and model management without unnecessary bloat.

Completeness4/5

Core operations are covered (generate, chat, embed, list, pull), but missing model deletion and model info endpoints are minor gaps that agents could work around.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

Related MCP Servers

MCP OpenAI Server
Agent Orchestration Command Line
mzxrai
A
license
B
quality
C
maintenance
A Model Context Protocol (MCP) server that lets you seamlessly use OpenAI's models right from Claude.
Updated 2 years ago (2024-12-06 18:15 UTC)
1
162 npm
76
MIT
LMStudio-MCP
AI & Machine Learning Developer Tools
samscarrow
A
license
Not graded
quality
D
maintenance
A Model Control Protocol (MCP) server that allows Claude to communicate with locally running LLM models via LM Studio.
Updated a year ago (2025-07-07 14:16 UTC)
MIT
ollama-mcp
AI & Machine Learning Developer Tools
KoDiK2005
F
license
Not graded
quality
C
maintenance
MCP server that lets Claude Code offload simple tasks like code explanation, writing tests, and adding comments to a local Ollama model, saving Claude API tokens.
Updated 3 months ago (2026-06-28 21:19 UTC)
-
mcp-local-llm
semenenkod333
A
license
Not graded
quality
C
maintenance
An MCP server that allows Claude Code to offload mechanical tasks such as summarization, classification, and drafting to a local LLM, reducing API costs while keeping Claude in control of complex reasoning and quality review.
Updated 2 months ago (2026-07-17 18:46 UTC)
5 npm
MIT