Loopt op van aansluiten naar zelf bouwen. De laatste kaart is alleen relevant als je tegen de grenzen aanloopt van veel servers tegelijk — sla hem gerust over.
1. MCP in gewone taal
MCP is de stekkerdoos waarmee Claude Code bij je andere systemen kan: je ticketsysteem, je database, je documenten. Het klinkt zwaarder dan het is. In de praktijk zet je een paar regels config neer en heb je er tools bij. Begin met één server die je echt gebruikt, niet met vijf tegelijk — anders weet je bij een fout niet waar je moet kijken.
2. MCP-config in de repo of erbuiten
Servers die bij het project horen — de database van dat project, de docs — zet ik in de repo, zodat een collega ze meteen heeft. Servers die bij mij horen, zoals mijn urenregistratie, blijven in mijn persoonlijke config. Klinkt vanzelfsprekend, gaat toch vaak mis. En sleutels horen in geen van beide: die komen uit je omgeving.
3. Zelf een MCP-server bouwen
De officiële uitleg van het protocol zelf. Zwaarder dan de Claude Code-pagina, en dat mag: hier gaat het over hoe je zelf een server schrijft. Ik heb er een gebouwd die mijn urenregistratie en facturatie aan elkaar knoopt. Dat was minder werk dan verwacht, vooral omdat je met een bestaande SDK begint in plaats van met het protocol zelf.
4. Goede tools schrijven voor een agent
Zodra je zelf tools maakt, kom je erachter dat de beschrijving belangrijker is dan de implementatie. Een tool die technisch werkt maar vaag beschreven staat, wordt op het verkeerde moment aangeroepen. Dit stuk gaat precies daarover: benoemen, afbakenen, en niet twintig tools maken waar er vier volstaan. Herkenbaar als je ooit een API voor collega's hebt ontworpen.
5. Als je te veel MCP-servers hebt
Elke aangesloten server kost context, ook als je hem die sessie niet gebruikt. Bij tien servers merk je dat. Dit stuk beschrijft een andere aanpak: de tools als code aanbieden en pas laden wat nodig is. Alleen relevant als je tegen die grens aanloopt — heb je twee servers draaien, sla dit dan over en kom later terug.
