uuTools.net

Convert Document Tool

convert_document

Convert a document, e-book, spreadsheet or drawing to another format, e.g. DOCX → PDF, PDF → DOCX, EPUB → MOBI, XLSX → CSV, PDF → JPG (pages as pictures). See list_formats for every pair. Send the file as file (attached in the chat), url or base64. Returns download_page when done.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "output_format": "<output_format>"
    },
    "name": "convert_document"
  }
}

Input Schema

Name	Required	Description
`dpi`	No	Resolution of page pictures (JPG/PNG outputs).
`url`	No	A public http(s) link to the file. Use this, file or base64.
`file`	No	A file attached in the chat (filled in by the app; use this instead of base64 when the user attached the file).
`pdfa`	No	PDF output as PDF/A (archiving).
`pages`	No	Page pictures: all pages (a ZIP) or only the first.
`title`	No	E-book title (EPUB/MOBI/AZW3 outputs).
`author`	No	E-book author.
`base64`	No	The file as base64 (or a data: URL), for small files only. Prefer file or url.
`filename`	No	Original file name, e.g. report.docx.
`input_format`	No	Input format, e.g. docx; not needed when filename has the extension.
`output_format`	Yes	Target format, e.g. pdf, docx, odt, txt, epub, mobi, xlsx, csv, jpg, png.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only a title annotation, the description carries the full burden, and it does disclose the three input delivery modes and that a download_page is returned when the conversion finishes. It omits failure behavior, file-size limits (only the schema hints base64 is for small files), and whether any follow-up polling via get_conversion is ever required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the action and followed by examples, the format-lookup pointer, input mechanics and the return value. Nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with a nested file object and no output schema, the description supplies the missing return-value signal (download_page) and the input-delivery story, which is the important part. Remaining gaps are optional-parameter behavior such as dpi/pages/pdfa, which the schema already covers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every one of the 11 parameters is already documented in structured form; the description's note about sending the file as file, url or base64 largely restates schema guidance. It adds only incidental flavor ("pages as pictures") without explaining dpi, pages, pdfa or the e-book metadata fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Convert a document, e-book, spreadsheet or drawing to another format") and backs it with concrete pair examples (DOCX → PDF, EPUB → MOBI, PDF → JPG), so an agent knows exactly what class of work this does. It scopes its input domain precisely but never mentions convert_image, so the boundary with that sibling is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: check list_formats for supported pairs and supply the file via file, url or base64. It names list_formats as a prerequisite reference but gives no when-not-to-use rule or exclusion relative to convert_image or get_conversion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All uuTools.net tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?