Part 4 of 7 · Chapter 4 of 5

MCP and Tools

Connecting the model to your database, browser, and issue tracker so it can check reality instead of guessing.

Advanced14 min readReviewed August 2026

Worth reading first: Rules Files

Everything so far has assumed the model can only read your files. Tools change that: they let it check reality — query your database, open your page in a browser, read the actual issue — instead of reasoning about what is probably there.

Why this changes the failure mode

Recall why models invent things: when they cannot see something, they produce the most plausible version of it. Tools attack that at the root.

Without tools

“Your users table probably has an emailcolumn, so here is a query.” Plausible, confident, and possibly wrong.

With a database tool

It runs a schema query, sees the column is actually email_address, and writes a query that works the first time.

What MCP actually is

The Model Context Protocol is a shared standard for connecting an AI tool to an external system. Before it, every editor needed a bespoke integration for every service. With it, a server written once works with any client that speaks the protocol.

Practically, you install a small server, tell your AI tool about it, and the model gains a set of actions it can call. Nothing about your prompting changes — the model simply has more ways to find things out.

1
A filesystem server
Read and write files outside the current project.
2
A database server
Inspect schemas and run read-only queries.
3
A browser server
Open a page, click things, and read what actually rendered.
4
An issue-tracker server
Read the ticket rather than being told a summary of it.

Setting one up

Configuration is a JSON file naming the servers to launch. The exact path differs per tool, but the shape is consistent:

mcp.json

{  "mcpServers": {    "postgres": {      "command": "npx",      "args": ["-y", "@modelcontextprotocol/server-postgres"],      "env": { "DATABASE_URL": "${DATABASE_URL}" }    }  }}

Note the environment variable rather than a literal connection string. This file gets committed; your credentials must not be in it.

The one worth setting up first

If you only add one, make it a browser tool. It closes the loop that is otherwise longest and most tedious: the model changes CSS, cannot see the result, and asks you whether it worked.

What becomes possible

The mobile nav overlaps the header below 400px. Open the pageat 375px wide, look at it, fix the CSS, then check it againand show me the result.

That is a full observe-change-verify cycle with you out of the middle. It is also where AI assistance starts feeling qualitatively different rather than just faster.

The risks, stated plainly

Tools give a model the ability to act on the world, so the honest framing is that you are widening what a mistake can reach.

1
Scope every credential down
Read-only where possible; a scratch database rather than production.
2
Read what it proposes before approving
Especially anything that deletes, migrates, or installs.
3
Only install servers you trust
An MCP server runs code on your machine with your permissions.
4
Watch for injected instructions
Content the model fetches — an issue body, a web page — can contain text designed to look like instructions. Treat fetched data as data, never as commands.

Key takeaways

Tools let the model check reality instead of predicting it — that is the whole value.
MCP is a shared protocol, so one server works across tools rather than per-editor integrations.
Reference credentials from the environment. The config file gets committed.
Read-only by default. Widen access only when you have a specific reason.
A browser tool is the highest-value first addition: it closes the observe-change-verify loop.
Content the model fetches is data, not instructions — that distinction is a real attack surface.