How do I use Word Document Reader MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Word Document Reader MCP Server read the quarterly report at /docs/reports/q3-2024.docx and extract all tables" 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.

Word Document Reader MCP Server

by little2512

Overview Schema Related Servers Score Discussions

JavaScript

Local

Word Document Reader MCP Server

A powerful Word document reading MCP server with table extraction, image OCR analysis, large document optimization, and intelligent caching.

🚀 Core Features

1. Document Content Extraction

✅ Word document (.docx/.doc) text extraction
✅ Support for mixed Chinese-English documents
✅ Preserve original formatting and structure

2. Table Extraction

✅ Automatically identify and extract tables from Word documents
✅ Convert to structured data format
✅ Preserve table row/column structure information
✅ Support complex table parsing

3. Image OCR Analysis

✅ Extract embedded images from Word documents
✅ High-precision OCR recognition using Tesseract.js v5
✅ Support mixed Chinese-English text recognition (95%+ accuracy)
✅ Intelligent image preprocessing for better recognition
✅ Support multiple image formats (JPG, PNG, GIF, BMP, WebP)

4. Large Document Optimization

✅ Automatic detection of large documents (>10MB or >100 pages)
✅ Worker thread parallel processing, utilizing multi-core CPUs
✅ Chunked processing to avoid memory overflow
✅ 60%+ speed improvement

5. Intelligent Caching System

✅ File system persistent caching
✅ Smart cache invalidation based on file modification time
✅ Cache statistics and management support
✅ 90%+ speed improvement for repeated document processing

6. Full-text Index Search

✅ Millisecond-level search with inverted index
✅ Intelligent Chinese-English word segmentation
✅ Relevance scoring and sorting
✅ Support document type filtering

Related MCP server: Document Reader MCP Server

📦 Installation and Usage

1. Install Dependencies

npm install

2. Start Server

# Start full-featured version
npm start

# Or start basic version (without advanced features)
npm run start:basic

3. Run Tests

# Run all tests
npm test

# Run tests in watch mode
npm run test:watch

# Generate test coverage report
npm run test:coverage

read_word_document

Read and analyze Word documents

{
  "name": "read_word_document",
  "arguments": {
    "filePath": "path/to/document.docx",
    "memoryKey": "my-document",
    "documentType": "api-doc",
    "extractTables": true,
    "extractImages": true,
    "useCache": true,
    "outputDir": "./output"
  }
}

search_documents

Full-text index search

{
  "name": "search_documents",
  "arguments": {
    "query": "search keywords",
    "documentType": "api-doc",
    "limit": 10
  }
}

get_cache_stats

Get cache statistics

{
  "name": "get_cache_stats"
}

clear_cache

Clear cache

{
  "name": "clear_cache",
  "arguments": {
    "type": "all"  // "all", "document", "index"
  }
}

list_stored_documents

List stored documents

{
  "name": "list_stored_documents",
  "arguments": {
    "documentType": "api-doc"
  }
}

get_stored_document

Get specific document content

{
  "name": "get_stored_document",
  "arguments": {
    "memoryKey": "document-key"
  }
}

clear_memory

Clear memory content

{
  "name": "clear_memory",
  "arguments": {
    "memoryKey": "specific-key"  // Optional, clear all if not provided
  }
}

📁 Project Structure

word-doc-mcp/
├── server.js              # Main server file (with all features)
├── server-basic.js        # Basic server (compatibility)
├── package.json           # Project configuration and dependencies
├── config.json           # Server configuration file
├── tests/                # Test directory
│   ├── setup.js          # Test environment setup
│   ├── unit/             # Unit tests
│   │   └── services/     # Service layer tests
│   ├── integration/      # Integration tests
│   │   ├── tools/        # Tool tests
│   │   └── cache/        # Cache tests
│   └── fixtures/         # Test data
│       ├── documents/    # Test documents
│       └── mock-data.js  # Mock data
├── .cache/               # Cache directory (auto-created)
├── output/               # Output directory (auto-created)
└── node_modules/         # Dependencies

⚙️ Configuration

Edit the config.json file to customize server behavior:

