强大的模型上下文协议 (MCP) 服务器提供全面的文档处理功能。
读取 DOCX、PDF、TXT、HTML、CSV
DOCX 到 HTML/PDF 的转换
HTML 到 TXT/Markdown 的转换
PDF 操作（合并、拆分）
多编码传输支持（UTF-8、Big5、GBK）
文本格式化和清理
文本比较和差异生成
按行或分隔符分割文本
HTML 清理和格式化
资源提取（图像、链接、视频）
结构保留转换
Related MCP server: docx-mcp
要通过Smithery自动为 Claude Desktop 安装文档处理服务器：
npx -y @smithery/cli install @cablate/mcp-doc-forge --client claudenpm install -g @cablate/mcp-doc-forgemcp-doc-forge在 Dive Desktop 中点击“+ 添加 MCP 服务器”
复制并粘贴此配置：
{
"mcpServers": {
"searxng": {
"command": "npx",
"args": [
"-y",
"@cablate/mcp-doc-forge"
],
"enabled": true
}
}
}点击“保存”安装 MCP 服务器
麻省理工学院
欢迎社区参与和贡献！贡献方式如下：
⭐️ 如果您觉得有用，请为项目加星标
🐛 提交问题：报告问题或提供建议
🔧 创建 Pull 请求：提交代码改进
如果您有任何问题或建议，请随时联系我们：
📧 GitHub： CabLate
🤝合作：欢迎洽谈项目合作
📚 技术指导：诚挚欢迎建议和指导
Read content from non-image document-files at specified paths, supporting various file formats: .pdf, .docx, .txt, .html, .csv
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the file to be read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It states 'read content' implying a read-only, non-destructive operation. However, it fails to mention error handling (e.g., missing file, unsupported format) or any side effects, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose and supported formats. It is front-loaded with the key action ('Read content from non-image document-files…'). omits any extraneous information, but could be slightly more structured with separate clauses.
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 (one parameter, no output schema, no nested objects), the description covers the essential purpose and file types. It does not detail return format or encoding, but for a straightforward reader, the context is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter (filePath), so the schema already provides the path description. The tool description adds no additional semantics beyond mentioning supported formats, which are implicit from the file extension. Thus, it adds minimal value over the 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 the tool reads content from non-image document files and lists specific formats (.pdf, .docx, .txt, .html, .csv). This specificity distinguishes it from sibling tools like docx_to_html or pdf_splitter, which perform targeted conversions or manipulations.
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 reading text-based files, but it does not explicitly advise when to avoid this tool or suggest alternatives. For instance, it does not mention that image files should be handled by other tools or that excel_read should be used for .xlsx files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert DOCX to HTML while preserving formatting
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input DOCX file | |
| outputDir | Yes | Directory where HTML should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. 'Preserving formatting' adds some behavior, but no info on safety, auth, or side effects. 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?
Single sentence, no wasted words, perfectly concise for a simple tool.
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 simplicity (2 params, no output schema), description covers purpose and core behavior. Lacks mentions of limitations or error cases, but adequate.
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 100%, schema descriptions are clear. Description adds no extra meaning beyond 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?
Clearly states verb 'Convert', resources 'DOCX to HTML', and a specific attribute 'preserving formatting'. Distinct from siblings like docx_to_pdf.
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 when-to-use guidance, no mention of alternatives like html_to_text for text extraction, no exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert DOCX files to PDF format
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input DOCX file | |
| outputPath | Yes | Path where the output PDF file should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description fails to disclose behavioral traits such as file overwrite behavior, formatting preservation, or error handling, which are important for a conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is to the point. It could benefit from a bit more detail but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not cover return values, error conditions, or prerequisites. Given the tool's simplicity and absence of output schema, more context is needed for an agent to use it 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?
Input schema has 100% description coverage with two parameters (inputPath, outputPath). The description adds no additional semantics beyond what the schema already provides, meeting the baseline.
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 action (convert) and the resource (DOCX files to PDF format), distinguishing it from sibling tools like docx_to_html and format_convert.
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 on when to use this tool versus alternatives such as docx_to_html or format_convert. The description only states the conversion purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Excel file and convert to JSON format while preserving structure
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input Excel file | |
| includeHeaders | No | Whether to include headers in the output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions 'preserving structure' but doesn't explain what that entails (e.g., sheets, formatting). It also doesn't state that the tool is non-destructive or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. However, it lacks structure and additional detail that could improve usability.
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 absence of annotations and output schema, the description is too brief. It doesn't cover important aspects like output format, error handling, or limitations, making it incomplete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; 'preserving structure' is vague and doesn't clarify parameter usage. No details on inputPath format or includeHeaders behavior.
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 reads an Excel file and converts it to JSON while preserving structure. It is specific to Excel files, distinguishing it from sibling tools like document_reader or format_convert.
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 on when to use this tool over alternatives, nor any context on when to set includeHeaders. There are no hints about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between different document formats (Markdown, HTML, XML, JSON)
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Input content to convert | |
| fromFormat | Yes | Source format | |
| toFormat | Yes | Target format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must handle transparency alone. It only states basic conversion without disclosing traits such as validation behavior, error handling, lossiness, or transformation assumptions. This is insufficient for an agent to anticipate side-effects or constraints.
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?
Description is a single efficient sentence with no redundant words. It immediately conveys the core operation and supported formats.
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?
No output schema and no annotations. Description omits critical details like return format (e.g., plain string, object) and does not address error scenarios (e.g., unsupported conversion direction). For a conversion tool, this leaves the agent guessing about what the output looks like.
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?
Input schema covers 100% of parameters with descriptions; the tool description adds no additional meaning beyond the schema. Baseline score of 3 applies as the description does not enhance parameter understanding.
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?
Description clearly states verb 'Convert' and resource 'document formats' with explicit list of formats (Markdown, HTML, XML, JSON). It differentiates from sibling tools like docx_to_html or html_to_markdown by being a general converter among these four formats, though it does not explicitly contrast with specific siblings.
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 generic converter versus format-specific sibling tools (e.g., html_to_markdown). The description lacks any 'use-if' or 'prefer-alternative' hints, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean HTML by removing unnecessary tags and attributes
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input HTML file | |
| outputDir | Yes | Directory where cleaned HTML should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states removal of 'unnecessary' elements without specifying criteria (e.g., scripts, styles, attributes). No mention of side effects, file permissions, or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but arguably too brief. It lacks details that would help the agent understand the tool's behavior, though it is front-loaded with the action and resource.
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 output schema, the description does not explain what the output looks like (e.g., cleaned HTML file, error handling). It omits return values and side effects, leaving gaps for a tool with two required file path parameters.
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 100%, so the schema already describes both parameters. The description adds no additional meaning beyond what the schema provides; it does not clarify file formats, required permissions, or naming conventions for the output directory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'clean' and resource 'HTML', stating it removes 'unnecessary tags and attributes'. This differentiates from siblings like html_formatter (formatting) and html_to_markdown (conversion), though it lacks clarity on what constitutes 'unnecessary'.
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 siblings such as html_formatter or html_extract_resources. The description does not mention prerequisites, use cases, or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all resources (images, videos, links) from HTML
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input HTML file | |
| outputDir | Yes | Directory where resources should be saved |
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 the tool is read-only, modifies input, or how it handles errors. The description carries the full burden but only states the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary detail. It could be slightly expanded to cover what extraction entails without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool likely produces output files, but the description does not specify return values or side effects. With no output schema and no annotations, the description is insufficient for an agent to fully understand the tool's 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?
Schema coverage is 100%, and both parameters have descriptions in the schema. The tool description adds no additional meaning beyond what is already in the schema (e.g., that resources are saved to an output directory).
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 extracts resources (images, videos, links) from HTML, differentiating it from sibling tools like html_cleaner or html_formatter. However, it could be more specific about the extraction process (e.g., whether it saves files or extracts URLs).
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 such as html_cleaner or html_to_text. There is no mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format and beautify HTML code
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input HTML file | |
| outputDir | Yes | Directory where formatted HTML should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits, but only states 'format and beautify' without disclosing mutation, error handling, or output behavior.
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?
Single sentence with no wasted words, but lacks additional context that could be included without verbosity.
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?
No output schema and minimal description fail to convey return values or side effects. For a tool with two required parameters, more context is needed.
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?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no extra meaning beyond 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 the verb ('Format and beautify') and resource ('HTML code'), but does not differentiate from sibling tools like html_cleaner or html_to_markdown, which might have overlapping purposes.
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 on when to use this tool versus alternatives. Sibling tools like html_cleaner or html_extract_resources exist with no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert HTML to Markdown format
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input HTML file | |
| outputDir | Yes | Directory where Markdown file should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose critical behavioral details such as file overwrite behavior, error handling, or output encoding. The description adds no value beyond the tool name.
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?
Single sentence is concise but borderline under-specified. Not wasteful, but lacks structure that could front-load key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file conversion tool with two required parameters, no output schema, and no annotations, the description is grossly incomplete. It omits file format specifics, error cases, and any behavioral contract.
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?
Input schema covers both parameters with descriptions, so the description adds no extra meaning. Baseline score of 3 applies as schema coverage is 100%.
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?
Description explicitly states the action ('Convert') and resources ('HTML to Markdown'), clearly distinguishing it from sibling tools like html_to_text or html_cleaner.
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 on when to use this tool versus alternatives (e.g., html_to_text). No mention of prerequisites or context, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert HTML to plain text while preserving structure
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input HTML file | |
| outputDir | Yes | Directory where text file should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'preserving structure' without explaining what that entails (e.g., handling of nested elements, CSS, scripts). No disclosure of side effects, performance characteristics, or error handling.
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 extremely short (one sentence), but it sacrifices necessary details for brevity. It is more under-specified than concise, missing important behavioral and usage information. Effective conciseness would be shorter without losing completeness, but here it is incomplete.
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 2 required parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns (e.g., file path, confirmation), how it handles errors, or edge cases like empty files. Sibling context is not leveraged for differentiation.
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 100%, so the baseline is 3. However, the description adds no additional meaning beyond the schema. It does not explain path formats, file extensions, or whether outputDir must exist. The description provides zero extra value for parameter understanding.
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 converts HTML to plain text, with a specific verb ('Convert') and resource ('HTML to plain text'). It mentions preserving structure, which adds context. However, it does not differentiate from siblings like 'html_to_markdown' or 'html_cleaner' that may also produce text output.
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 given on when to use this tool versus alternatives (e.g., html_to_markdown). There is no mention of prerequisites, preferred scenarios, or when to avoid the tool. The description fails to help the agent select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge multiple PDF files into one
| Name | Required | Description | Default |
|---|---|---|---|
| inputPaths | Yes | Paths to the input PDF files | |
| outputDir | Yes | Directory where merged PDFs should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., file ordering, safety of originals). It merely states the basic action, leaving the agent unaware of side effects or constraints.
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 (one sentence) but lacks essential details. It is not under-specified for a trivial tool, but for a file operation tool, more structure would be helpful.
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 presence of siblings and the complexity of file merging, the description is incomplete. It does not explain the output file naming, error handling, or limits, leaving gaps for the agent.
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 input schema has 100% description coverage, so parameters are documented. The description adds no additional meaning beyond what the schema already provides; the baseline score of 3 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 the tool merges multiple PDF files into one, which is a specific verb+resource. However, it does not distinguish from the sibling pdf_splitter or clarify the output format (e.g., whether the merged file name is derived).
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 like pdf_splitter, nor any prerequisites or limitations (e.g., maximum number of files).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a PDF file into multiple files
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input PDF file | |
| outputDir | Yes | Directory where split PDFs should be saved | |
| pageRanges | Yes | Array of page ranges to split |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the original file is preserved, how output files are named, or error handling. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It could be front-loaded with key behavior but is too sparse to be considered 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?
No output schema and no annotations. The description does not explain the output format (e.g., whether split files are saved individually, their naming convention). For a tool with 3 required parameters, more context is needed.
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 100% with descriptions, so baseline is 3. The description adds no additional meaning beyond the schema; all parameters are required and explained in 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 the verb ('split') and the resource ('PDF file'), and distinguishes it from siblings like pdf_merger (which merges) and text_splitter (which splits text).
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 on when to use this tool vs alternatives, such as when splitting by page ranges is appropriate versus other methods. No when-not-to-use or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two text files and show differences
| Name | Required | Description | Default |
|---|---|---|---|
| file1Path | Yes | Path to the first text file | |
| file2Path | Yes | Path to the second text file | |
| outputDir | Yes | Directory where diff result should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose read-only nature, output format, or potential limitations (e.g., encoding, file size), leaving 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?
One concise sentence with no redundant language, but could be slightly more informative without sacrificing brevity.
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?
Missing output schema and description does not explain diff output format or encoding assumptions, leaving agent without crucial context for handling results.
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 already provides clear descriptions for all 3 parameters (100% coverage), so description adds no extra semantic value beyond baseline.
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?
Description clearly states action ('Compare two text files') and result ('show differences'), distinguishing it from siblings which are all different document/text operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives mentioned; usage is implied but not guided for scenarios like binary file comparison or choosing between diff tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text between different encodings
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input text file | |
| outputDir | Yes | Directory where converted file should be saved | |
| fromEncoding | Yes | Source encoding (e.g., 'big5', 'gbk', 'utf8') | |
| toEncoding | Yes | Target encoding (e.g., 'utf8', 'big5', 'gbk') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'convert text between different encodings,' omitting details like file overwriting behavior, output file naming conventions, error handling for invalid encodings, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it sacrifices necessary detail. Conciseness is positive, but not at the expense of completeness; it should include more context to be truly effective.
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 performs file conversion with no output schema, the description should explain return values, output file format, and potential side effects. It fails to provide this context, leaving agents to guess the tool's 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?
The input schema has 100% coverage with descriptions for all four parameters. The description does not add extra meaning beyond what the schema provides, so it meets the baseline expectation.
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: converting text between encodings. It uses a specific verb and resource, and distinguishes itself from sibling tools like docx_to_html or text_formatter, as none of those focus on encoding conversion.
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 does not mention prerequisites, when not to use it, or differentiate from sibling tools that might perform similar operations in different contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format text with proper indentation and line spacing
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input text file | |
| outputDir | Yes | Directory where formatted file should be saved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits fully. It only states the intended formatting action but omits details like whether input is modified in-place, if existing files are overwritten, or any side effects. The agent cannot infer safety or side-effect profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, appropriate for a simple tool. However, it is too brief to cover key details, trading conciseness for completeness.
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 lack of output schema, the description should explain the result of formatting (e.g., new file created, encoding, style). It fails to provide enough context for the agent to understand inputs and outputs, making it incomplete.
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 100%, so baseline is 3. The description does not elaborate on parameter roles or constraints beyond the schema's own descriptions, thus adding no extra value.
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 formats text with indentation and line spacing, which is a specific verb-resource pair. However, it does not differentiate from sibling tools like html_formatter or text_diff, which also involve text formatting, thus missing a chance to clarify scope.
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 (e.g., html_formatter, text_splitter). No context on prerequisites or excluded use cases is given, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split text file by specified delimiter or line count
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input text file | |
| outputDir | Yes | Directory where split files should be saved | |
| splitBy | Yes | Split method: by line count or delimiter | |
| value | Yes | Line count (number) or delimiter string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states the split method, missing details like file overwrite behavior, error handling, or output naming conventions.
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?
Single sentence, no wasted words. Could be improved by front-loading actionable info, but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required parameters and no output schema, the description is too minimal. It lacks context on file format requirements, output naming, or how the split method works in practice.
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 100%, so baseline is 3. Description adds no extra meaning beyond what the schema already provides (e.g., line count or delimiter string).
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?
Description clearly states the tool splits a text file by delimiter or line count, which is specific and distinguishes it from siblings like pdf_splitter and text_formatter.
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 on when to use this tool versus alternatives (e.g., for numeric splitting vs. delimiter patterns), nor any prerequisites like file existence or directory creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
document_readerdocx_to_htmldocx_to_pdfexcel_readformat_converthtml_cleanerhtml_extract_resourceshtml_formatterhtml_to_markdownhtml_to_textpdf_mergerpdf_splittertext_difftext_encoding_convertertext_formattertext_splitterEach tool targets a distinct operation: reading various formats, specific conversions (docx, html, pdf, text), and manipulations. There is no overlap in purpose; even similar conversions like html_to_markdown and html_to_text are clearly differentiated.
All tool names follow the verb_noun pattern (e.g., document_reader, docx_to_html, text_splitter) using consistent snake_case. The naming is predictable and easy to understand.
With 16 tools, the count is slightly above the typical range of 3-15, but it is justified by the breadth of document formats and operations covered, making it reasonable for the server's purpose.
The tool set covers reading, converting, and manipulating common document formats (PDF, DOCX, HTML, text, Excel). Minor gaps exist, such as missing direct docx-to-text conversion (though document_reader can read docx), but the overall surface is comprehensive for most document processing needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Composable APIs for document extraction, image transformation, and document & sheet generation.
Turn documents into structured data: parse, extract, classify, split, and fill PDF forms.
Convert and compress PDFs and images, redact personal data, and run text and data utilities.
Cloud PDF generation from HTML, CSS and XSL-FO, with PDF/A and PDF/UA support.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cablate/mcp-doc-forge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
