Provides a standardized interface for interacting with Ollama's API, supporting model listing, chat functionality, text generation, embedding generation, and querying running models and model details.
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., "@Ollama_MCP_Guidance list available models"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🎯 快速开始： 如果您正在通过 LLM（如 Claude）使用本项目，请首先让 LLM 调用
get_started_guide工具。 这个入门指南将帮助 LLM 全面了解项目，从而为您提供更好的服务。
基于 MCP (Model Context Protocol) 的 Ollama API 交互服务。该项目提供了一个标准化的接口，用于与 Ollama 服务进行交互，并为 LLM 提供智能化的 API 调用指导。
⚠️ 项目状态说明：
这是一个 Cursor MCP Server 项目，目前仅支持在 Cursor 中使用
项目处于开发阶段，尚未实现 Ollama 的所有 API 端点
项目文档和注释采用中英双语，未来将统一为英文（并提供中文文档备份）
✨ 标准化的 JSON 响应格式
🔍 完整的错误处理和状态反馈
📊 详细的性能指标统计
🛠 简单的配置管理
📚 内置的 API 文档导航
Related MCP server: MCP Server Sample
本项目设计为 Cursor IDE 的 MCP 服务
需要在 Cursor 中通过 MCP 协议调用
不提供独立的客户端实现
确保已安装 Python 3.10 或更高版本
安装 Ollama
安装项目：
# 安装 uv（推荐）
curl -LsSf https://astral.sh/uv/install.sh | sh
# 创建并激活虚拟环境
uv venv
source .venv/bin/activate # Linux/macOS
# 或
.venv\Scripts\activate # Windows
# 安装依赖
uv pip install .项目使用 config.json 进行配置，主要配置项包括：
{
"ollama": {
"host": "http://localhost:11434", // Ollama 服务地址
"timeout": 30, // 请求超时时间（秒）
"user_agent": "Ollama_MCP_Guidance/1.0" // 请求标识
},
"api_doc": {
"max_length": 8000, // 文档内容最大长度
"file_path": "ollama-api.md" // API 文档路径
}
}📌 重要提示： 如果您正在与 AI 助手交互，请确保它已经调用了
get_started_guide工具。 这个入门指南包含了完整的使用说明和最佳实践，可以帮助 AI 更好地理解您的需求并提供准确的帮助。
由于 Cursor MCP 需要从默认命令行环境中执行单条命令，建议创建一个自定义运行脚本。创建 ollama-mcp-cli 文件（以下以 macOS/Linux 为例）：
（如果有不理解的地方，请提供信息，让AI来帮助你）
#!/bin/bash
# 虚拟环境配置
# 如果使用 conda，取消下面的注释并修改路径
# CONDA_PATH="你的conda路径/etc/profile.d/conda.sh"
# if [ -f "$CONDA_PATH" ]; then
# source "$CONDA_PATH"
# conda activate 你的环境名称
# fi
# 项目路径配置
PROJECT_PATH="你的项目路径/Ollama_MCP_Guidance"
if [ ! -d "$PROJECT_PATH" ]; then
echo "Error: Project directory not found at $PROJECT_PATH"
exit 1
fi
# 运行程序
cd "$PROJECT_PATH"
source .venv/bin/activate # 激活 uv 虚拟环境
python ollama_mcp_server.py "$@"然后设置脚本权限：
chmod +x ollama-mcp-cli注意：Windows 用户需要创建
ollama-mcp-cli.bat文件，内容相应调整。
启动 Ollama 服务
在 Cursor 的 MCP 配置中，使用以下命令：
/完整路径/ollama-mcp-cli提示：如果将脚本放在系统的可执行文件路径中（如
/usr/local/bin/），则可以直接使用脚本名称：ollama-mcp-cli
⚠️ 本节待修改
查看可用模型：
result = await get_ollama_list()简单对话：
response = await simple_chat(
model="llama2",
prompt="你好，请介绍一下自己"
)生成文本嵌入：
embeddings = await post_generate_embeddings(
model="nomic-embed-text",
text=["这是一段示例文本"]
)端点 | 方法 | 功能介绍 | 特性支持 | 工具名称 |
- | - | 项目入门指南💫 不想读枯燥的表格？让 AI 来帮你！尝试让你的 AI 助手运行 | - 智能项目导航 ✨- 个性化功能推荐 🎯- 最佳实践指导 💡 |
|
| GET | 获取Ollama服务器版本 | - 单次响应 ✅- 包含构建信息 ✅ |
|
| GET | 获取已安装模型列表 | - 完整响应 ✅- 包含模型元数据 ✅ |
|
| GET | 查看运行中的模型 | - 实时状态 ✅- 资源使用数据 ✅ |
|
| POST | 获取模型详细信息 | - 详细模式 ✅- 完整配置信息 ✅ |
|
| POST | 对话式交互功能 | - 流式输出 ❌- 多轮对话 ❌- 系统提示词 ❌- 图像输入 ❌ |
|
| POST | 基础文本生成 | - 流式输出 ❌- 上下文管理 ❌- raw模式 ❌- 模型JSON格式输出 ❌- 工具JSON包装 ✅ |
|
| POST | 生成文本向量表示 | - 批量处理 ✅- 固定维度输出 ✅ |
|
| POST | 生成文本向量表示（已弃用） | - 批量处理 ✅- 固定维度输出 ✅- 已被 |
|
| POST | 创建模型副本 | - 原子操作 ❌- 跨版本复制 ❌ | 未实现（管理员权限） |
| POST | 下载并安装模型 | - 进度反馈 ❌- 断点续传 ❌- 版本管理 ❌ | 未实现（管理员权限） |
| DELETE | 移除指定模型 | - 不可逆操作 ❌- 释放资源 ❌ | 未实现（管理员权限） |
| POST | 创建新模型 | - 模型创建 ❌- 参数配置 ❌ | 未实现（管理员权限） |
| HEAD | 检查blob是否存在 | - 二进制对象检查 ❌- SHA256校验 ❌ | 未实现（管理员权限） |
| POST | 上传blob | - 二进制对象上传 ❌- 大文件支持 ❌ | 未实现（管理员权限） |
基础功能限制
仅支持非流式响应（一次性返回结果）
不支持多轮对话历史
不支持系统提示词（system prompt）
不支持上下文管理
不支持 raw 模式和特定格式输出
管理功能限制
出于安全考虑，不支持以下管理员级别操作：
模型复制（/api/copy）
模型下载（/api/pull）
模型删除（/api/delete）
配置文件中的 API 端点路径请勿随意修改
实验性功能
图片处理功能尚未完全实现和测试，不建议在生产环境使用
部分高级特性（如参数调优、模板定制）尚未实现
Python >= 3.10
httpx >= 0.28.1
mcp[cli] >= 1.3.0
MIT License
💡 友好提示：如果您正在使用这个项目，欢迎通过邮件 (shadowsinger.tp@gmail.com) 告诉我。这不是必须的，但我很乐意知道这个项目对您有帮助！
<目前项目是面向cursor mcp的server项目，没有client，因此仅建议用于cursor mcp> <目前项目是中文项目，注释中包含中文和英文内容，将在未来的某一个版本将注释全部改为英文，并提供中文注释文件备份方便中文用户> <目前项目没有完全实现ollama支持的所有api端点>
<添加对于项目功能和未实现功能的说明： 1.目前项目不支持流式传输 2.目前项目不支持图片处理（尽管有相关代码，但未完全实现并测试） 3.目前项目没有完全实现ollama支持的所有api端点 4.关于实现的功能，请把notes.md最后的表格复制到此readme中进行说明。>
| Name | Required | Description | Default |
|---|---|---|---|
| titles | Yes | ||
| max_length | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available models in the Ollama server.
This tool queries the Ollama API's /api/tags endpoint to retrieve information about
all available models, including both pulled models and their different tags.
Args:
None: This function does not require any parameters.
Returns:
str: JSON-formatted string containing:
- List of available models with their details if successful
- Error details if the request fails or response format is invalid
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden and reveals that it queries /api/tags and returns JSON with model details or error, sufficient for a simple read operation.
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 concise, well-structured with summary, details, and Args/Returns sections, with no unnecessary 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?
Given no annotations and presence of output schema, the description provides complete information about behavior, parameters, and return format for this simple tool.
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?
There are no parameters, and the description explicitly confirms no parameters are needed, adding clear value beyond the empty schema.
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 the specific verb 'list' and identifies the resource as 'all available models in the Ollama server', clearly distinguishing it from siblings like get_ollama_version or get_running_models.
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 states that it lists all available models, implying a general use case, but does not explicitly provide guidance on when to use this tool versus 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.
Get the version information of the Ollama server.
This tool queries the Ollama API's /api/version endpoint to retrieve the server version.
It's useful for checking if the Ollama service is running and verifying its version.
Args:
None: This function does not require any parameters.
Returns:
str: JSON-formatted string containing:
- Version information if successful
- Error details if the request fails
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes endpoint (/api/version), that it returns version info or error details. No annotations provided, so description carries burden. Could mention read-only nature, but implied.
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?
Extremely concise: three short paragraphs with front-loaded summary. No unnecessary 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?
Has output schema, description explains return format (JSON string with version or error). Given simplicity, it's complete. Minor oversight: no mention of potential latency or network errors, but acceptable.
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?
No parameters, schema coverage 100%, description explicitly states no args. Perfectly clear.
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?
Clearly states verb (get) and resource (version information of the Ollama server). Distinguishes from sibling tools which are about listing, generating, or chatting, not version retrieval.
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?
Provides context: 'useful for checking if the Ollama service is running and verifying its version.' No explicit when-not or alternatives, but siblings are clearly different, so sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of currently running Ollama models.
This tool queries the Ollama API's /api/ps endpoint to retrieve information about running models,
similar to the 'ollama ps' command. It validates the response format and provides formatted output.
Args:
None: This function does not require any parameters.
Returns:
str: JSON-formatted string containing:
- List of running models with their details if successful
- Error details if the request fails or response format is invalid
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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. It discloses that it queries an API endpoint, validates the response, and returns a JSON-formatted string or error details. It could be more explicit about being read-only and safe, but overall it is transparent enough.
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 fairly concise with three short paragraphs. It front-loads the purpose and then explains internals and return format. However, some details like 'similar to the ollama ps command' could be seen as slightly redundant, but overall it is well-structured.
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?
Given no annotations, the description provides complete context: input (none), behavior (queries API, validates), and output (JSON string with list or error). With an output schema present, it does not need to detail return fields, but it still provides a useful summary. For a simple read tool, it is fully sufficient.
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 zero parameters, and the description explicitly states 'Args: None: This function does not require any parameters.' Since schema coverage is 100% and the description adds clarity about no inputs, a baseline of 4 is appropriate.
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 it queries the Ollama API's /api/ps endpoint to get the status of currently running models, similar to 'ollama ps'. It distinguishes itself from sibling tools like get_ollama_list (which likely lists all models) by focusing on running models.
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 usage is for checking running models, but does not explicitly state when to use this tool versus alternatives like get_ollama_list or other sibling tools. No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🌟 Getting Started Guide: Your Gateway to the ask-ollama Project
⚠️ AI Assistant Note:
Before proceeding with any operations, it's highly recommended to:
1. Ask the user if they're new to the project
2. Explain that this guide will provide comprehensive understanding
3. Mention that this tool contains essential information for optimal project usage
Why this guide is essential for AI assistants:
1. Provides complete project overview and capabilities
2. Contains special instructions for AI-user interactions
3. Details recommended workflows and best practices
4. Lists all available tools with practical examples
5. Explains current limitations and workarounds
6. Includes API documentation navigation guide
This guide will help you:
- Better understand user requirements
- Make informed tool recommendations
- Navigate API documentation effectively
- Avoid common pitfalls
- Provide more accurate assistance
Remember: Running this guide first will significantly enhance your ability to assist users effectively.
Args:
None: This function does not require any parameters.
Returns:
str: JSON-formatted string containing comprehensive project documentation and usage guidelines.
| 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 for behavioral disclosure. It describes the tool as returning a JSON string with documentation but lacks details on side effects, rate limits, or auth requirements. The tool is clearly read-only, but this is assumed rather than stated.
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 overly verbose with emojis, bullet points, and repetitive phrasing. It front-loads the purpose but then extends with excessive detail in a pushy tone. Every sentence does not earn its place; the guide's content could be summarized more efficiently.
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?
Given the tool's simplicity (no parameters, static documentation), the description covers the purpose, usage, and return format. The output schema exists, so return values are explained. It is complete enough for a guide tool with no complex behavior.
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?
There are no parameters, and schema coverage is 100%. The description explicitly states 'None' and repeats this. The baseline for 0 parameters is 4, and the description adds value by explaining the return format, so a 4 is appropriate.
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 it is a 'Getting Started Guide' for the ask-ollama project, using specific verbs like 'provides', 'contains', and 'lists'. It distinguishes itself from sibling tools like get_api_doc_section by offering a comprehensive overview rather than specific sections.
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 explicitly recommends running this guide before other operations, stating 'Before proceeding with any operations, it's highly recommended to...' and lists steps for user interaction. It does not explicitly mention when not to use it or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate embeddings for the given text using Ollama API.
Args:
model (str): Model name to use for embeddings generation.
Example: "nomic-embed-text"
text (List[str]): List of texts to generate embeddings for.
Example: ["Text 1"] or ["Text 1", "Text 2"]
Returns:
str: JSON-formatted string containing:
- Embeddings data and metadata if successful
- Error details if the request fails or response format is invalid
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| text | 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 full burden. It mentions that it uses the Ollama API, takes a model and text, and returns JSON with success or error. However, it does not disclose whether the operation is read-only or has side effects, nor does it discuss rate limits or authentication. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, and examples. It is fairly concise, though the return format description is slightly verbose. Every sentence serves a purpose.
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?
Given 2 required parameters, no annotations, and an output schema (though not shown), the description covers the essential inputs, expected output format, and error handling. It is complete enough for an AI agent 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 description coverage is 0%, so the description must compensate. It does so excellently: for 'model', it gives a type, example, and format; for 'text', it specifies it is a list of strings with examples. This adds significant meaning beyond the bare schema.
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 'Generate embeddings for the given text using Ollama API.' This is a specific verb-resource pair, and with sibling tools like simple_chat and get_ollama_list, it is clearly distinguishable as the embeddings tool.
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 clear context for using the tool (to generate embeddings) but does not explicitly state when not to use it or mention alternatives. However, the sibling tool names imply distinct purposes, so it's reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show detailed information about a model.
This function retrieves detailed information about the specified model
through the Ollama API's /api/show endpoint.
Args:
model (str): Model name, e.g., "llama2" or "mistral"
Returns:
str: JSON-formatted model information including:
- Basic info (family, parameter size, quantization)
- Technical parameters (context length, layer count)
- Configuration (template, system prompt)
- License and modelfile content
If the request fails, returns error information in JSON format.
| Name | Required | Description | Default |
|---|---|---|---|
| model | 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 full burden. It explains the API endpoint, return format (JSON with specific fields), and error behavior ('fails, returns error information'). It does not cover authentication or rate limits but is adequate for a read-only operation.
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 well-structured with Args and Returns sections. It is front-loaded with the purpose. However, the first sentence slightly restates the title ('Show detailed information about a model'). It is concise but not overly terse.
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?
Given one parameter, no annotations, and the presence of an output schema (implied by return description), the description covers the return format well. It lacks prerequisites (e.g., Ollama must be running) but is largely complete for a simple retrieval tool.
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 0% description coverage, so the description must add value. It explains that the 'model' parameter is a model name with examples ('llama2', 'mistral'), but lacks deeper semantics like format constraints, validation, or list of valid values.
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 verb ('retrieves detailed information') and the resource ('model'), and specifically mentions the API endpoint '/api/show'. It distinguishes from sibling tools like get_ollama_list (which lists models) and simple_chat (which generates responses).
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 usage when needing detailed model info but provides no explicit guidance on when to use vs. alternatives like get_ollama_list or when not to use. Sibling tool names suggest alternatives, but no comparisons or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Basic chat interaction with Ollama models.
This is a simplified chat implementation that provides basic conversation
capabilities without advanced features. For advanced features, please use
complex_chat (not implemented yet).
Limitations:
1. No conversation history (messages array)
2. No streaming support (stream)
3. No system prompts (system role)
4. No image input support (images)
5. No format control (format)
6. No parameter tuning (options)
7. No keep-alive control (keep_alive)
Features:
1. Basic chat: Single message and response
2. Error handling: Connection and format validation
3. Performance metrics: Processing time and token statistics
Args:
model (str): Model name to use, e.g., "llama2", "mistral"
prompt (str): User input text
Returns:
str: JSON-formatted string containing:
- Model response and metadata if successful
- Error details if the request fails or response format is invalid
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| prompt | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: no conversation history, no streaming, no system prompts, etc. Also details error handling and performance metrics. The return format is described as JSON with response or error details.
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 well-structured with sections and bullet points, but slightly verbose (repeats 'Basic chat' in two places). Still, every sentence adds 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?
Given the tool's simplicity (2 params, no nested objects) and the presence of output schema (described in return), the description covers all necessary aspects: purpose, usage, limitations, features, parameters, and return format. No gaps.
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 coverage is 0%, but description adds meaning: for 'model', it gives examples like 'llama2', 'mistral'; for 'prompt', it says 'User input text'. This adds value beyond the schema's purely structural definition.
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 'Basic chat interaction with Ollama models' and distinguishes from 'complex_chat' (though not implemented). The verb 'chat' and resource 'Ollama models' are specific.
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?
Explicitly says when to use (basic chat) and when not (advanced features require complex_chat). Lists limitations. However, does not compare to sibling 'simple_generate', which might be another text generation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Basic text generation with Ollama models.
This is a simplified implementation of the /api/generate endpoint that provides
basic text generation capabilities without advanced features.
Limitations:
1. No streaming support
2. No raw mode
3. No format control
4. No parameter tuning (options)
5. No context management
Features:
1. Basic generation: Single prompt and response
2. Error handling: Connection and format validation
3. Performance metrics: Processing time and token statistics
Args:
model (str): Model name to use, e.g., "llama2", "mistral"
prompt (str): Text prompt for generation
Returns:
str: JSON-formatted string containing:
- Generated text and metadata if successful
- Error details if the request fails
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| prompt | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses limitations (no streaming, no raw mode, etc.), features (basic generation, error handling, performance metrics), and return format. This provides sufficient behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (limitations, features, args, returns) and front-loaded with the core purpose. It is somewhat verbose but each section adds value.
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?
Given the simple tool (2 parameters, output schema exists), the description covers all necessary aspects: purpose, limitations, features, parameter explanations, and return format. It is fully sufficient for an agent to use 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 0% description coverage, but the description includes an 'Args' section that explains each parameter with examples ('llama2', 'mistral'), adding meaning beyond the schema's property names.
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 it is for 'basic text generation with Ollama models' and explicitly lists limitations and features, differentiating it from more advanced endpoints. However, it does not directly contrast with sibling tool 'simple_chat', which may cause ambiguity.
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 usage for simple generation without advanced features like streaming or parameter tuning, but it does not explicitly state when to use this tool versus alternatives like 'simple_chat' or 'post_generate_embeddings'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have clearly distinct purposes: listing models, version, running status, guide, embeddings, model info, chat, and generation. The `get_api_doc_section` tool lacks a description, creating slight ambiguity, and `simple_chat` vs `simple_generate` could be confused but descriptions mitigate this.
Naming mixes prefixes: `get_*` for queries, `post_*` for actions, and `simple_*` for simplified implementations. While all use underscore_case, the inconsistent verb prefix and the `simple_` prefix deviate from a strict verb_noun pattern.
9 tools is well-scoped for an Ollama MCP server focused on guidance and basic interactions. Each tool covers a distinct aspect without unnecessary overlap or excessive quantity.
The tool set covers core operations: listing, version, running status, embeddings, model info, chat, and generation. It lacks model management (pull, delete, create) but that aligns with a guidance focus. The `get_api_doc_section` tool hints at documentation access, enhancing completeness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ShadovvSinger/Ollama_MCP_Guidance'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