{
  "processing": {
    "maxFileSize": 10485760,
    "maxPages": 100,
    "chunkSize": 1048576,
    "parallelProcessing": true
  },
  "cache": {
    "enabled": true,
    "defaultTTL": 3600,
    "cacheDirectory": "./.cache"
  },
  "ocr": {
    "enabled": true,
    "languages": ["chi_sim", "eng"]
  }
}

🧪 Testing

Test Framework

Using Node.js built-in test framework, following these standards:

Unit Tests: Test individual components and functions
Integration Tests: Test interactions between tools
End-to-End Tests: Test complete workflows

Running Tests

# Run all tests
npm test

# Run specific test file
node --test tests/unit/services/DocumentIndexer.test.js

# Run integration tests
node --test tests/integration/

# Generate coverage report
npm run test:coverage

Test Coverage

✅ Functional tests for all MCP tools
✅ Complete cache system tests
✅ Error handling and edge cases
✅ Performance and concurrency tests
✅ End-to-end workflow tests

📊 Performance Metrics

Large Document Processing: 60%+ speed improvement (parallel processing)
Repeated Document Processing: 90%+ speed improvement (caching)
OCR Recognition Accuracy: 95%+ (image preprocessing)
Memory Usage Optimization: 40% reduction (streaming processing)
Search Response Time: <100ms (full-text index)

🛡️ Security Considerations

Input file size limits
File type validation
Cache data isolation
Error handling and logging
Automatic temporary file cleanup

🔄 Version Compatibility

Backward Compatibility

✅ Maintain full compatibility with original API
✅ Existing tool functionality unchanged
✅ Optional configuration with reasonable defaults
✅ Provide basic version to ensure compatibility

System Requirements

Minimum Requirements:

Node.js 16+
4GB RAM
1GB disk space

Recommended Configuration:

Node.js 18+
8GB+ RAM
Multi-core CPU
SSD storage

🐛 Troubleshooting

Common Issues

Module Installation Failure
```
npm cache clean --force
npm install
```
OCR Recognition Failure
- Ensure sufficient memory (8GB+ recommended)
- Check supported image formats
- Review error logs
Slow Large Document Processing
- Enable parallel processing
- Adjust chunkSize configuration
- Use SSD storage

Memory Insufficient

node --max-old-space-size=4096 server.js

📝 Changelog

v2.0.0

✅ Add table extraction functionality
✅ Add image OCR analysis
✅ Implement large document parallel processing
✅ Add intelligent caching system
✅ Implement full-text index search
✅ Complete testing framework

v1.0.0

✅ Basic Word document reading
✅ Memory storage management
✅ Simple search functionality

🤝 Contributing

Issues and Pull Requests are welcome!

Development Guidelines

Fork the project
Create feature branch
Write test cases
Ensure all tests pass
Submit Pull Request

📄 License

MIT License

Quick Start: npm install && npm start

Available Tools

7 tools

clear_cacheC

清空所有缓存

ParametersJSON Schema

Name	Required	Description	Default
`type`	No	清除类型：all, document, index	all

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. '清空所有缓存' implies a destructive operation that removes cached data, but it doesn't specify what types of data are affected, whether this requires special permissions, if the operation is reversible, what side effects might occur, or what happens after execution. For a potentially destructive tool, this is 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 extremely concise - just four Chinese characters that directly convey the core function. There's zero wasted language or unnecessary elaboration. It's front-loaded with the essential information in the most compact form possible.

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?

For a cache-clearing operation with no annotations and no output schema, the description is incomplete. It doesn't address important contextual questions: What does 'cache' refer to in this system? What are the consequences of clearing it? Are there different cache types? What confirmation or result should be expected? The single sentence leaves too many practical questions unanswered.

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 description mentions 'all cache' which implies comprehensive clearing, but the input schema shows a 'type' parameter with three options (all, document, index). The description doesn't explain these options or their differences. With 100% schema description coverage, the baseline is 3, but the description adds minimal value beyond what's already in the schema.

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 '清空所有缓存' (Clear all cache) clearly states the action (clear) and target (cache), making the purpose immediately understandable. It doesn't specifically distinguish from sibling tools like 'clear_memory' or 'get_cache_stats', but the verb+resource combination is unambiguous for what this tool does.

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 provides no guidance on when to use this tool versus alternatives. There's no mention of when this operation is appropriate, what prerequisites might exist, or how it differs from sibling tools like 'clear_memory' or 'get_cache_stats'. The user must 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.

