Skip to main content
Glama
aigo666

MCP Development Framework

by aigo666
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

MCP开发框架

一个强大的MCP（Model Context Protocol）开发框架，用于创建与大语言模型交互的自定义工具。该框架提供了一套完整的工具集，可以轻松地扩展Cursor IDE的功能，实现网页内容获取、文件处理（PDF、Word、Excel、CSV、Markdown）以及AI对话等高级功能。它具有强大的MCP工具扩展能力，使开发者能够快速构建和集成各种自定义工具。

最新版本现在支持在PDF和Word文档处理中，直接返回原始图片内容并进行OCR识别，使大语言模型能够同时理解文档中的文本和图像内容：

  • 图片内容直接显示：文档中的图表、图像等可以直接在对话中显示，无需额外工具

  • OCR文本识别：自动提取图片中的文字内容，支持中英文多语言

  • 图片内容理解：大模型可以"看到"文档中的图片，并基于图片内容进行分析和回答

  • 完整文档内容返回：真正实现文档的全内容理解，包括文本、表格和图像

这使得AI模型能够更全面地理解和分析文档内容，特别是对于包含图表、表单、流程图或其他可视化信息的文档尤为有价值。

主要功能

本框架提供了以下核心功能：

1. 综合文件处理

使用parse_file工具可以自动识别文件类型并选择合适的处理方式，支持PDF、Word、Excel、CSV和Markdown文件。

  • 用法: parse_file /path/to/document

  • 支持格式:

    • PDF文件 (.pdf)

    • Word文档 (.doc, .docx)

    • Excel文件 (.xls, .xlsx, .xlsm)

    • CSV文件 (.csv)

    • Markdown文件 (.md)

  • 参数: file_path - 文件的本地路径

  • 返回: 根据文件类型返回相应的处理结果

2. PDF文档处理

使用parse_pdf工具可以处理PDF文档，支持两种处理模式：

  • 用法: parse_pdf /path/to/document.pdf [mode]

  • 参数:

    • file_path - PDF文件的本地路径

    • mode - 处理模式（可选）：

      • quick - 快速预览模式，仅提取文本内容

      • full - 完整解析模式，提取文本、图片内容和OCR文本（默认）

  • 返回:

    • 快速预览模式：文档的文本内容

    • 完整解析模式：文档的文本内容、原始图片和OCR识别结果

3. Word文档解析

使用parse_word工具可以解析Word文档，提取文本、表格和图片信息。

  • 用法: parse_word /path/to/document.docx

  • 功能: 解析Word文档并提取文本内容、表格和图片

  • 参数: file_path - Word文档的本地路径

  • 返回: 文档的文本内容、表格和原始图片

  • 特点: 同时提供文档内嵌图像的显示和分析功能

4. Excel文件处理

使用parse_excel工具可以解析Excel文件，提供完整的表格数据和结构信息。

  • 用法: parse_excel /path/to/spreadsheet.xlsx

  • 功能: 解析Excel文件的所有工作表

  • 参数: file_path - Excel文件的本地路径

  • 返回:

    • 文件基本信息（文件名、工作表数量）

    • 每个工作表的详细信息：

      • 行数和列数

      • 列名列表

      • 完整的表格数据

  • 特点:

    • 使用pandas和openpyxl提供高质量的表格数据处理

    • 支持多工作表处理

    • 自动处理数据类型转换

5. CSV文件处理

使用parse_csv工具可以解析CSV文件，提供完整的数据分析和预览功能。

  • 用法: parse_csv /path/to/data.csv

  • 功能: 解析CSV文件并提供数据分析

  • 参数:

    • file_path - CSV文件的本地路径

    • encoding - 文件编码格式（可选，默认自动检测）

  • 返回:

    • 文件基本信息（文件名、行数、列数）

    • 列名列表

    • 数据预览（前5行）

    • 描述性统计信息

  • 特点:

    • 自动编码检测

    • 支持多种编码格式（UTF-8、GBK等）

    • 提供数据统计分析

    • 智能数据类型处理

6. Markdown文件解析

使用parse_markdown工具可以解析Markdown文件，提取文本内容、标题结构和列表等信息。

  • 用法: parse_markdown /path/to/document.md

  • 功能: 解析Markdown文件并提取标题结构、列表和文本内容

  • 参数: file_path - Markdown文件的本地路径

  • 返回:

    • 文件基本信息（文件名、大小、修改时间等）

    • 标题结构层级展示

    • 内容元素统计（代码块、列表、链接、图片、表格等）

    • 原始Markdown内容

  • 特点:

    • 自动识别各级标题和结构

    • 智能统计内容元素

    • 完整的标题层级展示

