MCP and Tool Integration — Giving Your Agent Tools

In the previous chapter, we ran a minimal agent that connects tools to the brain (LLM) and turns its own loop. That experience should have made one thing clear — an agent's capability is decided almost entirely by "what tools it's connected to." In this chapter, we escape the grind of hand-building those tools every time and learn to connect to external tools and data in a standard way, through a common standard called MCP (Model Context Protocol). MCP was born with Claude and is now becoming the industry-wide standard for connection.

Why tool integration is the crux of an agent

An LLM on its own, no matter how smart, can only "produce words." Knowing the latest stock count, writing a single line to a file — none of that is possible without a means to touch the outside world. An agent can turn its "investigate, execute, verify" loop only because it holds tools that act on the outside.

In other words, the ceiling of an agent's capability is set by the quality and number of tools it's connected to. With the same LLM, an agent that has only a calculator and one connected to a database, search, files, and internal APIs can do wildly different things. It's not unusual for connecting good tools precisely to boost perceived capability far more than swapping in a fancier brain.

The limits of raw tool definitions

In the previous chapter, we defined tools by hand. Write a function, pass its name, arguments, and description to the LLM, and run it and return the result when a call comes in — this flow itself is correct, and still fundamental. The problem is rebuilding this from scratch every time, per tool, per project.

Take a "tool that searches a database," for example. Write the connection handling, assemble the query, format the result, handle errors, deal with credentials safely… Everyone implements this whole set on their own — in your project, in the team next door, in a different language. The same tool is being reinvented over and over by developers worldwide — that's the reality of raw tool definitions.

This is a lot like the era when every peripheral needed its own dedicated cable. A dedicated port for the printer, another for the mouse — the more devices, the more the kinds of connections explode. With a "common port," this hassle disappears all at once. That's where MCP comes in.

What MCP is — a common standard for tool connection

MCP (Model Context Protocol) is an open standard for connecting AI to external tools and data in a standard way. Anthropic released it for Claude at the end of 2024, and various AI tools and services adopted it afterward. As of 2026 it's widely adopted across vendors and is growing into an industry standard cultivated under neutral governance. What matters is that it's a common specification anyone can implement, not the product of a single company.

In a phrase, the idea of MCP is "USB for AI tool connection." Just as USB let peripherals from any manufacturer work through the same port, a tool that supports MCP "plugs in and works" with any MCP-capable agent. By having builders and users follow the same set of conventions, N×M combinatorial hell folds down to "N + M."

The two converse via a fixed procedure. When the client connects, it first receives from the server "a list of usable tools" and "the description and arguments of each." The LLM looks at that list, picks a tool that fits the goal and calls it, and the server executes and returns the result — this round-trip working without per-tool custom implementation is the crux of MCP.

Client -> Server : "Tell me the tools you have"
Server     -> Client : "search_docs / read_file / query_db — three, with these descriptions"
LLM decides: "Let's call query_db with args {sql:"..."}"
Client -> Server : "Run query_db"
Server     -> Client : "Here's the result: these rows"

There are mainly two ways to expose a server: the local type, run as a process on your own machine, and the remote type, connected to over a network. Local suits your own files and a development DB; remote suits team-shared SaaS integrations and the like. Both share the same convention of "receive a tool list and call," and the client-side handling barely changes.

Using and building MCP servers

The best part of MCP is that you can use servers already published out in the world as-is. For most commonly used tools, someone has already prepared an MCP server. Connect it to your own agent and its capability grows all at once, without reinventing the wheel.

The connection procedure itself is simple. Just start the server you want (or specify its URL) and register the server's location and credentials in the client-side settings. After that, the agent receives the tool list on connection and calls tools as needed. You don't need to write "the guts of a DB search tool." Your job becomes combining the provided tools to fit your goal.

You can build your own server too

For a tool with no ready-made server — an in-house proprietary API, special business logic — you can simply write your own MCP server. This is MCP's beauty: once you publish it as a server, any compatible agent can use it the same way. A tool built for one project can be reused in the next project, and by another agent on the team, with no rewrite.

The guts of building a server are: "define the capability you want to provide as a tool, declare its name, arguments, and description, and when called, run the processing and return a result." The idea is the same as the raw tool definitions you wrote in the previous chapter, but the decisive difference is that the output goes not to "a specific agent" but to "the common MCP port." The effort to build is one-time; the reuse is endless.

What tools to give, and how

Once you can "connect" tools, the next question is "what to give, and how." This is the design crux that governs an agent's quality and safety, and it's also the foundation for the chapters ahead. Let's pin down three principles.

③ is especially important. "Investigating" tools (search, reference, reading) rarely cause much harm if called by mistake. But "changing" tools (writing, deletion, sending, execution) can produce irreversible results from a single misstep. The rule is to deliberately separate read-only from write tools and layer extra guards on the latter.

Advanced tools such as browser control

Among tools, one that has drawn particular attention recently is browser control. Look at the screen, follow links, fill in forms, press buttons — if you can hand the operations a human performs in a browser to an agent, many web services with no dedicated API turn into its "hands and feet." Implementations that provide browser control as an MCP server have appeared, and the barrier to connecting has come down.

That said, this is also one of the most powerful and highest-risk tools. The danger of taking on-screen instructions at face value (manipulation, disinformation), unintended clicks or submissions, exposure of credentials — the cautions for "execution" tools in the previous section apply squarely. The wise course is to start with read-leaning uses like browsing and information retrieval, and add careful guards around operations that involve writing.

Browser or not, the more advanced a tool, the more "what it can do" and "what might happen" grow in proportion. The stronger the tool you hand over, the more carefully you apply the three principles of privilege, description, and guards — that's the message this chapter has repeated throughout.

Once you know how to equip tools, the next stage is "scaling up the agents." We move on to designs that divide and coordinate work — too much for one agent — across several. In the next chapter, Chapter 4, "Multi-agent design," let's learn division of labor and coordination between agents (A2A).