clear_memoryC

清除指定的内存内容

ParametersJSON Schema

Name	Required	Description	Default
`memoryKey`	No	要清除的内存键名，如果不提供则清除所有

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. '清除' (clear) implies a destructive operation, but the description doesn't specify whether this is reversible, what permissions are required, whether it affects system performance, or what happens when memoryKey is omitted. The description mentions the optional parameter behavior but lacks critical 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 extremely concise - a single Chinese phrase that directly states the tool's function. There's zero wasted language, and it's front-loaded with the core action. This is appropriate conciseness for a simple tool.

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?

For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'memory' means in this context, what gets cleared, whether the operation is safe/reversible, what happens when all memory is cleared, or what the tool returns. Given the complexity of a memory-clearing operation, more context is needed.

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

Parameters4/5

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

The description implies parameter semantics by mentioning '指定的' (specified), which aligns with the optional memoryKey parameter. With 100% schema description coverage and only one parameter, the description adds minimal but appropriate context about the parameter's purpose without duplicating schema information.

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

Purpose3/5

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

The description '清除指定的内存内容' (Clear specified memory content) states the verb (clear) and resource (memory content), but it's vague about what 'memory content' means in this context. It doesn't distinguish this tool from sibling tools like 'clear_cache' or explain what type of memory is being cleared.

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 provides no guidance on when to use this tool versus alternatives like 'clear_cache' or other sibling tools. There's no mention of prerequisites, typical use cases, or when this tool would be preferred over other memory/cache management tools.

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

get_cache_statsB

获取缓存统计信息

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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 states the action ('get') but doesn't add any context about what the statistics include, whether it's a read-only operation, performance implications, or rate limits. This leaves significant gaps for a tool that likely provides system-level data.

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, efficient sentence in Chinese ('获取缓存统计信息') that directly states the purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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 annotations and output schema, the description is incomplete. It doesn't explain what the cache statistics include (e.g., hit rates, memory usage), the format of the return value, or any behavioral traits. For a tool that likely provides detailed system data, this leaves too much unspecified.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, earning a high baseline score.

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 '获取缓存统计信息' (Get cache statistics) clearly states the verb 'get' and the resource 'cache statistics', providing a specific purpose. However, it doesn't differentiate from sibling tools like 'clear_cache' or 'get_stored_document', 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.

Usage Guidelines2/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 like 'clear_cache' or 'get_stored_document'. There's no mention of context, prerequisites, or exclusions, 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.

get_stored_documentC

获取已存储的文档内容

ParametersJSON Schema

Name	Required	Description	Default
`memoryKey`	Yes	要获取的文档内存键名

TDQS

C2.6/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 the full burden of behavioral disclosure. It states the tool retrieves content but doesn't describe what happens if the document doesn't exist (e.g., errors), whether it requires authentication, rate limits, or the format of returned content. For a read operation with zero annotation coverage, this leaves significant gaps in understanding behavior.

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, efficient sentence in Chinese that directly states the tool's purpose. It's appropriately sized and front-loaded with the core action. There's no wasted text, though it could be slightly more informative without losing conciseness.

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 tool has no annotations and no output schema, the description is incomplete. It doesn't explain what 'stored' means in context (e.g., from a cache or database), what content is returned (e.g., text, binary), or error handling. For a tool with one parameter but rich behavioral unknowns, this minimal description is inadequate.

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 description coverage is 100%, with the single parameter 'memoryKey' documented as '要获取的文档内存键名' (the memory key name of the document to retrieve). The description doesn't add any meaning beyond this, such as explaining what a 'memoryKey' represents or providing examples. Since the schema does the heavy lifting, 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.

Purpose3/5

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

