Automation & Agents
04Chapter · Automation & Agents
3 min read
automationagentsmcptools

Agents Are Only as Useful as Their Tools

An agent that can only talk is a chatbot. An agent that can act needs tools — and a clean way to reach them. This is exactly where MCP fits the automation story.

Last updated ·

An agent that can only talk is a chatbot with ambitions. An agent that can act needs tools — and a clean way to reach them without wiring each one by hand.

A tool is anything that lets an agent reach beyond words into the real world: read a database, call an API, send an email, check live inventory. Without tools, an agent asked “is this in stock?” can only produce a confident-sounding guess; give it an inventory tool and it reads the actual number, then acts on truth instead of plausibility. The ceiling on what an agent can do is simply the set of tools you put within its reach — which is why, in automation, tools are not a detail. They're the whole capability.

But how you give it those tools matters as much as which ones. There are three levels, and they age very differently as a system grows:

Approach What it is As it scales
Raw API callthe agent hits an endpoint directlybrittle — auth & shape baked into the prompt
Wrapped toola clean function you wrote around itbetter — but one wrapper per agent
MCP serverthe tool wrapped once, in a shared standardany MCP agent reaches it — no re-wiring

The trouble the third row solves shows up the moment you have several agents and several tools. Wire each agent to each tool with its own bespoke integration and the count grows as a product, not a sum: three agents and four tools is twelve custom connections, each breaking on its own schedule. That's the same N×M tangle the MCP lesson described — and exactly the wall automation hits as it grows past a single script. Wrap a tool as an MCP server once, and any MCP-speaking agent uses it without a custom integration; the tangle of bespoke wires collapses into one interface both sides already understand.

A good tool is designed for the model that will use it. A short checklist I run before exposing one:

A clear name and description — the agent chooses tools by reading these, so write them for a stranger.

Arguments that are hard to misuse — shape them so the easy way to call it is the correct way.

Least privilege — expose only what the job needs; every extra capability is extra blast radius.

Validate what comes back — check the tool's response before the agent acts on it.

Where it goes wrong

Pouring effort into the agent's prompt while starving it of tools — polishing how it reasons about a question it has no way to answer. A perfectly worded agent with no inventory tool still guesses. The second trap is letting integrations sprawl, every tool wired its own way, until the system is a museum of one-off connectors. Standardise on a protocol while the tangle is still small.

Try this

List what an agent you're building must do in the real world — read this, change that, notify someone. Each verb is a tool it must reach. Count how many bespoke integrations that implies if you wire each by hand, and you'll feel exactly why a shared protocol like MCP exists: it turns that multiplying list into a single thing to learn.

Grounded in Anthropic's Model Context Protocol and Building Effective Agents (the agent-computer interface).

New chapters land here as I learn them. Want the next one?