We Gave Agents a New Protocol & Handed Them the Same Old Plumbing

I was playing with tool calling around August 2024, months before the Model Context Protocol (MCP) existed (it was released on November 25, 2024). Back then, there was no shared standard across vendors, so every tool was something you designed by hand, and you felt every wasted turn. We got a standard, and a lot of us skipped the design part, the part MCP server best practices are really about.

Since then, I’ve tried out a lot of MCP servers. Virtually every one that comes out for infrastructure, networking, and related systems, I’ve looked at and used, to see how and where it fits. I keep landing on the same quiet disappointment. Most of them aren’t broken. They aren’t insecure. They just stop short. The industry found a brand-new way to give agents tools, and we mostly used it to hand them the same plumbing we already had.

Let me break down the three types I keep running into, worst to best.

Type 1: The 1:1 API Mapping

This is the most common one, and honestly, it makes me a little sad. Take an existing REST API, point a generator at the OpenAPI spec, and ship whatever falls out. It’s easy to see why. Here’s the whole thing:

Picture a simple, hypothetical question: “who has access to this resource?” With a 1:1 mapping, the dance might go like this. Call get_users_with_access, get back a list of groups. Call get_users_in_group, get back a list of user IDs. Call get_username_from_id, over and over, to finally resolve names and emails. The agent wanted names and emails in the first sentence. Instead it spent three different turns, N tool calls, a pile of tokens, and several chances to wander off course. We gave the model our internal data model and hoped for the best.

Here is that sequence, with illustrative numbers (2 groups, 5 users):

Type 2: Semantic Search MCPs

This is better. Instead of exposing every endpoint, you expose a search tool. The agent describes what it needs in plain language, and another model or agent behind the server figures out which tools, API paths, or queries are relevant and hands them back.

I like the intent here. It respects that the agent knows its goal better than your URL structure does. It scales to huge APIs without drowning the context window in tool definitions.

But it’s still multi-turn. The agent asks what’s available, gets pointed at the right call, then makes the call, then interprets the result. You’ve moved the guesswork around rather than removing it. It’s a better map, but the agent is still doing the driving.

Here is the same question, with an illustrative turn count:

Type 3: Pure Agentic Abstractions

This is the good stuff, and there’s so little of it out there. Here you design tools around outcomes, not endpoints. A single get_users_with_access call returns a clean list of users with their names and emails, because the server did the group-resolving, ID-chasing join work internally and handed back the thing the agent actually asked for.

The win is threefold. You minimize agent turns (each round-trip of tool call and response), so there’s less latency and less room to derail. You minimize tokens, because the agent isn’t wading through intermediate payloads it never cared about. And you return meaningful data, shaped for the decision the agent is trying to make.

Yes, this is more work. You have to think about what agents actually want to accomplish instead of mechanically wrapping your routes. That thinking is the entire job. Without it, what we ship is a proxy, not an agent tool.

Here is the same question again: