Convertr file converter

Convert a file

convert_file

Convert a file to another format. Give exactly one of url (public link to the file) or content_base64 (file content, max 10 MB), plus output_format. The call waits up to wait_seconds (default 50, max 80) for the result. When the status is succeeded, the answer contains the download_url and the time it expires (files are deleted after 24 hours). When the status is queued or processing, call get_conversion with the id. Costs 1 credit per conversion of an input up to 100 MB (100 free credits per month); failed conversions are refunded. Needs an API key.

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_file"
  }
}

Input Schema

Name	Required	Description
`url`	No	public http(s) URL of the file to convert. Use this or content_base64, not both.
`filename`	No	file name with extension, for example clip.mp4. Required with content_base64 unless input_format is set.
`settings`	No	optional conversion settings as a JSON object, for example {"bitrate":"192k"}
`input_format`	No	source format. Default: the file extension.
`wait_seconds`	No	seconds to wait for the result, 0 to 80. Default 50.
`output_format`	Yes	target format, for example mp3, pdf or webp
`content_base64`	No	the file content, base64 encoded, max 10 MB decoded. Use this or url, not both.

Output Schema

Name	Required	Description
`id`	Yes	conversion id
`error`	No
`input`	No
`output`	No
`status`	Yes	queued, processing, succeeded or failed
`progress`	Yes	progress in percent
`created_at`	No
`finished_at`	No
`credits_charged`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false). The description adds substantial behavior beyond them: blocking wait up to wait_seconds, the 24-hour download_url expiry, per-conversion credit cost with 100 free credits per month, refunds on failure, and the API-key requirement.

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?

Front-loaded with the purpose, then inputs, then waiting/async behavior, then pricing. Six dense sentences with no filler — each carries an operational fact the agent needs.

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

Completeness5/5

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

Although an output schema exists, the description still tells the agent what to expect (download_url, status, expiry) and how to handle the non-terminal statuses, plus cost/auth constraints. Nothing needed to invoke this 7-parameter, nested-settings tool correctly is missing.

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 the schema already documents every parameter including the max 10 MB, the default/max wait, and the either/or rule. The description restates the exclusivity constraint and size limit but adds no syntax or format detail the schema lacks, and never mentions filename or settings.

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

Purpose5/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 file to another format') and implicitly distinguishes itself from the sibling read/delete tools by being the only one that creates a conversion. An agent can identify its role without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit input exclusivity ('exactly one of url or content_base64'), and routes the agent to the correct sibling for the async case: 'When the status is queued or processing, call get_conversion with the id.' Both when-to-use and where-to-go-next are stated.

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

All Convertr file converter tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?