agy-ollama-mcp

by leifdavisson

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
The tools have significant overlap: local_summarize_and_extract, local_chunked_summary, and local_map_reduce_file all perform summarization/compression with only subtle differences. This can confuse an agent about which to use. Other tools are clearer, but the redundant trio lowers the score.
Naming Consistency3/5
All tools use a 'local_' prefix and snake_case, which is consistent, but the names are not fully uniform: 'summarize_and_extract' combines two actions while others use a single verb, and 'chunked_summary' vs 'map_reduce_file' are stylistic variations. The patterns are mostly consistent but not perfectly aligned.
Tool Count5/5
Seven tools is a reasonable, well-scoped number for a local Ollama helper. It covers core operations without being overwhelming, fitting comfortably within the typical 3-15 range.
Completeness4/5
The tools cover the main capabilities (code generation, summarization, extraction, model management, prewarming) well. However, the presence of three overlapping summarization tools suggests redundancy rather than a missing feature; the domain appears largely covered, with minor gaps like model downloading or inference not being addressed.
Average 3.4/5 across 7 of 7 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states a high-level compression goal and does not disclose whether content stays local, how model selection works, how chunking or size limits behave, or what the extraction_goal drives. This is under-disclosed for a data-processing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, and the content-type list plus 'before cloud reasoning' are both useful context. It is concise, though perhaps lean for a tool with this much schema ambiguity.
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?
With no annotations, 0% schema coverage, and three parameters, the description needed to provide far more operational and parameter context. It gives only a purpose sentence, leaving sibling selection, parameter semantics, and processing behavior essentially uncovered; the output schema only relieves return-value documentation.
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 0%, so the description must compensate for the three parameters. It only implies that content holds large files/logs/traces/documentation; it does not explain extraction_goal or model, and their required semantics are left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb ('compress') and target resources ('massive files, logs, terminal traces, or documentation') and identifies the output as 'high-density summaries'. However, it omits the extraction half implied by the tool name and the required extraction_goal, and it does not distinguish the tool from local_chunked_summary or local_extract_json.
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 phrase 'before cloud reasoning' gives implied context for when to use this tool as a local preprocessing step. But it gives no explicit guidance on when to prefer this over siblings like local_extract_json or local_chunked_summary, and 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and the description gives no indication of side effects, permissions, or read-only status. It doesn't mention whether the tool modifies anything or requires special access, so the behavior is opaque.
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 that packs the essential information without redundancy. It is well-structured and immediately understandable.
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?
The description lacks details about the output format, error behavior, or any constraints. While the core purpose is clear, the absence of output schema or behavioral notes leaves significant gaps for an agent trying to use the tool correctly.
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?
The schema has no descriptions, and the tool description does not explain the parameters. While names like 'content' and 'chunk_chars' are somewhat self-explanatory, the default values and extraction_goal are not clarified. This is a low score given zero schema coverage.
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 function: map-reduce chunked summarization for large files/logs. It identifies the resource (content) and the action (summarize), making the purpose distinct even without explicit sibling comparison.
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 provides a usage condition ('exceed single context limits') which guides when to use the tool. However, it does not explicitly contrast with sibling tools like local_summarize_and_extract or local_map_reduce_file, leaving some ambiguity about when this is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the local Ollama dependency and map-reduce approach, but it does not mention runtime expectations, side effects, file modification behavior, return format, failure modes, or resource requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler; the action and resource appear immediately. It is structurally efficient, though its brevity contributes to the lack of operational detail.
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?
The tool has six parameters, no schema descriptions, and no annotations, yet the description is only one sentence. Prerequisites, parameter semantics, output behavior, and relationship to sibling tools are left unexplained, so the definition is not complete enough for reliable invocation.
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 description names none of the six parameters. An agent cannot infer the meaning of file_path, extraction_goal, model, chunk_size, overlap, or concurrency from the text, so the description does not compensate for the schema gap.
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 names a specific action (compress), specific target resources (large files, traces, logs), a distinguishing method (local Ollama Map-Reduce), and its intended purpose (before ingesting into context). This differentiates it from sibling summarization/extraction tools by the map-reduce mechanism and pre-ingestion use case.
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 clearly situates usage: apply this when dealing with large files, traces, or logs that need compression before context ingestion, using local Ollama. It does not explicitly name alternatives or exclusion criteria, but the 'before ingesting into context' framing and large-file focus provide practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the core behavior—extracting JSON—and implies a read-only operation, but it does not describe error handling, validation behavior, or how the optional model parameter affects execution. Since no annotations are present, the description carries the burden but only partially fulfills it.
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 redundant or irrelevant content. It conveys the essential purpose without wasting words.
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?
The description omits important context such as the output format details, the role of the model parameter, and how to choose this tool over similar siblings. An agent would need additional information to use the tool effectively in all relevant scenarios.
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?
The description implicitly maps 'content' to 'unstructured text' and 'schema_description' to 'target schema description', but the 'model' parameter is completely unexplained. With zero structured schema coverage, the description does not sufficiently compensate by clarifying all parameter roles and expected formats.
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 a specific action ('Extract structured JSON'), the input type ('unstructured text, logs, or documentation'), and the guiding constraint ('according to a target schema description'). This is sufficient for an agent to understand the tool's primary function.
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 does not provide explicit guidance on when to use this tool versus overlapping sibling tools like local_summarize_and_extract or local_chunked_summary. It implies usage when a schema is available, but does not state conditions, alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose a meaningful behavioral trait: generation happens locally via Ollama and does not consume cloud tokens. However, it does not clarify whether the output is returned as text, written to files, or what happens if Ollama is unavailable, leaving important behavioral details unspecified.
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 concise sentence that front-loads the core action and scope, then adds the key differentiator about local Ollama and cloud-token savings. Every word earns its place and there is no redundant information.
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 essential call can be inferred: provide a task description and optionally model, context, or language. The presence of an output schema reduces the need to describe return values. However, optional parameter semantics and tool-selection boundaries are left unclear, so the description is adequate but not fully complete.
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 0%, so the description must compensate by explaining parameter meanings. It does not mention task_description, model, context, or language, and provides no format or usage hints for any of them. The tool-level description allows minimal inference about task_description and language, but not enough to document the parameters properly.
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 ('Generate') with a clear resource scope: code drafts, boilerplate, unit tests, and scaffolding. It further distinguishes the tool by specifying local Ollama execution and the benefit of not consuming cloud tokens, making it clearly distinct from sibling summarization/extraction tools.
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 phrase 'locally via Ollama without consuming cloud tokens' implies when this tool is appropriate, namely for token-conscious local drafting. However, there is no explicit when-not-to-use guidance or direct comparison to sibling tools, so usage guidance remains mostly implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'List' clearly implies a read-only operation with no side effects, and the scope is limited to local models. It does not mention error cases or performance characteristics, but for a simple list operation this is sufficient.
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, tight sentence that conveys all necessary information without any fluff. It is front-loaded with the verb and object, making it highly readable and scannable.
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 description is complete for a simple, parameterless list operation. It does not specify the output format (e.g., list of names or details), but this is not essential for understanding the tool's purpose and typical usage. The local scope is clearly stated.
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 tool has no parameters, and the schema coverage is 100% (vacuously). The description adds no parameter information, but since there are none, the baseline of 3 applies. No gaps exist.
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 a specific verb ('List'), a specific resource ('models'), and a clear scope ('local Ollama instance'). It distinguishes itself from the sibling tools that perform other local operations.
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?
No explicit guidance is given for when to use this tool versus alternatives. However, the simplicity of the operation and lack of obvious alternatives make the usage context implicit. A more explicit mention of when to prefer this over other listing or query tools would have been clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It reveals that the model is loaded into memory/VRAM, persistence is set via keep_alive=-1, and the intended effect is eliminating cold-start delay. It does not mention resource consumption or response behavior, but the core behavioral profile is transparent.
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?
A single dense sentence front-loads the action and mechanism with no filler. Every clause contributes meaningful information.
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 single-parameter tool with an output schema present, the description is mostly complete. The main gap is not explicitly directing the agent to provide the model name or consult local_list_models for available models.
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 0% and the description never references the 'model' parameter. The parameter name is inferable from the tool name, but no guidance is given on valid model identifiers or the need to supply an already-available local model.
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 ('Pre-warm') naming the exact resource ('local model') and the mechanism ('keep_alive=-1'). It clearly communicates the tool's function and distinguishes it from sibling generation/extraction 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?
The description implies when to use it: before subsequent calls needing zero cold-start delay. It does not explicitly name alternatives or exclusion cases, but the intended context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agy-ollama-mcp MCP server](https://glama.ai/mcp/servers/leifdavisson/agy-ollama-mcp/badges/card.svg)](https://glama.ai/mcp/servers/leifdavisson/agy-ollama-mcp)

Score Badge

Copy to your README.md:

[![agy-ollama-mcp MCP server](https://glama.ai/mcp/servers/leifdavisson/agy-ollama-mcp/badges/score.svg)](https://glama.ai/mcp/servers/leifdavisson/agy-ollama-mcp)

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

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