Every session starts the same way. I ask the agent to merge a few PDFs and strip the EXIF off some screenshots, and it goes hunting for a library, installs it, writes a script, gets a result that is slightly off, patches the script, then opens the output just to confirm it worked. Next session, same thing from zero.
So I wrapped the file operations behind an MCP server. The interesting part was not the wrapping. It was deciding how many tools to expose.
The obvious version is wrong
I had 26 file operations already built for a website: merge PDF, split PDF, rotate, compress, protect, unlock, PDF to JPG, image resize, strip metadata, HWP to PDF, XLSX to CSV, QR code, and so on. The obvious move is 26 operations, 26 tools.
That is a mistake, and the reason is boring but decisive: tool definitions live in the model's context on every single turn. Not when the tool is called. Every turn. Twenty-six schemas with their descriptions and argument docs is a fixed tax you pay on the first message and every message after it, in a conversation where the user may only ever need one of them.
There is a second cost that is harder to see. More tools means more chances to pick the wrong one. pdf_compress versus pdf_optimize versus image_compress is a distinction that is obvious in a docs page and genuinely ambiguous in a tool list.
Group by job, not by operation
The version I shipped has six tools. Related operations share a tool and an argument picks between them.
| Tool | What it does |
|---|---|
doc_read |
Text out of DOCX, PDF, HWP, HWPX and EML, tables included |
doc_convert |
Documents to PDF, PDF pages to images, sheets to CSV or JSON |
pdf_edit |
Merge, extract, delete, rotate, reorder, split, compress, protect, unlock |
pdf_info |
Page count, page sizes, encryption, metadata |
image_edit |
Resize, compress, convert, strip EXIF and GPS, cut out the background |
qr_make |
A link or some text as a PNG or SVG |
pdf_edit covers nine operations behind one schema. The model picks the tool by the noun it is holding (a PDF) rather than by the verb it is guessing at, and the verb goes in an argument where a wrong guess is a validation error instead of a wasted round trip.
What it measured out to
I put the same four files in two sessions and handed the same task sentence to the same model. One session had only this server. The other had no dedicated tools and was free to use the shell and Node.
| Without tools | With the server | |
|---|---|---|
| Cost | $0.28 | $0.13 |
| Wall time | 9:06 | 0:39 |
| Tasks finished | 2 / 4 | 4 / 4 |
| Tool calls | 20 | 10 |
| Tokens | 510,607 | 184,605 |
53% less cost, 93% less time. The token and cost figures are not estimates, they are the per-message numbers the sessions recorded, summed.
One thing to read carefully: the bare session never started two of the four tasks. It burned the clock finding and installing libraries for two Korean documents (HWP, a closed binary format that is standard in Korean government and school paperwork, and has basically no drop-in library outside Korea). So the gap is a floor, not a ceiling. Had it been forced to finish all four, the distance would be wider, and most of the extra distance would come from a format problem rather than from the tool design.
The rule I would give someone else
Count how many tool schemas a user has to carry to get value from your server on their first message. If that number is bigger than the number of distinct nouns your server operates on, you are shipping a menu instead of an interface.
Nouns for me were: a document, a PDF, an image, a QR code. Four nouns, six tools, because PDFs needed a read-only companion and documents needed both a reader and a converter. If I had built it operation-first I would have shipped 26 and it would have been worse in a way that is very hard to notice, because nothing breaks. It just quietly costs more on every turn.
Running it
claude mcp add ezpzfile -- npx -y ezpzfile-mcp
Node 22.13+, MIT, everything runs locally and no file is uploaded. Source is at github.com/ezpzfile/ezpzfile-mcp, package is on npm, and the tool list with every argument is at ezpzfile.com/mcp.
Background removal is the one exception to "nothing touches the network" — it downloads a model the first time you ask for a cut-out, then caches it. It still uploads nothing.
If you have built an MCP server, I am curious where you landed on tool count and whether you measured it or eyeballed it. I eyeballed it first and got it wrong.
Top comments (0)