Loading ToolBench
Headless Model Context Protocol server over the MD -> ALL conversion core: document conversion + lossless DOCX/Markdown LaTeX recovery, fully offline.
mdall-mcp demonstrates solid definition quality with 14 well-named, action-verb tools covering document conversion, equation rendering, and content analysis. All tools have descriptions (avg 156 chars, within 10-1024 baseline) and complete input schemas with typed parameters. Naming follows verb_noun convention (convert_file, extract_equations, purify_audit). However, output schemas are undocumented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are present but terse (avg 45 chars vs 72 baseline); many lack format/constraint details. Error handling is absent from descriptions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification (READ_ONLY vs WRITE). Missing idempotency guidance for batch operations.
Analyze a document without converting it: word/character counts, outline (headings), reading time estimate, and language detection.
Convert many documents in one call. Each job is converted independently; one failure does not abort the rest. Returns a per-job result summary.
Convert a document from one format to another, inferring both formats from the file extensions. Fully offline. DOCX export is reversible: the original Markdown + LaTeX is embedded for lossless recovery.
Convert a LaTeX equation to Typst syntax or Unicode representation.
Export inline Markdown to a file in the format implied by the output extension. Optional title/author metadata. Referenced figures are resolved relative to base_dir (default: the output folder).
Extract every display and inline LaTeX equation from a document, with their positions and contexts.
Output schemas completely undocumented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. E.g., convert_file returns what? A file path? A status object? This forces agents to guess or fail mid-chain.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification. Tools marked READ_ONLY vs WRITE in metadata but not exposed to LLM. Agents cannot reason about retry safety or side effects.
Parameter descriptions lack format/constraint details. E.g., 'input' param says 'Absolute path to source file' but does not specify: which formats are supported? What happens if path is relative? What if file does not exist? Agents must infer or fail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Import any supported document and return its Markdown representation (LaTeX equations preserved as $...$). Does not write a file.
Check whether a DOCX is recoverable by MD -> ALL without performing a full conversion. Reports reversibility, the recovered size, and a short preview.
List every import and export format the conversion engine supports, as structured JSON.
Audit a document for LLM watermarks and encoding artifacts (hidden Unicode, homoglyphs, unicode dashes, CRLF) without modifying it. Returns a JSON report.
Strip LLM watermarks, normalize encoding, AND remove LLM tics (verbose phrasing, filler words) and French typography (guillemets, thin spaces). Math zones and code are preserved. Writes the decontaminated result to output.
Strip LLM watermarks and normalize encoding (CRLF → LF, homoglyphs → ASCII, hidden Unicode removed). Math zones and code are preserved. Writes the cleaned result to output.
Recover the ORIGINAL editable Markdown + LaTeX from a DOCX previously exported by MD -> ALL. This is the reversibility differentiator: a supervisor can annotate the DOCX in Word and the author recovers their exact source. Returns the recovered Markdown.
Render a LaTeX equation to a PNG or SVG image using the embedded Typst engine. The LaTeX is re-embedded in the image metadata so the result stays recoverable.
No error handling guidance in descriptions. Tools do not document what errors are possible, when they are retryable, or what the LLM should do next. E.g., convert_file: what if input file is corrupted? What if output path is not writable?
convert_batch lacks idempotency and partial-failure guidance. Description says 'one failure does not abort the rest' but does not specify: are failed jobs retryable? Does re-running the batch re-process successful jobs? Can this cause duplicates?