The entire difference between an AI chatbot and an AI agent, on my machine, is twelve lines of JSON. This is the actual, complete .mcp.json at the root of this website's repository:
{
"mcpServers": {
"laravel-boost": {
"command": "php",
"args": [
"artisan",
"boost:mcp"
]
}
}
}
Before that file existed, Claude was a very well-read consultant: it could tell me about Laravel, and I did the copying, pasting, running, and reporting back. After that file existed, Claude could query my database schema, run Tinker, list my routes, and read my error logs, directly, mid-conversation, without me playing courier. That is the whole chatbot-to-agent transformation, and it is smaller and less mystical than most explanations make it. Let me give you the version I wish I had read first.
What MCP Actually Is, Minus the Hype
Model Context Protocol, which Anthropic open-sourced in November 2024, is a standard interface between an AI model and the outside world. The comparison that finally made it click for me is USB-C: before it, every tool-to-model connection was a custom cable, an integration someone had to hand-build for one model and one tool. MCP standardizes the plug. A tool exposes an MCP server once; any MCP-capable client, Claude, and by now most major AI clients since the ecosystem converged on the protocol through 2025, can use it.
Technically, an MCP server tells the model three things: here are my tools (typed functions you may call), here are my resources (data you may read), and here is how to call them. The model decides when to call them. That last clause is what makes an agent an agent: the loop of decide, act, observe, decide again happens on the model's side, not yours.
The Three Levels: Chatbot, Assistant, Agent
I think about the shift in three levels, because "agent" gets used for all of them.
Level 1, chatbot: the model knows things. You ask, it answers, you do all the doing. Every AI interaction before tools.
Level 2, tool-using assistant: the model can act, but each action is a one-shot errand you supervised: "query this table," "fetch this page."
Level 3, agent: the model chains actions toward a goal without you scripting the chain. "Find why the contact form 500s" becomes, on its own: read the log through one tool, check the route, inspect the schema, run a Tinker snippet to reproduce, propose the fix. Nobody wrote that sequence. The model composed it from available tools.
MCP does not make the model smarter. It makes level 3 possible by giving the model a big enough toolbox that composing becomes worthwhile.
What This Looks Like on a Real Codebase
The Boost server from my twelve lines ships tools like database-schema, database-query, tinker, list-routes, last-error, and search-docs, version-aware Laravel documentation search. The compound effect on a working day is hard to overstate, and it shows up in mundane moments, not demos.
A concrete one from this repo: mid-refactor, Claude needed to know how my polymorphic comments were actually stored before touching the model. Old world: I switch to a database client, inspect, screenshot or paste, explain. New world: it calls database-schema, sees the morph columns, and writes the migration correctly on the first pass. Thirty seconds, no context switch, and, crucially, no opportunity for me to paraphrase my own schema wrongly, which I have absolutely done. I wrote up the full setup in my Laravel Boost MCP guide if you run a Laravel stack.
The insight that only shows up after months of daily use: the value is not any single tool call. It is that the model stops working from my description of the system and starts working from the system.
Beyond the Local Server: The Remote Roster
Local servers like Boost are half the picture. The other half is remote connectors, MCP servers run by the services themselves. My own Claude environment currently has Figma, HeyGen, Higgsfield, Canva, Semrush, Supabase, and Postman wired in this way, among others. Same protocol, zero local setup, and suddenly "generate the b-roll images for this script" or "pull this design's tokens" are tool calls inside one conversation. That roster is what powers my code-first Figma workflow and, at the system level, the AI operating system I run on Claude Code.
How to Start Without Making My Mistakes
Start with one server, project-scoped. Put a .mcp.json in one repo with the single server that touches your daily pain. Resist the catalog. I did not resist the catalog, which brings me to:
Tool sprawl is real and it costs you twice. Every connected server injects its tool definitions into the model's context. My peak was a setup where tool definitions crowded the context before I typed a word, and the model got worse, more options, more dithering, more wrong tool picks. Today my rule is: a server earns its slot by being used weekly, and everything else gets removed. Ten well-chosen servers beat forty impressive ones; I keep a shortlist in my best MCP servers roundup.
Treat write-capable tools like production access, because they are. A tool that can query can often mutate. Prefer read-only modes where offered, review what each server exposes, and keep destructive capabilities behind explicit approval. The agent is exactly as careful as the worst tool you handed it.
Where This Is Going
The protocol is settling into the boring, load-bearing role good protocols end up in: invisible. The interesting frontier has moved up a layer, to which tools you compose, what guardrails you run them under, and what standing workflows you build on top. That is a topic I keep returning to, because once the plumbing is standard, the craft is in the system you assemble above it.
The twelve lines of JSON at the top of this post are, genuinely, where mine started. Most of what I have shipped since, the agent pipelines, the automated content systems, the design round-trips, runs through MCP servers somewhere in the stack. My projects page is what those twelve lines eventually compounded into — nearly everything recent listed there has this protocol quietly underneath it.
