MCP server that exposes Magies Office PDF and document tools via a local REST API, enabling Claude and other MCP clients to perform document processing, conversion, editing, and office automation tasks
Critical failures across all dimensions. Five tools use dynamic naming (convert__*, organize__*, edit__*, security__*, read__*) with tool names generated at runtime from a catalog, tool definitions are NOT explicitly visible in source code, only inferred. All five tools share a single generic input schema (input_file_ids array) with no per-tool parameter variation documented. Descriptions are generic placeholders ('Dynamic tool group for...') under 100 chars, failing the 10 - 1024 char baseline and providing no actionable guidance on WHEN to use each tool or WHAT it returns. No output schemas documented. No error handling guidance. No parameter descriptions beyond 'Workspace file IDs to process.' The catalog-driven approach obscures actual tool capabilities, without seeing the generated catalog entries, we cannot verify tool names follow verb_noun patterns, parameter constraints, or output structure. This is a fundamental architecture issue: MCP requires explicit tool registration with complete schemas, not runtime-generated tools from external catalogs.
Dynamic tool group for document conversion operations (e.g., PDF to Word, Excel, PowerPoint conversions). Tool names are generated from catalog entries with format 'convert__<toolId>'
Dynamic tool group for document editing operations (e.g., text editing, form filling, annotation). Tool names are generated from catalog entries with format 'edit__<toolId>'
Dynamic tool group for document organization operations (e.g., page reordering, merging, splitting). Tool names are generated from catalog entries with format 'organize__<toolId>'
Dynamic tool group for document reading and analysis operations (e.g., OCR, text extraction, metadata reading). Tool names are generated from catalog entries with format 'read__<toolId>'
Dynamic tool group for document security operations (e.g., encryption, signing, password protection). Tool names are generated from catalog entries with format 'security__<toolId>'
Tool definitions inferred from runtime catalog, not explicitly registered. MCP spec requires static tool registration with complete schemas at server startup. Dynamic tool generation from external catalogs violates the protocol contract and prevents clients from discovering tool capabilities.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. Baseline: 100% of A+ tools have documented return types.
Generic descriptions (10 - 50 chars) fail to explain WHEN to use each tool or distinguish between similar tools (convert vs organize vs edit). Baseline: 194 chars average, 34 - 392 char range for A+ tools. Current descriptions are 40 - 60 chars and generic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 23 | 2026-07-28+ | v2 |
Single generic input schema (input_file_ids array) reused across all five tools. No per-tool parameters, constraints, or enums. Baseline: 4 params per tool average. This prevents LLMs from understanding tool-specific options.
No error handling guidance. Errors will not tell LLMs what to do next (retry, ask user, abort). No categorization of retryable vs fatal errors.