Provides tools backed by local Ollama models for code drafting, summarization and extraction, chunked map-reduce compression of large files, structured JSON extraction, and model listing/prewarming.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agy-ollama-mcp Summarize this diff locally before sending it to the cloud model"
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.
agy)Tiered Edge-Cloud Architecture: High-performance local inference daemon as a zero-cost semantic pre-filter, code drafter, and map-reduce compressor for Google Antigravity CLI.
Google Antigravity CLI (agy) is a terminal-first autonomous coding agent harness designed for deep engineering workflows: repository-wide code exploration, multi-file edits, test execution, and multi-step reasoning.
Because agy-cli routes its primary reasoning loop through cloud-hosted frontier models (such as Gemini 2.0 Flash / Pro), feeding uncurated logs, raw data files, or entire repository ASTs rapidly inflates input/output context. This leads to quota exhaustion, throttling, and latency spikes.
[ Large Context: Dumps / Logs / Drafts ]
│
▼
┌──────────────────────┐
│ Local Pre-Filter │ <-- Fast, Zero Token Cost (Ollama)
│ (Ollama / C++ Eng) │ Summarization, Extraction, AST Pruning
└──────────┬───────────┘
│ (Only high-density signal forwarded)
▼
┌──────────────────────┐
│ agy-cli Core │ <-- Protected Quota, High-Speed Reasoning
│ (Gemini 2.0 / Cloud) │ Strategic Decisions, Code Synthesis
└──────────────────────┘By placing Ollama as a local semantic pre-filter via the open Model Context Protocol (MCP), you offload token-heavy preliminary workloads, saving 70% to 95% of cloud context tokens while accelerating turnaround latency.
Related MCP server: claude-to-agy
flowchart TD
subgraph Antigravity ["Google Antigravity CLI (Cloud Frontier Harness)"]
AGY["agy Core Agent Loop\n(Gemini 2.0 Flash / Pro)"]
CLO_QUOTA["Cloud Quota / Token Budget\n(Protected)"]
end
subgraph MCP_Boundary ["Local Protocol Boundary (STDIO Transport)"]
STDIO["JSON-RPC 2.0 over Stdio"]
SERVER["src/ollama_bridge/server.py\n(FastMCP Server)"]
ISOLATION["Stderr Logging Isolation\nsrc/ollama_bridge/config.py"]
end
subgraph Bridge_Engine ["Deterministic Edge Engine (Python 3.10+)"]
RES["src/ollama_bridge/resolution.py\n4-Tier Precedence Resolver"]
ENG["src/ollama_bridge/engine.py\nChunking, Drafting, Map-Reduce"]
CLI["src/ollama_bridge/client.py\nInventory & Prewarming"]
end
subgraph Hardware_Tier ["Local Accelerated Compute Tier"]
OLLAMA["Ollama Daemon (http://localhost:11434)"]
VRAM["GPU VRAM (keep_alive: -1 pinned)"]
QWEN["qwen2.5-coder:14b"]
DEEPSEEK["deepseek-r1:14b"]
end
AGY -->|"Tools: draft, summarize,\nmap-reduce, extract_json"| STDIO
STDIO --> SERVER
SERVER --> RES
SERVER --> ENG
SERVER --> CLI
SERVER -.->|"Diagnostic Logs (Stderr)"| ISOLATION
RES -->|"Resolved Model"| ENG
ENG -->|"POST /api/generate"| OLLAMA
CLI -->|"GET /api/tags\nPOST /api/generate"| OLLAMA
OLLAMA --> VRAM
VRAM --> QWEN
VRAM --> DEEPSEEK
OLLAMA -->|"Fast Local Output (0 tokens billed)"| ENG
ENG -->|"Clean JSON / Brief Result"| SERVER
SERVER -->|"JSON-RPC Response"| STDIO
STDIO --> AGY
AGY -.->|"Only Curated Insights Fed"| CLO_QUOTAThe bridge daemon registers 7 specialized Model Context Protocol tools:
Tool Name | Parameters | Purpose & Rationale |
| Drafts code implementations, boilerplate, and scaffolding locally without burning cloud tokens. | |
| Strips noise, boilerplate, and repetitive lines from logs or text into a high-density technical summary. | |
| In-memory line-aware chunk partitioning and tree-synthesis map-reduce for texts exceeding single-pass limits. | |
| File-direct sliding-window map-reduce. Streams multi-megabyte files directly from disk, runs concurrent worker map distillation with | |
| Extracts strict structured JSON conforming to a specified schema at low temperature ( | |
(none) | Queries | |
| Sends |
Add the bridge to your Antigravity configuration at ~/.gemini/config/mcp_config.json:
{
"mcpServers": {
"local-ollama": {
"command": "python3",
"args": [
"/home/leifdavisson/.local/bin/ollama_mcp_bridge.py"
],
"env": {
"LOCAL_LLM_MODEL": "qwen2.5-coder:14b",
"OLLAMA_HOST": "http://localhost:11434"
}
}
}
}The project installs two complementary slash commands for agy-cli:
/local-draft (Open SKILL.md (file:///home/leifdavisson/.gemini/config/skills/local-draft/SKILL.md)):
Forces AST parsing, code scaffolding, or boilerplate generation onto local Ollama models.
/local-draft Create a Pydantic V2 schema for our customer ingestion webhook/reduce (Open SKILL.md (file:///home/leifdavisson/.gemini/config/skills/reduce/SKILL.md)):
Performs file-direct chunked map-reduce on massive files (>300 lines) before ingesting into context.
/reduce /var/log/syslog.log "Identify database connection timeouts and trace IDs"chunk_reduce.py)Run the map-reduce pipeline directly from your shell or pipe from stdin:
# File direct execution:
chunk_reduce.py -f /var/log/syslog.log -g "Find failed SSH logins" -j 4
# Piped execution:
cat massive_output.txt | chunk_reduce.py -g "Extract unhandled exceptions"The codebase is governed by formal INCOSE requirements and verified according to DO-178C Level A High-Assurance verification criteria:
Metric | Required Standard | Achieved Result |
Requirements Verified | 100% (9 / 9) | 100% (9 / 9) |
Uncovered Requirements | 0 | 0 |
Orphaned Tests | 0 | 0 |
Total Test Suite | >= 80 | 139 Passed (135 AST Mapped) |
Statement Coverage | 100.0% | 100.0% (366 / 366 statements) |
Branch Coverage | 100.0% | 100.0% (92 / 92 branches) |
DO-178C Level A MC/DC | 100.0% | 100.0% Verified Pairs |
Mutation Kill Score | >= 90.0% | 91.0% (mutmut) |
Strict Static Typing | 0 errors | 0 errors ( |
Protocol Isolation | Pure JSON-RPC | Zero stdout pollution (stderr isolated) |
Detailed audit documentation and artifacts:
Open VERIFICATION_REPORT.md (file:///data/agy_ollama_mcp/VERIFICATION_REPORT.md)
Open RTM_MATRIX.json (file:///data/agy_ollama_mcp/RTM_MATRIX.json)
Open requirements.json (file:///data/agy_ollama_mcp/requirements.json)
Open features/ (file:///data/agy_ollama_mcp/features/)
Python 3.10+
Ollama running locally (http://localhost:11434)
Recommended local models: qwen2.5-coder:14b or deepseek-r1:14b
# 1. Clone repository
git clone https://github.com/leifdavisson/agy-ollama-mcp.git
cd agy-ollama-mcp
# 2. Install package in editable mode
pip install -e .
pip install -r requirements-dev.txt
# 3. Pull recommended local models in Ollama
ollama pull qwen2.5-coder:14b
ollama pull deepseek-r1:14b
# 4. Verify local installation
pytest --cov=src --cov-branch --cov-fail-under=100 tests/
python3 scripts/verify_mcdc.py
python3 scripts/generate_rtm.pyVariable | Default | Description |
|
| Endpoint of the local Ollama daemon. |
| Auto-detected | Preferred model override (e.g. |
|
| Request timeout in seconds for generation tasks. |
|
| Context window size allocated in local model memory. |
|
| Sampling temperature for code generation. |
|
| Set to |
This project is built atop the open-source AI and developer tooling ecosystem. Direct backlinks to official project documentation, homepages, and repositories:
Ollama: Official Runtime Daemon (GitHub Repository)
Model Context Protocol (MCP): Standard Specification (GitHub Organization)
Qwen2.5-Coder: Specialized Code Intelligence Model (Ollama Card)
DeepSeek-R1: Reasoning and Verification Model (Ollama Card)
llama.cpp: Pure C/C++ Inference Engine
Google Antigravity CLI (agy): Autonomous Terminal Coding Harness (Open antigravity-guide (file:///home/leifdavisson/.gemini/config/skills/antigravity-guide/SKILL.md))
This project is licensed under the GNU Affero General Public License v3.0 (GNU AGPLv3). See LICENSE (Open LICENSE (file:///data/agy_ollama_mcp/LICENSE)) for full legal terms.
Map-reduce chunked summarization for massive files or logs that exceed single context limits.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| content | Yes | ||
| chunk_chars | No | ||
| extraction_goal | No | Extract key technical points, errors, and relevant logic |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Generate initial code drafts, boilerplate, unit tests, or scaffolding locally via Ollama without consuming cloud tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| context | No | ||
| language | No | ||
| task_description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Extract structured JSON from unstructured text, logs, or documentation according to a target schema description.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| content | Yes | ||
| schema_description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List all models currently installed and available in the local Ollama instance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Compress large files, traces, or logs using local Ollama Map-Reduce before ingesting into context.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| overlap | No | ||
| file_path | Yes | ||
| chunk_size | No | ||
| concurrency | No | ||
| extraction_goal | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Pre-warm a local model into memory/VRAM with keep_alive=-1 so subsequent calls have zero cold-start delay.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Compress massive files, logs, terminal traces, or documentation into high-density summaries before cloud reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| content | Yes | ||
| extraction_goal | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0local_chunked_summarylocal_draft_codelocal_extract_jsonlocal_list_modelslocal_map_reduce_filelocal_prewarm_modellocal_summarize_and_extractThe 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
MCP-Native LLM Orchestration Agent
Multiple MCP tools, persistent graph memory, token-saving data pointers, and more.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
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
