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, uploading, downloading, 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.
What MCP gives you here
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 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.
Why a hosted converter instead of a local library
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.
Wrapping up
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:
- Repo:
- The API it calls: https://convertica.net/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.
SOCIAL SHARE CARD GENERATOR