MCP server for Convertica — convert PDF ⇄ Word, Excel, PowerPoint, JPG, HTML, Markdown, EPUB, PDF/A, merge/split/compress/protect PDFs and convert images (HEIC, WebP, …) straight from Claude, Cursor or any MCP client.
Convertica MCP has two well-named, action-oriented tools with clear descriptions and structured schemas. However, several quality gaps prevent a higher score: (1) The `convert_file` tool's input schema uses `additionalProperties` with oneOf for `options`, which is less precise than explicit parameter definitions, this forces LLMs to guess at valid option names without enumeration or per-option descriptions. (2) Parameter descriptions in the schema are present but terse (many under 50 chars); they lack actionable guidance on constraints, formats, or dependencies. (3) No output schema is documented, LLMs cannot know what fields `convert_file` returns beyond what the code reveals (saved, bytes, tool). (4) The `list_converters` tool accepts an empty input schema but returns JSON text rather than structured object fields, making the output harder to parse programmatically. (5) Error handling is functional (apiKey() check, file validation, HTTP status hints) but lacks guidance on retry behavior or when errors are retryable.
Run one of convertica.net's 35+ conversion tools on local file(s) and save the result next to the input (or into output_dir). Requires authentication via the CONVERTICA_API_KEY env var. Use list_converters for tool slugs and options. Examples: {tool: 'pdf-to-word', files: ['/docs/report.pdf']}; {tool: 'pdf-organize/merge', files: ['/a.pdf','/b.pdf']}.
List all available file conversion tools (PDF ⇄ Word/Excel/PowerPoint/JPG/HTML/Markdown/EPUB/PDF-A, merge/split/compress/protect PDF, image convert/optimize/HEIC, and more) with their input fields and options. Call this first to find the right `tool` value for convert_file.
Output schemas not documented. `list_converters` returns JSON text in a content array; `convert_file` returns {saved, bytes, tool} but this structure is not formally documented. LLMs cannot predict response fields or plan downstream operations.
Parameter schema for `options` in convert_file uses `additionalProperties` with `oneOf` ([string, number, boolean]). This is overly permissive, there is no enumeration, validation, or per-option description. LLMs cannot know which options a tool accepts without calling list_converters first, then inferring from the response.
Parameter descriptions are minimal. `output_dir` is described as 'Directory to save the result (default: alongside the first input file)' (59 chars). `files` is '(absolute paths of input file(s). Order matters for multi-file tools.)' (67 chars). These lack format guidance (must exist? relative or absolute?), constraints (max items?), or dependency hints (e.g., 'Required for multi-file tools; single-file tools use first file').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
`list_converters` accepts an empty input schema `{}` but returns raw JSON text via `content[].type:text`. This is inefficient for LLM parsing and wastes tokens. Should return a structured object with a `converters` array field, each with `slug`, `description`, `files`, `params` properties.
Error messages are helpful (hints for 401, 403, 429) but do not classify errors as retryable, user-fixable, or fatal. An LLM cannot decide whether to retry, ask the user, or give up.