Part 1 of 3 — building and testing MCP agents
"Agent" has become one of those words that means everything and nothing. So let's ground it.
On its own, a large language model does one thing: it turns text into text. Ask it a question, it predicts an answer. It can't look anything up, check a fact against a live system, or take an action in the world. Everything it "knows" is frozen at training time.
An agent changes that by wiring the model into a loop with tools. Give it a set of functions it can call — read a file, hit an API, query a database — and a loop that feeds each tool's result back to it, and something different happens. The model can now decide it needs information, ask for a tool, read what comes back, decide whether that's enough or whether it needs another tool, and only then answer.
That loop — call a tool, or answer, repeat until done — is the core of every system people call an agent, dressed up in different frameworks. But to me it seems the loop alone is not the whole definition. A loop with no stop condition is a runaway process; a loop with no tool policy is a security incident waiting to happen. When I tried to pin down what I actually configure when I set up an agent, I ended up with two separate things.
I split the concept in two parts, like a class and its instances. An agent definition is the template; an agent instance is one running occurrence of it. (I wrote a separate article going deeper into this definition and how the newest MCP spec stress-tests it — link at the bottom.)
The agent definition consists of:
An agent instance is what you get when a definition picks up real work:
Note the symmetry: the definition holds limits, contracts and capabilities; the instance holds counters, goals and credentials. Static in the class, dynamic in the instance. Keep this split in mind — the rest of the series leans on it.
The Model Context Protocol (MCP) standardizes one half of the picture: how a host discovers and calls tools in the first place. Before MCP, every "agent plus data source" pairing needed its own bespoke integration — a Slack agent, a GitHub agent, a database agent, each wired by hand. MCP turns that into a protocol: any MCP server exposes typed, discoverable tools over a standard interface, and any MCP-aware host can connect to any MCP server without custom glue code.
Think of it as the plug standardizing, not the appliance. The agent — definition, instance, and the loop between them — still has to exist on the host side. MCP just means the host doesn't have to reinvent "how do I talk to this particular tool" every single time.
I've been building a small MCP host that does exactly this: it connects to one or more MCP servers, aggregates whatever tools they expose, and drives that call-a-tool-or-answer loop on behalf of an LLM. The interesting design decision wasn't the happy path — it was resisting the temptation to let the SDK auto-run tools invisibly. Most agent frameworks offer a mode where you hand the model a tool list and it just handles the rest, opaquely, in one call.
I deliberately don't do that. The host drives the loop by hand: send the conversation, inspect the response for tool-call requests, dispatch each one, feed the results back, repeat — capped by the termination limits from the agent definition, so nothing spirals. It's a few dozen more lines of code than the "just let the SDK do it" version. What it buys you is visibility: every tool call, every round trip, every token is something you can actually see and measure, instead of a black box between "here's a question" and "here's an answer."
That visibility turns out to matter a lot once you start asking harder questions. Not just "does the agent work," but "is this system prompt actually better than that one," "is the cheaper model good enough," "what will this cost at scale." Those are measurement questions, not build questions — and they're what the rest of this series is about.
Next up: the levers you have when configuring an agent — which, not coincidentally, are exactly the fields of the agent definition above — and the metrics that tell you whether pulling one made things better or worse.
Deeper dive into the definition itself: https://dev.to/langensjonathan/what-is-an-agent-a-classinstance-definition-stress-tested-against-the-2026-07-28-mcp-spec-5akp