From the archive4 sections · 2 min readBy Dezső Mező · Published .mdAILLMMCPStandardNews
For years everyone's been wiring up their own integrations for LLM agents: this tool, that DB, that billing pipe. Every project starts over. MCP solves this · a client/server protocol where agents see tools and data through a single interface.
01Why it's picking up
- USB-C for tool-use: one protocol, anywhere.
- No vendor lock · OpenAI, Anthropic, local models all call the same servers.
- Auditable: every tool-call becomes loggable and explainable.
- Security: clean enforcement points at the client/server boundary.
02How we use it
New client projects start MCP-native. We expose internal tools (retrieval, DB queries, CRM calls) as MCP servers, and the agent client can be anything. Big upside: swap the LLM provider later without rewriting the tool layer.
03When not to bother
If your agent just calls a prompt and doesn't touch anything else, MCP is overkill · a REST call is simpler. Once you have 3+ tool interactions, the switch pays for itself.
MCP doesn't replace retrieval, evals, or guardrails. It complements them: on the server side, you still need all three.
04Takeaway
Starting a new AI agent in 2026? Go MCP-first. Already have something running? Converting the tool layer is worth the next major release · not an emergency, but a clear direction. Happy to help you migrate.
What to take away
- MCP (Model Context Protocol) standardises how LLMs access tools, data sources, and context · the USB-C of agent-land. If you're building an AI agent in 2026, MCP-first is the bet: less vendor lock-in, swappable tools, easier audit.
More from the lab
Browse all entries- Q2 2026 roundup: what shifted, what we shipped, what broke
- H1 2026 in review: what changed for EU software teams
- AI agent pricing 2026: what an autonomous agent costs
- Self-hosted AI or the API? When to run your own LLM in 2026
Want this looked at on your own system?Start a conversation
