One MCP, many parsers. Routes between markitdown, Docling, and LlamaParse. Plus an interpret tool that pipes parsed markdown into Claude.
parse-mcp has clear, action-oriented tool names (parse, interpret, benchmark) and reasonable descriptions (avg ~100 chars). Input schemas are present with type definitions for all parameters. However, parameter descriptions are sparse or generic ('Optional backend hints (reserved for future use)' for hints param), and output schemas are not documented. Error handling guidance is minimal. The server follows basic tool patterns but lacks LLM-optimized descriptions and comprehensive schema documentation needed for A-grade quality.
Run every available backend on the same input, compare.
Parse a document, then ask Claude over the parsed markdown.
Report which backends are available in the current env.
Convert a document to markdown. Routes across backends automatically.
Parse a document and write it to the vault as a markdown note.
Shortcut for parsing an HTTP(S) URL. Same return shape as `parse`.
Output schemas not documented. LLMs cannot infer what fields parse(), interpret(), benchmark() return, forcing guesswork on downstream tool chaining.
Parameter descriptions are generic or placeholder. 'hints' param says 'reserved for future use' with no guidance on valid values or format. 'backend' descriptions lack enum constraints or examples of valid backend names.
Error handling lacks recovery guidance. No indication of which errors are retryable, user-fixable, or fatal. LLMs cannot self-correct on failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
list_backends and benchmark lack clear descriptions of what they return and when to call them. Discovery tools should guide LLM on usage patterns.
parse_to_vault has complex default behavior (vault_folder defaults to '<VAULT_ROOT>/📥 Inbox/Converted/') that may not be obvious to LLMs. Overwrite default=True could cause unintended data loss if LLM omits the parameter.