MCP server for integrating Claude with local Ollama models
claude-sidekick provides 5 tools for local Ollama integration with explicit schemas and descriptions. Naming follows verb_noun patterns (ollama_generate_text, ollama_chat, etc.), which is clear. Descriptions are substantial (150-250 chars) and include explicit guidance on WHEN to use each tool vs Claude, a strength for LLM selection. However, schemas are incomplete: parameters lack type information for some fields (e.g., 'model' has type string but no enum constraint despite the description listing specific model names); output schemas are not documented at all; error handling and recovery guidance are minimal; and the 5 tools show some redundancy (ollama_generate_text vs ollama_chat both do text generation with overlapping capabilities). Parameter descriptions are present but lack detail on ranges, constraints, and format expectations. The server demonstrates good effort on description quality but falls short on schema rigor and output documentation, typical of community MCP servers.
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.
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.
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.
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.
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.
Output schemas not documented. Tools return strings but LLMs need to know the structure of responses (what fields, what types, what to expect next). Without documented output schemas, agents cannot plan downstream calls or extract data reliably.
Model parameter lacks enum constraint. Description lists examples ('gpt-oss, llama3.2, qwen2.5') but parameter schema has type 'string' with no enum. This invites hallucinated model names. Should declare enum: ['gpt-oss', 'llama3.2', 'qwen2.5', 'deepseek-coder'] to let LLMs pick from valid options.
Numeric parameter constraints missing. temperature range (0.0-2.0) and max_tokens default (2048) are stated in descriptions but not in schema. Should declare minimum, maximum, and default in the schema so LLMs and clients enforce bounds programmatically.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 16 | - | v1 |
No error handling or recovery guidance. Code catches errors with generic messages like 'Ollama generation failed' but does not tell the LLM what to do next (retry, check Ollama service, call a different tool). Agents need actionable error guidance.
Functional overlap between ollama_generate_text and ollama_chat. Both accept a model parameter and generate text; ollama_chat takes messages array, ollama_generate_text takes a prompt string. For simple single-turn queries, an LLM cannot easily choose between them. Consider consolidating into a single 'ollama_generate' tool with a mode parameter or clearer WHEN guidance.
Messages parameter in ollama_chat lacks item schema validation. Declares items as 'object' with properties but does not enforce required fields (role, content) at the schema level. Should include 'required: ["role", "content"]' in the items definition.