FullScope-MCP
FullScope-MCP is a versatile server designed for content processing and summarization tasks, offering:
🤖 Model Calls: Query large language models directly
🌐 Web Scraping: Extract webpage content with option to save as text
📝 Content Summarization: Summarize text to specified length (default 20%)
🔗 Webpage Summarization: Fetch and summarize webpage content
📄 Text File Summarization: Process .txt files (limited to 2k characters)
📚 PDF File Summarization: Extract and summarize PDF content (limited to 2k characters)
🎯 Topic-Based Summary: Generate targeted summaries based on specific queries (RAG-like functionality)
Includes author information with NPM profile (@langgpt) for package distribution
Utilizes OpenAI API format for model interactions, with configuration options for API key, base URL, and model selection
Supports distribution through PyPI, with detailed instructions for building, testing, and publishing the package
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., "@FullScope-MCPsummarize this webpage for me: https://example.com/long-article"
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.
FullScope-MCP
内容总结运营 MCP Server,支持网页抓取、文件读取、内容总结、主题汇总等功能
🌟 功能特性
FullScope-MCP 是一个功能全面的 Model Context Protocol (MCP) 服务器,专门用于内容总结和运营场景。支持以下核心功能:
🤖 模型调用: 直接调用大语言模型进行回答
🌐 网页抓取: 抓取网页内容,可选保存为 txt 文本文件
📝 内容总结: 将任意内容总结为指定长度(默认原来的 20%,脱水版)
🔗 网页总结: 获取网页内容并自动总结为精炼版本
📄 文本文件总结: 读取 txt 等格式的文本文件并总结内容(限制返回 2k 字符)
📚 PDF 文件总结: 读取 PDF 文件并总结文本内容(限制返回 2k 字符)
🎯 主题汇总: 类似 RAG 功能,给定资料内容和查询主题,返回最相关的内容总结(2k 字符内)
Related MCP server: MCP Web Tools Server
📦 安装
使用 uvx 安装(推荐)
uvx fullscope-mcp-server使用 pip 安装
pip install fullscope-mcp-server从源码安装
git clone https://github.com/yzfly/fullscope-mcp
cd fullscope-mcp
pip install -e .⚙️ 配置
环境变量配置
在使用之前,需要配置以下环境变量:
必需配置
# MiniMax API Key(必需)
export OPENAI_API_KEY="your-minimax-api-key"可选配置
# API 基础 URL(默认使用 MiniMax)
export OPENAI_BASE_URL="https://api.minimaxi.com/v1"
# 使用的模型(默认 MiniMax-M1)
export OPENAI_MODEL="MiniMax-M1"
# 输入上下文最大 token 数(默认 120000)
export MAX_INPUT_TOKENS="120000"
# 输出上下文最大 token 数(默认 8000)
export MAX_OUTPUT_TOKENS="8000"Claude Desktop 配置
在 Claude Desktop 中使用时,请添加以下配置到 claude_desktop_config.json:
{
"mcpServers": {
"fullscope-mcp": {
"command": "uvx",
"args": ["fullscope-mcp-server"],
"env": {
"OPENAI_API_KEY": "your-minimax-api-key-here",
"OPENAI_BASE_URL": "https://api.minimaxi.com/v1",
"OPENAI_MODEL": "MiniMax-M1",
"MAX_INPUT_TOKENS": "900000",
"MAX_OUTPUT_TOKENS": "8000"
}
}
}
}或者使用 pip 安装版本:
{
"mcpServers": {
"fullscope-mcp": {
"command": "python",
"args": ["-m", "fullscope_mcp_server"],
"env": {
"OPENAI_API_KEY": "your-minimax-api-key-here",
"OPENAI_BASE_URL": "https://api.minimaxi.com/v1",
"OPENAI_MODEL": "MiniMax-M1",
"MAX_INPUT_TOKENS": "900000",
"MAX_OUTPUT_TOKENS": "8000"
}
}
}
}🚀 使用方法
1. 模型调用
# 工具名: call_model
# 参数: prompt (str) - 要发送给模型的提示词
# 返回: 模型的回答2. 网页抓取
# 工具名: scrape_webpage
# 参数:
# - url (str) - 要抓取的网页URL
# - save_to_file (bool) - 是否保存内容到txt文件
# 返回: 抓取结果和文件路径(如果保存)3. 内容总结
# 工具名: summarize_content
# 参数:
# - content (str) - 要总结的内容
# - target_ratio (float) - 目标压缩比例,0.1-1.0之间,默认0.2
# 返回: 总结后的内容4. 网页总结
# 工具名: summarize_webpage
# 参数:
# - url (str) - 要抓取和总结的网页URL
# - target_ratio (float) - 目标压缩比例,默认0.2
# 返回: 网页内容总结5. 文本文件总结
# 工具名: read_and_summarize_text_file
# 参数:
# - filepath (str) - 文本文件路径
# - target_ratio (float) - 目标压缩比例,默认0.2
# 返回: 文件内容总结6. PDF文件总结
# 工具名: read_and_summarize_pdf_file
# 参数:
# - filepath (str) - PDF文件路径
# - target_ratio (float) - 目标压缩比例,默认0.2
# 返回: PDF内容总结7. 主题汇总
# 工具名: topic_based_summary
# 参数:
# - content (str) - 资料内容
# - query (str) - 查询的主题或问题
# 返回: 基于主题的相关内容总结(2k字符内)📖 使用示例
在 Claude Desktop 中使用
网页内容总结
请帮我总结这个网页的内容:https://example.com/article文档总结
请读取并总结这个PDF文件:/path/to/document.pdf主题分析
基于这段资料内容,帮我分析"人工智能发展趋势"相关的信息
直接运行服务器
# 设置环境变量
export OPENAI_API_KEY="your-api-key"
# 运行服务器
python fullscope_mcp_server.py🔧 开发指南
项目结构
fullscope-mcp/
├── src/
│ └── fullscope_mcp_server/
│ ├── __init__.py
│ └── server.py
├── README.md
├── pyproject.toml
└── LICENSE本地开发
# 克隆项目
git clone https://github.com/yzfly/fullscope-mcp
cd fullscope-mcp
# 创建虚拟环境
python -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
# 安装开发依赖
pip install -e ".[dev]"
# 运行测试
pytest代码格式化
# 格式化代码
black src/
isort src/
# 类型检查
mypy src/🌐 支持的模型
本服务器主要针对 MiniMax API 设计,但通过配置 OPENAI_BASE_URL 和相关参数,也可以支持其他兼容 OpenAI API 格式的模型服务:
MiniMax-M1 (默认推荐)
MiniMax-Text-01
其他支持 OpenAI API 格式的服务
MiniMax API 配置说明
MiniMax API 支持最大 1,000,192 tokens 的上下文长度,非常适合处理长文档和大量内容的总结任务。
获取 API Key: MiniMax 开放平台
API 文档: MiniMax API 文档
🚀 发布到 PyPI 的步骤
1. 准备发布
# 安装构建工具
pip install build twine
# 构建包
python -m build
# 检查包
twine check dist/*2. 发布到 TestPyPI (测试)
# 上传到 TestPyPI
twine upload --repository testpypi dist/*
# 从 TestPyPI 安装测试
pip install --index-url https://test.pypi.org/simple/ fullscope-mcp-server3. 发布到正式 PyPI
# 上传到 PyPI
twine upload dist/*📝 更新日志
v1.0.0 (2024-12-19)
✨ 首次发布
🌐 支持网页抓取和保存
📝 支持内容总结(可配置压缩比例)
📄 支持文本文件和PDF文件读取总结
🎯 支持主题汇总(RAG功能)
🤖 支持直接模型调用
⚙️ 完善的环境变量配置
📦 支持 uvx 和 pip 安装
🤝 贡献
欢迎提交 Issue 和 Pull Request!
Fork 本项目
创建功能分支 (
git checkout -b feature/AmazingFeature)提交更改 (
git commit -m 'Add some AmazingFeature')推送到分支 (
git push origin feature/AmazingFeature)开启 Pull Request
📄 许可证
本项目采用 MIT 许可证 - 查看 LICENSE 文件了解详情。
👨💻 作者
yzfly
GitHub: @yzfly
Email: yz.liu.me@gmail.com
微信公众号: 云中江树
NPM: @langgpt
🙏 致谢
Model Context Protocol - 协议标准
MiniMax API - AI 模型服务
Beautiful Soup - HTML 解析
PyPDF2 - PDF 处理
❓ 常见问题
Q: 如何获取 MiniMax API Key?
A: 访问 MiniMax 开放平台,注册账号后在账户管理-接口密钥中获取。
Q: 可以使用其他模型吗?
A: 可以!通过配置 OPENAI_BASE_URL 和 OPENAI_MODEL 环境变量,可以使用任何兼容 OpenAI API 格式的模型服务。
Q: 文件大小有限制吗?
A: 是的,为了性能考虑:
文本文件和PDF文件内容限制在约 120k 字符以内
网页内容会根据模型的上下文限制自动截断
主题汇总结果限制在 2k 字符以内
Q: 如何在 Claude Desktop 中使用?
A: 按照上面的配置说明,将配置添加到 claude_desktop_config.json 文件中,重启 Claude Desktop 即可。
如果你觉得这个项目有用,请给个 ⭐ 星!
Available Tools
7 toolscall_modelC
调用模型进行回答
Args:
prompt: 要发送给模型的提示词
Returns:
模型的回答
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool '调用模型进行回答' (calls a model for answering) but doesn't specify what model is used, whether there are rate limits, authentication requirements, response formats beyond '模型的回答' (model's answer), or any error conditions. This leaves critical behavioral aspects undocumented.
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 appropriately concise with a clear structure: a brief purpose statement followed by Args and Returns sections. However, the purpose statement is overly vague, and the parameter documentation is minimal, which slightly reduces its effectiveness despite the efficient format.
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 (1 parameter, no annotations, but with an output schema), the description is minimally complete. The output schema likely covers return values, reducing the need for detailed output explanation. However, for a model-calling tool, more context about the model type, capabilities, or limitations would be beneficial to fully understand its use.
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 adds minimal value beyond the input schema. It states 'prompt: 要发送给模型的提示词' (prompt: the prompt to send to the model), which slightly clarifies the parameter's purpose but doesn't provide format requirements, length constraints, or examples. With 0% schema description coverage and only 1 parameter, this is adequate but leaves room for improvement.
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 '调用模型进行回答' (call model for answering) is a tautology that essentially restates the tool name 'call_model' without providing specific details about what kind of model is being called or what type of answers it produces. While it mentions '回答' (answers), it doesn't distinguish this tool from sibling tools like 'summarize_content' or 'topic_based_summary' that also involve model processing.
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 guidance is provided about when to use this tool versus alternatives. The description doesn't mention any specific context, prerequisites, or exclusions. Given sibling tools like 'summarize_content' and 'topic_based_summary' that appear to serve similar purposes, the lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_and_summarize_pdf_fileB
读取PDF文件并总结内容(限制2k字符)
Args:
filepath: PDF文件路径
target_ratio: 目标压缩比例,0.1-1.0之间
Returns:
PDF内容总结
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | ||
| target_ratio | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 a character limit ('限制2k字符') which is useful behavioral context, but doesn't disclose other important traits like error handling, performance characteristics, authentication needs, or rate limits. For a file-reading tool with no annotations, this leaves significant gaps.
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 efficiently structured with a clear purpose statement, parameter explanations, and return value indication. Every sentence serves a purpose, though the formatting with 'Args:' and 'Returns:' sections could be more integrated into natural language flow.
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 has an output schema (though not shown), the description doesn't need to detail return values. However, for a file-processing tool with no annotations and 2 parameters, it should provide more behavioral context about file access permissions, supported PDF formats, or error conditions. The character limit hint is helpful but insufficient for full completeness.
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?
With 0% schema description coverage, the description must compensate, and it does by explaining both parameters: 'filepath: PDF文件路径' (PDF file path) and 'target_ratio: 目标压缩比例,0.1-1.0之间' (target compression ratio between 0.1-1.0). This adds meaningful context beyond the bare schema, though it doesn't explain how the ratio affects summarization quality or length.
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 purpose: '读取PDF文件并总结内容' (read PDF file and summarize content). It specifies the resource (PDF files) and verb (read and summarize), but doesn't explicitly differentiate from sibling tools like 'read_and_summarize_text_file' or 'summarize_content', which handle similar operations on different inputs.
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 no guidance on when to use this tool versus alternatives. With sibling tools like 'read_and_summarize_text_file', 'summarize_content', and 'summarize_webpage' available, there's no indication of when PDF-specific summarization is preferred over general content summarization tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_and_summarize_text_fileC
读取txt等格式的文本文件并总结内容(限制2k字符)
Args:
filepath: 文本文件路径
target_ratio: 目标压缩比例,0.1-1.0之间
Returns:
文件内容总结
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | ||
| target_ratio | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the character limit constraint and that it returns a summary, but lacks critical behavioral details: whether it handles large files, what happens with unsupported formats, error conditions, performance characteristics, or authentication requirements. For a file-reading tool with zero annotation coverage, this leaves significant gaps.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. The Chinese text is concise and front-loaded with the core functionality. However, the character limit note in parentheses feels slightly tacked on rather than integrated, and the overall description could be more polished in its flow.
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 moderate complexity (file reading + summarization), no annotations, and an output schema that presumably documents the return value, the description is minimally adequate. It covers the basic what and how but lacks important context about limitations, error handling, and differentiation from similar tools. The presence of an output schema helps, but the description should do more to guide effective use.
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 adds meaningful context for both parameters: it explains that 'filepath' is for text files (beyond just being a string path) and that 'target_ratio' controls compression (0.1-1.0 range). However, with 0% schema description coverage, the schema provides only basic type information. The description compensates somewhat but doesn't fully explain parameter interactions or provide examples of effective target_ratio 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 tool's purpose: '读取txt等格式的文本文件并总结内容' (read text files like txt and summarize content). It specifies the resource (text files) and action (read and summarize). However, it doesn't explicitly differentiate from sibling tools like 'summarize_content' or 'read_and_summarize_pdf_file', which reduces clarity about when to choose this specific 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 minimal usage guidance. It mentions file format support (txt等格式) and a character limit (限制2k字符), but offers no explicit advice on when to use this tool versus alternatives like 'summarize_content' or 'read_and_summarize_pdf_file'. There's no mention of prerequisites, typical use cases, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrape_webpageC
抓取网页内容,可选保存为txt文件
Args:
url: 要抓取的网页URL
save_to_file: 是否保存内容到txt文件
Returns:
抓取结果和文件路径(如果保存)
| Name | Required | Description | Default |
|---|---|---|---|
| save_to_file | No | ||
| url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 mentions optional file saving but lacks critical details: whether the tool performs authentication, respects robots.txt, handles rate limits, manages errors, or what format the scraped content takes (e.g., raw HTML, cleaned text). For a web scraping tool with zero annotation coverage, this leaves significant behavioral gaps.
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 and concise, using a clear header format with Args and Returns sections. Each sentence earns its place by defining purpose and parameters efficiently. It could be slightly more front-loaded by stating the core purpose first, but overall it avoids redundancy and waste.
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 moderate complexity (web scraping with file output), no annotations, and an output schema present (which handles return values), the description is minimally adequate. It covers the basic operation and parameters but lacks context on scraping behavior, error handling, or integration with siblings. The output schema relieves the description from detailing return values, but more behavioral context is needed for full completeness.
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 adds basic semantics for both parameters: 'url: 要抓取的网页URL' (URL of the webpage to scrape) and 'save_to_file: 是否保存内容到txt文件' (whether to save content to txt file). With 0% schema description coverage, this compensates somewhat by explaining what each parameter does. However, it doesn't provide format details (e.g., URL validation) or file path behavior, keeping it at the baseline 3.
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 purpose: '抓取网页内容' (scrape webpage content) with an optional '保存为txt文件' (save as txt file). It specifies the verb (scrape) and resource (webpage content), distinguishing it from sibling tools like summarize_webpage or topic_based_summary that process rather than extract content. However, it doesn't explicitly differentiate from hypothetical scraping alternatives, keeping it at 4 instead of 5.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like summarize_webpage for summarization tasks or other content extraction methods. There's no context about prerequisites, limitations, or typical use cases, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_contentB
将任意内容总结为指定比例的长度(默认20%)
Args:
content: 要总结的内容
target_ratio: 目标压缩比例,0.1-1.0之间
Returns:
总结后的内容
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| target_ratio | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 mentions the default ratio (20%) and parameter ranges (0.1-1.0), but lacks critical details: it doesn't specify the summarization method (e.g., extractive vs. abstractive), quality expectations, handling of different content types, or potential limitations like length constraints. This leaves significant gaps in understanding how the tool behaves.
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 highly concise and well-structured: a single sentence states the purpose, followed by clearly labeled sections for Args and Returns. Every sentence earns its place, with no redundant information, making it easy to parse and understand quickly.
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 moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and parameters adequately, and the output schema handles return values. However, it lacks behavioral details (e.g., summarization approach, error cases) and usage context relative to siblings, leaving room for improvement in guiding the agent effectively.
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 adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'content' is '要总结的内容' (content to summarize) and 'target_ratio' is '目标压缩比例,0.1-1.0之间' (target compression ratio between 0.1-1.0), including the default value of 0.2. This compensates well for the schema's lack of descriptions, though it doesn't detail format expectations for 'content'.
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 purpose: '将任意内容总结为指定比例的长度' (summarize any content to a specified ratio length). It specifies the verb '总结' (summarize) and the resource '任意内容' (any content), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'summarize_webpage' or 'topic_based_summary', which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. With siblings like 'summarize_webpage' and 'topic_based_summary' available, it fails to indicate scenarios where this general-purpose summarizer is preferred over more specialized tools, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_webpageB
抓取网页内容并总结为指定比例的长度(默认20%)
Args:
url: 要抓取和总结的网页URL
target_ratio: 目标压缩比例,0.1-1.0之间
Returns:
网页内容总结
| Name | Required | Description | Default |
|---|---|---|---|
| target_ratio | No | ||
| url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 scraping and summarizing with a default ratio, but lacks details on behavioral traits such as error handling, rate limits, authentication needs, or what happens if the URL is invalid. This is inadequate for a tool that performs web operations.
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 appropriately sized and front-loaded, with the core purpose stated first, followed by parameter and return details in a structured format. It avoids unnecessary elaboration, though the Chinese text might require translation for some agents.
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, 2 parameters with 0% schema coverage, and an output schema exists (so return values are covered), the description is moderately complete. It explains parameters and purpose but lacks behavioral context and usage guidelines, making it adequate but with 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 description coverage is 0%, so the description must compensate. It adds meaning by explaining 'url' as the webpage URL to scrape and summarize, and 'target_ratio' as the compression ratio between 0.1-1.0, with a default of 20%. This clarifies beyond the schema's basic types and titles.
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 purpose: '抓取网页内容并总结为指定比例的长度' (scrape webpage content and summarize to a specified ratio length). It specifies the verb (scrape and summarize) and resource (webpage content), though it doesn't explicitly differentiate from siblings like 'scrape_webpage' or 'summarize_content'.
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 guidance is provided on when to use this tool versus alternatives. With siblings like 'scrape_webpage', 'summarize_content', and 'topic_based_summary', the description lacks context on use cases, exclusions, or comparisons, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
topic_based_summaryB
主题汇总功能 - 基于给定资料和查询主题,返回最相关的内容总结(2k字符内)
Args:
content: 资料内容
query: 查询的主题或问题
Returns:
基于主题的相关内容总结
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 the 2k character limit, which is useful behavioral context. However, it doesn't disclose other important traits like whether this is a read-only operation, potential rate limits, error conditions, or how 'most relevant' is determined. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 appropriately concise with three sentences that each serve a purpose: stating the tool's function, listing parameters, and describing the return value. It's front-loaded with the core purpose. The bilingual formatting is slightly distracting but doesn't significantly impact clarity.
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 moderate complexity (2 parameters, topic-based summarization), the description covers the essential purpose and parameters. The presence of an output schema means the description doesn't need to explain return values in detail. However, with no annotations and sibling tools present, more usage guidance would improve completeness.
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. It lists both parameters ('content' and 'query') with brief explanations, adding meaning beyond the bare schema. However, it doesn't provide format expectations, constraints, or examples for either parameter, leaving some semantic gaps despite covering both parameters.
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 purpose: '基于给定资料和查询主题,返回最相关的内容总结' (based on given content and query topic, returns the most relevant content summary). It specifies the verb '返回' (return) and resource '内容总结' (content summary), though it doesn't explicitly differentiate from sibling tools like 'summarize_content' or 'summarize_webpage' beyond mentioning the topic-based aspect.
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 no guidance on when to use this tool versus alternatives. With sibling tools like 'summarize_content' and 'summarize_webpage' available, there's no indication of when this topic-based approach is preferred over general summarization tools or when it should be avoided.
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.
7 tool updates
v1.0.0- First observed
call_model - First observed
read_and_summarize_pdf_file - First observed
read_and_summarize_text_file - First observed
scrape_webpage - First observed
summarize_content - First observed
summarize_webpage - First observed
topic_based_summary
TDQS
There is significant overlap between tools, particularly the summarization functions: read_and_summarize_pdf_file, read_and_summarize_text_file, summarize_content, summarize_webpage, and topic_based_summary all perform summarization with similar parameters. However, their descriptions clarify different input sources (PDF, text file, arbitrary content, webpage, topic-based), which helps reduce complete confusion but still creates ambiguity about when to use which tool.
Most tools follow a consistent verb_noun pattern (e.g., read_and_summarize_pdf_file, scrape_webpage, summarize_content), with clear action-object naming. The only minor deviation is 'call_model' which uses a simpler verb_noun style, but overall the naming is predictable and readable across the set.
With 7 tools, this is a well-scoped set for a content processing and summarization server. Each tool appears to serve a specific purpose within the domain, and the count is neither too thin nor overwhelming, fitting typical server scopes of 3-15 tools effectively.
The tool set covers core content processing workflows: model calling, file reading (PDF and text), web scraping, and multiple summarization methods. Minor gaps exist, such as no explicit update or delete operations for processed content, but agents can likely work around this given the server's focus on summarization and information extraction rather than content management.
Maintenance
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
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.
Related MCP Servers
- FlicenseDqualityFmaintenanceMCP Server for AI Summarization, Support for multiple content types: * Plain text * Web pages * PDF documents * EPUB books * HTML content118166-
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that allows LLMs to interact with web content through standardized tools, currently supporting web scraping functionality.1MIT
- FlicenseBqualityDmaintenanceA Model Context Protocol server that enables LLMs to extract and use content from unstructured documents across a wide variety of file formats.111-
- AlicenseBqualityDmaintenanceA Model Context Protocol server enabling AI assistants to scrape web content with high accuracy and flexibility, supporting multiple scraping modes and content formatting options.4362MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/yzfly/fullscope-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server