An intelligent document assistant powered by MCP (Model Context Protocol) that helps users with document analysis, editing, formatting, summarization, and file operations. Supports multiple file types including text, PDF, DOCX, and images with OCR.
This MCP server implements 10 document and file manipulation tools with STDIO transport. While tool schemas are present and mostly complete, descriptions are generic and lack the specificity required for confident LLM selection. Parameter naming follows conventions but lacks clarity on mutual exclusivity and format constraints. Error handling is minimal, most tools raise ValueError without recovery guidance. Output schemas are not documented. The server does not implement tool annotations, output format documentation, or structured error responses that would guide agent behavior. Several tools expose path traversal risks without clear security documentation.
This tool edits the contents of the document by replacing a string in the documents with a new one.
Get detailed metadata about a document including file type, size, creation date, etc.
Get information about a file (size, modification time, etc.)
List all files in the working directory with their relative paths
This tool reads the contents of the document and returns it as a string
Read the contents of a file from the working directory
Search for text patterns in files within the working directory
Critical: set_working_directory description is vague ('allows the agent to work with any files in the specified folder') with no mention that this is a stateful operation or that it enables path traversal attacks if unchecked. Agents need explicit safety guidance.
High: No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. e.g., read_doc_contents returns a string but does not specify character encoding, max length, or whether it's raw text or structured.
High: Error handling is minimal. Tools like read_doc_contents and read_file raise ValueError('not found') without recovery guidance. Should return actionable errors like 'Document with id doc_123 not found. Available documents: [list]. Use upload_document() to add a new document.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Set the working directory for file operations. This allows the agent to work with any files in the specified folder.
Upload a document to the server's memory for analysis and manipulation
Write content to a file in the working directory
High: edit_doc_contents requires exact string matching including whitespace ('Must match exactly ,including whitespace'), but provides no guidance on how to discover valid strings beforehand. No helper tool exists to inspect text positions or line numbers. Agents will fail on whitespace mismatches with no recourse.
High: Parameter descriptions lack format constraints. search_in_files 'pattern' parameter: is it regex, glob, or literal? 'file_pattern' parameter: case-sensitive glob? write_file 'content' parameter: max size? Binary or text only? These ambiguities cause agents to guess and fail.
Medium: No mention of idempotency or side effects. write_file overwrites silently, is this idempotent on repeated calls? edit_doc_contents modifies in-place. Agents need to know which calls can be safely retried.
Medium: No permission or security annotations (readOnlyHint, destructiveHint). set_working_directory and write_file are destructive but not marked. Agents cannot determine if a tool is safe to call blindly.
Medium: Dual-store design (in-memory 'docs' dict + 'processed_docs' dict) not documented. Agents don't know if uploading a document populates both or just one, or how they interact.
Medium: list_files accepts optional 'pattern' parameter but description says 'File pattern to match (e.g., '*.py', '*.md')', unclear if this is required to filter or optional. No mention of what happens if pattern is omitted (list all?) or is invalid.
Low: Naming inconsistency: 'read_doc_contents' uses 'doc_id', 'get_document_metadata' uses 'doc_id', but 'read_file' uses 'file_path'. Agents working with uploaded documents must track both naming conventions, increasing cognitive load.