7. 网页内容获取

使用url工具可以获取任何网页的内容。

  • 用法: url https://example.com

  • 参数: url - 要获取内容的网站URL

  • 返回: 网页的文本内容

  • 特点:

    • 完整的HTTP错误处理

    • 超时管理

    • 自动编码处理

8. MaxKB AI对话

使用maxkb工具可以与MaxKB API进行交互，实现智能对话功能。

  • 用法: maxkb "您的问题或指令"

  • 功能: 发送消息到MaxKB API并获取AI回复

  • 参数:

    • message - 要发送的消息内容（必需）

    • re_chat - 是否重新开始对话（可选，默认false）

    • stream - 是否使用流式响应（可选，默认true）

  • 返回: AI的回复内容

  • 特点:

    • 支持流式响应

    • 自动重试机制

    • 完整的错误处理

    • 60秒超时保护

    • 保持连接配置优化

Related MCP server: MCP Toolbox

技术特点

本框架采用了多种技术来优化文件处理性能：

  1. 智能文件类型识别

    • 自动根据文件扩展名选择合适的处理工具

    • 提供统一的文件处理接口

  2. 高效的文档处理

    • PDF处理：支持快速预览和完整解析两种模式

    • Word处理：精确提取文本、表格和图片

    • Excel处理：高效处理大型表格数据

  3. 强大的MCP工具扩展能力

    • 插件化架构设计，易于扩展

    • 统一的工具注册和调用接口

    • 支持同步和异步工具开发

    • 丰富的工具开发API和辅助函数

  4. 内存优化

    • 使用临时文件管理大型文件

    • 自动清理临时资源

    • 分块处理大型文档

  5. 错误处理

    • 完整的异常捕获和处理

    • 详细的错误信息反馈

    • 优雅的失败处理机制

项目结构

本框架采用模块化设计，便于扩展和维护：

mcp_tool/
├── tools/
│   ├── __init__.py        # 定义工具基类和注册器
│   ├── loader.py          # 工具加载器，自动加载所有工具
│   ├── file_tool.py       # 综合文件处理工具
│   ├── pdf_tool.py        # PDF解析工具
│   ├── word_tool.py       # Word文档解析工具
│   ├── excel_tool.py      # Excel文件处理工具
│   ├── csv_tool.py        # CSV文件处理工具
│   ├── markdown_tool.py   # Markdown文件解析工具
│   ├── url_tool.py        # URL工具实现
│   └── maxkb_tool.py      # MaxKB AI对话工具
├── __init__.py
├── __main__.py
└── server.py              # MCP服务器实现

开发指南

如何开发新工具

  1. 在tools目录下创建一个新的Python文件，如your_tool.py

  2. 导入必要的依赖和基类

  3. 创建一个继承自BaseTool的工具类

  4. 使用@ToolRegistry.register装饰器注册工具

  5. 实现工具的execute方法

工具模板示例

import mcp.types as types
from . import BaseTool, ToolRegistry

@ToolRegistry.register
class YourTool(BaseTool):
    """您的工具描述"""
    name = "your_tool_name"  # 工具的唯一标识符
    description = "您的工具描述"  # 工具的描述信息，将显示给用户
    input_schema = {
        "type": "object",
        "required": ["param1"],  # 必需的参数
        "properties": {
            "param1": {
                "type": "string",
                "description": "参数1的描述",
            },
            "param2": {
                "type": "integer",
                "description": "参数2的描述（可选）",
            }
        },
    }
  
    async def execute(self, arguments: dict) -> list[types.TextContent | types.ImageContent | types.EmbeddedResource]:
        """执行工具逻辑"""
        # 参数验证
        if "param1" not in arguments:
            return [types.TextContent(
                type="text",
                text="Error: Missing required argument 'param1'"
            )]
          
        # 获取参数
        param1 = arguments["param1"]
        param2 = arguments.get("param2", 0)  # 获取可选参数，提供默认值
      
        # 执行工具逻辑
        result = f"处理参数: {param1}, {param2}"
      
        # 返回结果
        return [types.TextContent(
            type="text",
            text=result
        )]

部署指南

环境变量配置

在.env文件中配置以下环境变量：

# Server Configuration
MCP_SERVER_PORT=8000        # 服务器端口
MCP_SERVER_HOST=0.0.0.0     # 服务器主机

# 鉴权配置
MCP_AUTH_URL=http://170.106.105.206:4000/users  # 鉴权服务地址