The description states the tool's purpose as '获取已存储的文档内容' (get stored document content), which clearly indicates it retrieves document content. However, it doesn't distinguish this from sibling tools like 'list_stored_documents' (which likely lists metadata) or 'read_word_document' (which may read from a different source). The verb+resource is clear but lacks sibling 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a stored document), exclusions, or comparisons to siblings like 'search_documents' or 'read_word_document'. Without such context, the agent must 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.

list_stored_documentsC

列出所有已存储的文档

ParametersJSON Schema

Name	Required	Description	Default
`documentType`	No	筛选特定类型的文档

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions listing documents but doesn't describe pagination behavior, rate limits, authentication requirements, or what 'stored' means in this context. The description is too minimal to adequately inform the agent about how this 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.

Conciseness5/5

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

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's perfectly concise and front-loaded with the core functionality.

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?

For a list operation with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned about each document, whether results are paginated, or how 'documentType' filtering affects the output. The agent would need to guess about the tool's behavior and output format.

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% description coverage with a well-documented enum parameter. The description doesn't add any parameter information beyond what's in the schema, but since the schema already fully documents the single optional parameter, 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.

Purpose4/5

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

The description '列出所有已存储的文档' (List all stored documents) clearly states the verb (list) and resource (stored documents). It's specific about scope ('all'), but doesn't differentiate from sibling tools like 'search_documents' or 'get_stored_document', 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.

Usage Guidelines2/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 like 'search_documents' (for filtered searches) or 'get_stored_document' (for retrieving a single document). It simply states what the tool does without context about appropriate use cases.

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

read_word_documentC

增强版Word文档读取器，支持表格提取、图片OCR分析和缓存优化

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Word文档的文件路径
`memoryKey`	No	用于存储的内存键名，便于后续检索	default
`documentType`	No	文档类型	common-doc
`extractTables`	No	是否提取表格
`extractImages`	No	是否提取图片并进行OCR分析
`useCache`	No	是否使用缓存
`outputDir`	No	图片和临时文件输出目录	./output

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'cache optimization' but doesn't explain caching behavior (e.g., cache duration, invalidation). It doesn't disclose performance characteristics, error handling, or what 'enhanced' means operationally. The description adds some context about extraction capabilities but leaves critical behavioral traits unspecified.

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, efficient sentence that front-loads the core purpose ('enhanced Word document reader') followed by key features. Every phrase adds value, though it could be slightly more structured by separating core function from optional capabilities.

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?

For a 7-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (document content? structured data? metadata?), how extracted tables/images are formatted, or what 'memoryKey' storage enables. The agent lacks critical information about the tool's outputs and behavioral guarantees.

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%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (e.g., how 'extractImages' interacts with 'outputDir') or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

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 function as an 'enhanced Word document reader' with specific capabilities (table extraction, image OCR analysis, cache optimization). It distinguishes itself from basic readers by mentioning these advanced features, though it doesn't explicitly differentiate from sibling tools like 'get_stored_document' or 'search_documents' which might have overlapping functionality.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when this enhanced reader is preferable over simpler tools, nor does it reference any sibling tools for comparison. The agent must infer usage from the feature list alone.

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

search_documentsC

全文索引搜索，支持中英文混合搜索

ParametersJSON Schema

Name	Required	Description
`query`	Yes	搜索关键词
`documentType`	No	限制搜索的文档类型
`limit`	No	返回结果数量限制

TDQS

C2.6/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 the full burden. It mentions 'full-text index search' and language support, but lacks critical behavioral details: it doesn't disclose whether this is a read-only operation, how results are returned (e.g., pagination, sorting), performance characteristics, or error handling. For a search tool with no annotations, this is inadequate.

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 very concise with a single sentence, which is efficient. However, it's under-specified rather than optimally concise—it could benefit from slightly more detail without becoming verbose. It's front-loaded but lacks depth.

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 complexity of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., search results format), how to interpret outputs, or any limitations. This leaves significant gaps for an AI agent to use the tool effectively.

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 description adds no parameter semantics beyond what the input schema provides. The schema has 100% description coverage, clearly documenting 'query', 'documentType', and 'limit' with enums and defaults. The description doesn't explain parameter interactions or provide additional context, so it meets the baseline of 3.

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

Purpose3/5

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

