CLI, geen MCP

De opzet

Ik heb een kleine agent die mijn Outlook-inbox triageert. Begon met het voor de hand liggende: een kant-en-klare Outlook MCP-server (Python, 4 tools). Het werkte. Maar elke beurt was duur, en de latency was erger dan wat de actie — “vat deze thread samen” — zou moeten kosten.

Waar de tokens bleven

Wat er per beurt werkelijk verstuurd werd:

1. De tool-schemas staan permanent in de context. Alle 4 MCP-tools, elke beurt, of de agent nu mail aanraakte of niet. ~700 tokens overhead voordat de gebruiker iets had gezegd.
2. De e-mailbody was ruwe HTML. De MCP gaf terug wat Outlook stuurde — 6.200 bytes voor een gemiddelde mail, grotendeels tracking pixels, inline CSS, signature-afbeeldingen. De LLM had daar niks aan.

De omruil

Ik verving de MCP door een Rust-CLI: dezelfde 4 acties (list, read, draft, send), vanuit de agent aangeroepen zoals elk ander shell-commando.

• HTML → platte tekst, attachments en inline-afbeeldingen eruit: 6.200 → 2.386 bytes per body.
• Velden bijgesneden (afzender, onderwerp, platte body) — wat de LLM daadwerkelijk leest is nu ~500 bytes.
• Omdat het een CLI is, blijft het tool-schema niet langer in het inputvenster hangen. De agent ziet een shell die hij al kent.

Cijfers

Metric	MCP	CLI
Gem. mailbody naar de LLM	6.200 B	~500 B
Tool-schemas in context	~700 tok	0
Installatie	Python-env	3,7 MB binary
Regels code	—	~250

Code is open: zhaidewei/molk.

Wat ik hieruit meeneem

Kant-en-klare agent-tools zijn ontworpen om alles te tonen. Dat is de juiste default als je niet weet wie ze aanroept, maar het is de verkeerde default als jij ze aanroept en precies weet wat je model moet zien. De goedkope zet was om de tool ook als iets te behandelen dat ik zelf moet beheren — niet alleen iets dat ik installeer.