# MaxKB配置
MAXKB_HOST=http://host.docker.internal:8080  # MaxKB API主机地址
MAXKB_CHAT_ID=your_chat_id_here              # MaxKB聊天ID
MAXKB_APPLICATION_ID=your_application_id_here # MaxKB应用ID
MAXKB_AUTHORIZATION=your_authorization_key    # MaxKB授权密钥

# 调试模式
DEBUG=false                 # 是否启用调试模式

# 用户代理
MCP_USER_AGENT="MCP Test Server (github.com/modelcontextprotocol/python-sdk)"

# 本地目录挂载配置
HOST_MOUNT_SOURCE=/path/to/your/local/directory  # 本地目录路径
HOST_MOUNT_TARGET=/host_files                    # 容器内挂载路径

本地目录挂载

框架支持将本地目录挂载到容器中，以便工具可以访问本地文件。配置方法：

  1. 在.env文件中设置HOST_MOUNT_SOURCE和HOST_MOUNT_TARGET环境变量

  2. HOST_MOUNT_SOURCE是你本地机器上的目录路径

  3. HOST_MOUNT_TARGET是容器内的挂载路径（默认为/host_files）

使用工具时，可以直接引用本地文件路径，框架会自动将其转换为容器内的路径。例如：

# 使用PDF工具处理本地文件
pdf "/Users/username/Documents/example.pdf"

# 框架会自动将路径转换为容器内路径
# 例如："/host_files/example.pdf"

这样，你就可以在不修改工具代码的情况下，轻松访问本地文件。

Docker部署（推荐）

  1. 初始设置：

# 克隆仓库
git clone https://github.com/aigo666/mcp-framework.git
cd mcp-framework

# 创建环境文件
cp .env.example .env

  1. 使用Docker Compose：

# 构建并启动
docker compose up --build -d

# 查看日志
docker compose logs -f

# 管理容器
docker compose ps
docker compose pause
docker compose unpause
docker compose down

  1. 访问服务：

  2. Cursor IDE配置：

  • 设置 → 功能 → 添加MCP服务器

  • 类型: "sse"

  • URL: http://localhost:8000/sse?token=<your-token> (替换 <your-token> 为您的 JWT Token)

鉴权配置

SSE 服务现在支持 API 鉴权机制，每个请求都需要携带有效的认证信息：

  1. 配置鉴权服务地址：

    • 在 .env 文件中设置 MCP_AUTH_URL 环境变量（默认为 http://170.106.105.206:4000/users 该鉴权地址仅供测试，不保证长期稳定，建议使用以下项目自行部署）

  2. 客户端配置：

    • 在 Cursor 插件中配置时，需要在 URL 中添加 token 查询参数

    • 格式为 http://your-server:8000/sse?token=<your-token>

    • 服务器会自动将 token 转换为 Bearer <your-token> 格式发送到鉴权服务

  3. 鉴权流程：

    • 当 SSE 服务收到请求时，会从 URL 中提取 token 参数

    • 然后向配置的鉴权地址发送请求，并传递 Authorization: Bearer <your-token> 头

    • 只有鉴权成功（返回 200 状态码）的请求才会被处理

    • 鉴权失败的请求会收到 401 Unauthorized 响应

  4. 推荐JWT鉴权服务：

部署方式

传统Python部署

  1. 安装系统依赖：

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y poppler-utils tesseract-ocr tesseract-ocr-chi-sim

# macOS
brew install poppler tesseract tesseract-lang

# Windows
# 1. 下载并安装Tesseract: https://github.com/UB-Mannheim/tesseract/wiki
# 2. 将Tesseract添加到系统PATH

  1. 安装Python依赖：

# 创建虚拟环境
python -m venv venv
source venv/bin/activate  # Linux/Mac
# 或
.\venv\Scripts\activate  # Windows

# 安装依赖
pip install -r requirements.txt

  1. 启动服务：

python -m mcp_tool

依赖项

主要依赖：

  • mcp: Model Context Protocol实现

  • PyMuPDF: PDF文档处理

  • python-docx: Word文档处理

  • pandas和openpyxl: Excel文件处理

  • httpx: 异步HTTP客户端

  • anyio: 异步I/O支持

  • click: 命令行接口

贡献指南

  1. Fork仓库

  2. 创建功能分支 (git checkout -b feature/amazing-feature)

  3. 提交更改 (git commit -m 'Add some amazing feature')

  4. 推送到分支 (git push origin feature/amazing-feature)

  5. 打开Pull Request

许可证

本项目采用MIT许可证 - 详情请参阅LICENSE文件。

Available Tools

8 tools
maxkbC

