By the end of this chapter you understand what an MCP server is made of, when building one is the right move, and how to make one that stays safely read-only, so the model can reach a tool of yours that no ready-made connector covers.
AVATAR OPENER · ~90s
Watch: a small home-built connection the model can call, and how to keep it read-only
HeyGen avatar · generated, consistent presenter
In the beginner course you plugged Claude into a live source using a ready-made connector, framed as a standard port the frozen model uses to reach the living world. This chapter is the other side of that. When no ready-made connector exists for the tool or data you care about, you build the connection yourself. That built connection is an MCP server, and making a small one is far more within reach than it sounds.
MCP, the Model Context Protocol, is just an agreed shape for how a model and an outside tool talk to each other. Because it is a shared standard, anything you build to that shape can be reached by the model without you writing custom glue for each side. You are not inventing a new integration from scratch. You are filling in a small, well-defined template, and the model knows how to talk to anything that follows it.
Beginner plugs in a connection someone else made. Here you build the one nobody made yet.
A connector you build is just a small, honest description of what your tool can do and what it can show, written in a shape the model already understands.
WHAT A SERVER IS MADE OF: THREE PRIMITIVES
An MCP server exposes up to three kinds of thing, and the easiest way to hold them is as parts of speech. Tools are verbs, things the model can do. Resources are nouns, things the model can read. Prompts are templates, ready-made ways to ask for something. Most small servers you build will only need the first one or two.
Tools (verbs)
Actions the model can take through your server: look up a record, add a row, fetch today’s figure. Doing, not just reading.
Resources (nouns)
Data the model can read: a file, a record, a live value. Reading, not changing. The safest primitive to start with.
Prompts (templates)
Reusable, ready-made ways to ask your tool for something, so the model does not have to reinvent the request each time.
Pick by control
Choose the primitive by how much power you are granting. A read-only server exposes resources and read-tools, nothing that can change or delete.
You choose which primitives to expose based on how much you are willing to let the model do. This is the whole safety story of building a connector: a server that only offers resources and read-only tools can look but never touch. One that offers action-tools can change things. Starting read-only is not timidity, it is the sane default, and you add the ability to change things only deliberately, one action at a time.
WHEN TO BUILD ONE, AND WHEN NOT TO
Building a server is the right move only sometimes, and knowing when saves you effort. The honest test is whether a ready-made connection already exists and whether a plain command-line tool would do the job with less overhead.
Does a connector exist?
If a ready-made one already covers your tool, use that. Do not rebuild what is maintained for you.
Would a CLI do?
If the tool already has a command-line way in, that is often lighter than a server. Reach for a server when there is a real gap.
Build the gap only
When nothing covers your specific tool or data, build a small server for exactly that, and no more.
There is a real cost to remember from the connector world: every tool you expose to the model takes up room in its working memory, even when it is not being used. So a server bristling with twenty tools is not a flex, it is a tax on every conversation. Build small. Expose the few things you actually need, keep the rest off, and the model stays sharp.
BUILD A SMALL ONE, AND TEST IT
The good news for a non-coder: you do not hand-write a server from a blank file. There is an official skill for building connectors, and you can direct it the way you have directed everything else in this course, by describing what you want and letting it scaffold the thing. Your job is to be clear about the one job the server does and to insist it stays read-only unless you say otherwise.
Scaffold a small, read-only MCP server
I want to build a small MCP server that gives you read-only access
to one thing I care about that no existing connector covers.
The thing: [describe it, e.g. "the current stock levels in my
inventory spreadsheet" or "the latest entries in my project log"].
Requirements:
- Read-only to start. Expose it as a resource or a read tool. Do
NOT give it any ability to change, add, or delete anything.
- One job only. Do not add tools I did not ask for.
- Walk me through building it with the official connector-building
skill, and tell me before each step what it will do.
- Then show me how to test it with the MCP Inspector before I
connect it to anything real.
Explain each piece in plain terms as we go. I am not a programmer.
Before you wire a new server into your real setup, you test it in isolation. The MCP Inspector is a small interactive tool made for exactly this: it lets you poke at your server, see the tools and resources it exposes, and call them by hand to confirm they behave, all before the model ever touches it. Testing a connector in the Inspector first is the equivalent of the Roast Me habit for connections: you find the problems in a safe sandbox, not in production.
What testing first saves you
In the Inspector you call your new read tool and see it returns the
right value, cleanly, with nothing it should not expose.
You also notice it happily returned a field you did not mean to
share, and you trim it, before the model or anyone else ever saw it.
Only then do you connect it for real. The sandbox caught the leak.
The full hands-on build, a real server file you run and connect, needs the terminal and a project, which you now have from the last two chapters. The companion repo has a minimal working server under mcp/ that you can clone, run, and inspect, so you have a real, safe example to learn from rather than a blank page. Start from that, change one thing, and watch it work.
NOW YOU TRY · DESIGN
Spec a small server for a real gap
Find one real thing you wish the model could reach that no ready-made connector covers, a value in a spreadsheet you keep, a log you update, a small database of your own. Use the prompt above to spec a read-only server for exactly that one thing. Be strict: one job, read-only, no extra tools. Decide which primitive fits (a resource to read, or a single read tool). You do not have to build it yet; the tight spec is the win.
Right if you have a spec for a genuinely useful small server that is read-only, does exactly one thing, and that you would test in the Inspector before trusting it.
Show the worked solution
The drill works when the spec is boringly small and obviously safe, because that is what a good first server looks like. Say the gap is "I want the model to be able to see the current total in my running expenses sheet without me pasting it in every time." Notice how much this does not need. It does not need to edit the sheet, add expenses, or delete anything, so you expose it as a single read-only resource: the current total, and only the total. One job. You pick the resource primitive because you are reading a value, not taking an action. Then, before you connect it to your real workflow, you open it in the MCP Inspector and call it by hand: does it return the number, is it the right number, and, the question people forget, does it accidentally expose more than you intended, like every line item when you only wanted the sum? If it does, you trim it right there in the sandbox. That whole shape, one job, read-only, tested in isolation first, is the difference between a connector that quietly extends what you can do and one that quietly leaks or breaks things. The temptation is always to make the server do more while you are in there. Resist it. A small server you fully understand and have tested beats an ambitious one you half-trust, every time.
WATCH FOR
✗You build a server for something a connector already covers. Check first. If a maintained connection exists, use it. Build only for the real gap nobody else filled.
✗You expose a pile of tools "to be useful". Every tool taxes the model’s working memory and widens the risk. One job per server, and only the tools that job needs.
✗You give a first server the power to change things. Start read-only. Expose resources and read tools. Add anything that can change or delete only deliberately, one action at a time.
✗You connect a new server straight into your real setup. Test it in the MCP Inspector first. Confirm it behaves and does not leak, in the sandbox, before the model or anyone else touches it.
WHAT YOU LEARNED
The takeaways
An MCP server is a small connection you build, in a shared shape the model already knows how to talk to, for a tool or data no ready-made connector covers.
It exposes up to three primitives: tools (verbs, actions), resources (nouns, data to read), and prompts (templates). Most small servers need only one or two.
Choose primitives by how much power you grant. A read-only server exposes resources and read tools and can look but never touch. That is the safe default.
Build one only when no connector exists and a plain command-line tool would not do. Keep it to one job, because every exposed tool taxes the model’s memory.
Test a new server in the MCP Inspector before connecting it for real, the way you Roast Me a plan: find the leaks and bugs in a sandbox, not in production.
Your project · build a connection
Spec a small read-only server for one real gap in your thread project, and if you are ready, clone the example in the companion repo and inspect it. You can now extend what the model can reach, safely. Next chapter opens up everything else Claude Code can do as an automation surface: oversight modes, context control, and hooks that make a rule run every single time without fail.
A ready-made connector is a door someone else hung for you. Building your own MCP is learning to hang a door where there was only a wall, small, read-only, and tested before you trust it. That is the difference between using the connected world and extending it.