The description states the tool performs 'full-text index search' and supports 'Chinese-English mixed search', which provides a basic purpose. However, it doesn't specify what resource is being searched (documents, files, etc.) or distinguish it from sibling tools like 'list_stored_documents' or 'get_stored_document'. The purpose is somewhat vague about scope.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'list_stored_documents' (which might list without search) or 'get_stored_document' (which retrieves a specific document), nor does it specify any prerequisites or exclusions for usage.

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 updatesv1.0.0Jan 3, 2026
- Addedclear_cache
- Addedclear_memory
- Addedget_cache_stats
- Addedget_stored_document
- Addedlist_stored_documents
- Addedread_word_document
- Addedsearch_documents
7 tool updatesJan 3, 2026
- Removedclear_cache
- Removedclear_memory
- Removedget_cache_stats
- Removedget_stored_document
- Removedlist_stored_documents
- Removedread_word_document
- Removedsearch_documents
7 tool updatesDec 13, 2025
- First observedclear_cache
- First observedclear_memory
- First observedget_cache_stats
- First observedget_stored_document
- First observedlist_stored_documents
- First observedread_word_document
- First observedsearch_documents

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is some potential overlap between 'clear_cache' and 'clear_memory' as both involve clearing operations, which could cause confusion without clear context in their descriptions. The other tools like 'read_word_document', 'search_documents', and document listing/storage tools are well-differentiated.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., 'clear_cache', 'get_stored_document', 'list_stored_documents'), making them predictable and easy to understand. There are no deviations in naming conventions.

Tool Count5/5

With 7 tools, the server is well-scoped for a Word Document Reader, covering core operations like reading, searching, listing, storing, and cache management. Each tool appears to serve a specific and necessary function without being overly sparse or bloated.

Completeness4/5

The tool set covers key document handling workflows, including reading, searching, listing, and storage, with added cache management. A minor gap exists in document modification or deletion tools, but the core functionality for a reader is largely complete, allowing agents to perform essential tasks effectively.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

AILANG Parse A
io.github.sunholo-data
Deterministic DOCX/PPTX/XLSX/PDF parser: track changes, comments, headers, footers, merged cells.
Developer Tools Documentation Access App Automation
102
space-ocrOAuth
io.github.hwang-yh-cto
Verified OCR with per-value coordinates, plus a workspace agents can file documents into and query.
Image & Video Processing Knowledge & Memory Search
1
Brainiall Documents A
com.brainiall
High-fidelity PDF to structured Markdown conversion and document field extraction.
Data Platforms
31
stagenth · 文档解析 A
com.stagenth
Parse PDF/Word/PPT/HTML to Markdown; tables as JSON, image extraction, RAG chunking, page ranges.
RAG Systems File Systems
42

Related MCP Servers

Simple Document Processing MCP
File Systems Text Summarization Multimedia Processing
cablate
A
license
B
quality
D
maintenance
Provides comprehensive document processing, including reading, converting, and manipulating various document formats with advanced text and HTML processing capabilities.
Updated a year ago (2025-06-02 01:29 UTC)
16
153
19
MIT
Document Reader MCP Server
File Systems Developer Tools
ohaha-1
A
license
Not graded
quality
D
maintenance
Enables reading and processing various document formats including Word, PDF, RTF, and text files. Supports extracting media elements like images and links, with features for PDF page range selection and automatic text encoding detection.
Updated a year ago (2025-08-13 04:45 UTC)
8
MIT
docx-mcp
File Systems Workplace & Productivity Developer Tools
Andrew82106
A
license
B
quality
D
maintenance
Enables comprehensive management of Microsoft Word documents with 30+ tools for reading, writing, formatting, template merging, image extraction, equation extraction, and style application.
Updated 9 months ago (2025-12-20 01:23 UTC)
24
1
MIT
docx-comments
Workplace & Productivity Content Management Systems
kosh-jelly
A
license
A
quality
D
maintenance
Provides comprehensive read/write access to Word documents, including comments, track changes, and reply threads.
Updated 7 months ago (2026-01-31 22:54 UTC)
9
1
MIT

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 July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/little2512/word-doc-mcp'

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