请求MaxKB API并返回处理后的结果

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYes要发送的消息内容
re_chatNo是否重新开始对话
streamNo是否使用流式响应

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It only says the tool returns a processed result, but fails to disclose critical behavioral traits such as destructive potential, authentication needs, or effects of parameters like re_chat and stream.

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 short sentence with no wasted words. It is concise but lacks structure; however, for a simple tool, brevity is acceptable.

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?

Given three parameters, no output schema, and no annotations, the description should provide more context about the API call behavior, return format, and expected usage. It does not, making the tool underdocumented 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with all three parameters described in Chinese. The tool description adds no additional meaning beyond the schema, which already explains parameters. Baseline score of 3 is appropriate as schema covers parameter semantics.

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 requests the MaxKB API and returns a processed result, providing a specific verb and resource. However, it does not explain what MaxKB is or how it differs from sibling parsing tools, which limits differentiation.

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 offers no guidance on when to use this tool versus alternatives or when not to use it. It does not mention prerequisites, context, or related tools, leaving the agent to infer usage from the name alone.

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

parse_csvA

解析CSV文件内容，支持各种编码格式

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesCSV文件的本地路径，例如'/path/to/data.csv'
encodingNo文件编码格式，例如'utf-8'、'gbk'等，默认自动检测

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided; the description adds minimal behavioral information (encoding support) but lacks details on error handling, return format, or side effects.

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?

Single, clear sentence with no unnecessary words; appropriately concise for a straightforward tool.

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?

Given low complexity, description is adequate but lacks details on return values, error behavior, and file access requirements; schema covers parameters well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; description does not add meaning beyond the schema's parameter descriptions.

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 it parses CSV files and supports various encodings, distinguishing it from siblings like parse_pdf or parse_excel.

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 on when to use this tool versus alternatives; context is only implied by the tool name and sibling list.

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

parse_excelB

Parses an Excel file and returns its content including all sheets

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the Excel file to parse

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits like read-only nature, file size limits, or format requirements, but it only states the basic output.

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 sentence efficiently conveys the core function with no redundancy.

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?

Given no output schema, the description should elaborate on the returned content format (e.g., as tables or text) and supported Excel versions, but it remains vague.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with file_path already described; the description adds no extra meaning beyond what the schema provides.

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 clear verb 'Parses' and resource 'Excel file', and specifies 'returns its content including all sheets', which distinguishes it from sibling tools like parse_csv and parse_pdf.

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?

No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or limitations.

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

parse_fileC

解析文件内容，支持PDF、Word、Excel、CSV和Markdown格式

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes文件的本地路径，例如'/path/to/document.pdf'

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether parsing is read-only, what output format to expect, any side effects, or error conditions. The agent receives no information beyond the basic action.

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

Conciseness5/5

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

The description is a single sentence that conveys the essential purpose and supported formats without unnecessary words. It is well-structured and front-loaded.

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?

Given the lack of output schema and the presence of sibling tools for individual formats, the description is incomplete. It does not explain return values, error handling, or what makes this tool different from the more specific parsers.

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 schema has 100% coverage for the single parameter, and the description adds the list of supported file formats, which provides context beyond the schema. However, it does not elaborate on file path requirements, supported encodings, or size limits.

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 purpose (parse file content) and lists supported formats (PDF, Word, Excel, CSV, Markdown). However, it does not distinguish itself from sibling tools like parse_pdf or parse_csv, leaving ambiguity about when to use this unified tool versus the specific ones.

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

Usage Guidelines1/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, cases where it should be avoided, or how it relates to sibling parsers.

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

parse_markdownB

解析Markdown文件内容，提取标题结构、列表和文本内容

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesMarkdown文件的本地路径，例如'/path/to/document.md'

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions extraction of content but does not disclose whether the operation is read-only, requires file existence, or how errors are handled. This leaves significant behavioral gaps for a tool with no annotation coverage.

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 concise sentence covering the core action and extracted content. It is front-loaded and efficient, though a bit more structure (e.g., listing extracted elements separately) could improve readability.

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?

Despite the tool's simplicity (one param, no output schema), the description does not specify the return format or structure, which is critical for an agent to interpret results. The absence of output schema makes this omission more impactful.

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 single parameter (file_path) is fully described in the schema (100% coverage). The description adds an example path, which is helpful but does not provide additional meaning beyond the schema description. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states it parses Markdown files and extracts specific elements (title structure, lists, text), making the tool's purpose explicit. It naturally distinguishes from sibling tools like parse_csv or parse_pdf due to the Markdown focus.

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?

No guidance on when to use or avoid this tool versus alternatives is provided. The description only states what it does, leaving the agent to infer applicability without explicit context or exclusions.

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

