I kept hitting the same tiny annoyance. I would be deep in a chat with Claude, working through some documents, and then I would need one of them as a Word file. Or a client would send a HEIC photo that nothing wanted to open. Every time it meant leaving the editor, finding a converter site, up, down, and coming back. Small friction, but it adds up over a day.
So I wired the conversion step directly into the assistant using MCP. Now I just ask for it in plain language and the file lands in my folder. This post shows how to set that up.
The Model Context Protocol lets an AI client call external tools in a structured way. Instead of the model guessing or writing throwaway scripts, it calls a real tool with real arguments and gets a real result back. A conversion server is a good fit: the model does not need to know how to render a PDF, it just needs to know that a convert_file
tool exists and what it accepts.
I used the Convertica MCP server because it wraps a whole batch of conversions behind two tools, but the pattern applies to any MCP server you like.
You need Node 18 or newer and an MCP client. I will show Claude Code and the generic config that Cursor, Windsurf and Claude Desktop all understand.
You also need an API key. Convertica issues one from the account dashboard once you have a subscription, and the same key works for the web API and the MCP server.
Claude Code, one line:
claude mcp add convertica -e CONVERTICA_API_KEY=cvk_live_xxxx -- npx -y convertica-mcp
Any other client, drop this into the MCP config:
{
"mcpServers": {
"convertica": {
"command": "npx",
"args": ["-y", "convertica-mcp"],
"env": { "CONVERTICA_API_KEY": "cvk_live_xxxx" }
}
}
}
That is the whole install. npx
pulls the package on first run, so there is nothing to clone or build.
Once the server is connected, you talk to it the way you talk about anything else. A few that I actually use:
Convert ~/Downloads/contract.pdf to Word
Merge these three PDFs into one and compress the result
Turn this HEIC photo into a JPG
Render
[https://example.com]as a PDF
The model picks the right tool, reads the local file, sends it off, and writes the result next to the original. If you are curious what is available, there is a list_converters
tool that returns the full catalog with each tool's options, so you can ask "what can you convert?" and get an honest answer instead of a hallucinated one.
Under the hood there are two tools. list_converters
returns the catalog. convert_file
takes a tool name, one or more local file paths, and an options object, then saves the output. Everything is typed, so the model gets a clear error if it asks for something that does not exist rather than failing silently.
You could do a lot of this locally with libraries. I went with a hosted API for two reasons.
The first is coverage. PDF to Word done well is genuinely hard, and so is Office rendering, HEIC decoding, and PDF/A conformance. Stitching together five libraries and keeping them working is a project in itself. One API that already handles thirty five conversions is less code I own.
The second is that it keeps the client thin. The MCP server is a small wrapper with no native dependencies, so npx
just works on any machine without a build step or a headless browser.
The tradeoff is that files leave your machine for the conversion. Convertica deletes processed files right after the response, which was good enough for my use, but if you are handling something sensitive, read the provider's retention policy first and decide for yourself.
The setup is a few minutes and the payoff is that a whole category of context switching disappears. Ask for the file you want in the format you want, keep working.
The server is open source (MIT) if you want to read it or adapt the pattern to your own API:
If you build something similar for a different service, I would like to see it. The two-tool shape (a catalog tool plus a typed action tool) turned out to be a clean way to expose a broad API to an assistant without overwhelming it.