parse_pdfB

解析PDF文件内容，支持快速预览和完整解析两种模式

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPDF文件的本地路径，例如'/path/to/document.pdf'
modeNo解析模式：'quick'（仅文本）或'full'（文本和图片），默认为'full'full

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It only mentions two parsing modes but omits details like read-only nature, file access permissions, error handling, or side effects. The agent receives insufficient behavioral context.

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 conveys the core purpose and key feature (two modes). No extraneous information, every word earns its place.

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?

Despite the tool having only two simple parameters and no output schema, the description fails to mention what the output looks like or how results are returned. For a parsing tool, this is a significant gap that limits an agent's ability to process results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: both 'file_path' and 'mode' are described in the input schema. The description adds minimal value by paraphrasing the mode parameter's purpose, but it does not clarify file_path beyond 'local path'. With high coverage, a score of 3 is baseline.

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

Purpose5/5

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

The description clearly states the tool's purpose: parsing PDF files, with two modes (quick preview and full parsing). It unambiguously identifies the target resource (PDF) and differentiates from sibling tools that parse other formats like CSV, Excel, etc.

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 implies usage for PDF parsing but does not explicitly specify when to use or not use this tool versus alternatives. No exclusions or context are provided, leaving the agent to infer from the tool name and siblings.

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

parse_wordB

解析Word文档内容，提取文本、表格和图片信息

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesWord文档的本地路径，例如'/path/to/document.docx'

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states extraction of text, tables, and images but does not mention limitations (e.g., .doc vs .docx, formatting preservation, or whether images are saved or returned). This is minimal disclosure.

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, clear sentence with no unnecessary words. It efficiently conveys the tool's purpose and capabilities.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description provides the core functionality. However, it lacks details about the return format or structure, which the agent needs to handle the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description and example for file_path. The description adds minimal extra meaning beyond the schema, meeting the baseline for high coverage.

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

Purpose5/5

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

The description explicitly states the verb 'parse' and the resource 'Word document', and lists the extracted elements (text, tables, images). It clearly distinguishes from sibling tools like parse_pdf or parse_csv.

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?

No guidance is provided on when to use this tool versus alternatives like parse_pdf or parse_markdown. The description lacks context about the appropriate scenarios or prerequisites.

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

urlB

Fetches a website and returns its content

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL to fetch

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must convey behavior. It only states the action without disclosing important details like handling of redirects, timeouts, authentication, or the format of returned content.

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?

Single sentence with no unnecessary words; every part contributes to the purpose.

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?

Given no output schema and the tool's potential for varied responses (e.g., HTML, errors), the description omits critical context about content format, error handling, and limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter clearly described. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.

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

Purpose5/5

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

Description clearly states the tool fetches a website and returns its content, using a specific verb and resource. It distinguishes from sibling tools which are file parsers, not web fetchers.

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?

Description implies the tool is for fetching website content but provides no explicit guidance on when to use it versus alternatives or any exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updates
    • First observedmaxkb
    • First observedparse_csv
    • First observedparse_excel
    • First observedparse_file
    • First observedparse_markdown
    • First observedparse_pdf
    • First observedparse_word
    • First observedurl
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0
Disambiguation3/5

Tools are mostly distinct: specific parsers for file types, but parse_file overlaps with all of them. maxkb and url are separate, causing some ambiguity.

Naming Consistency3/5

Most tools follow 'parse_' prefix, but maxkb and url deviate. Naming is partially consistent but has outliers.

Tool Count3/5

8 tools is a reasonable count, but the server name 'MCP Development Framework' suggests broader scope than just file parsing and URL fetching.

Completeness2/5

The toolkit covers file parsing well, but lacks other development operations (e.g., writing, API management). Gaps make it incomplete for a framework.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Toolbox

    ai-zerolab
    A
    license
    Not graded
    quality
    D
    maintenance
    A comprehensive toolkit that enhances LLM capabilities through the Model Context Protocol, allowing LLMs to interact with external services including command-line operations, file management, Figma integration, and audio processing.
    31
    Apache 2.0
  • Contextual MCP Server by ContextualAI

    Contextual MCP Serverofficial

    ContextualAI
    F
    license
    C
    quality
    D
    maintenance
    A Model Context Protocol server that provides Retrieval-Augmented Generation capabilities using Contextual AI, enabling AI interfaces like Cursor IDE and Claude Desktop to query domain-specific knowledge with context-aware responses and source citations.
    1
    21
    -

Appeared in Searches

Latest Blog Posts

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/aigo666/mcp-framework'

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