You now know what MCP is and how its three kinds of capability differ. The next instinct is to install a server and start connecting things. Slow down — that instinct is exactly what this lesson retrains.

An MCP server is not a decorative plugin. It is a software package or a remote service that, once connected, can read files, recall notes, fetch web pages, or touch a repository on your behalf. Inspection comes before connection. Every time.

Servers are packages and services, not plugins

The word "plugin" sounds harmless — a little add-on you toggle. An MCP server is more consequential than that. It is real software: either a package that runs on your machine or a remote service you reach over the network. It carries an author, a release history, requested permissions, and bugs like any other software.

That is why "free" tells you nothing about safety. A free server that can read your entire home folder is far more dangerous than a paid service that can only convert time zones. Free does not mean harmless. Judge a server by what it can touch, not what it costs.

Start with the official reference examples. They are free, local, and designed for learning — but even they deserve inspection, because one of them can touch your files.

Five local reference servers

The table below uses servers from the official MCP reference set. Each one teaches a different lesson about boundaries:

Read the boundary column as law, not suggestion. The Filesystem server pointed at an empty practice folder is a teaching toy. The same server pointed at your home folder is a loaded tool. The difference is one configuration line — which is why you read configuration instead of copying it blindly.

The Registry is for discovery, not trust

When you are ready to look beyond the reference set, the starting point is the official MCP Registry. It exists so you can *find* servers.

It is not a trust badge. Listing in a registry means a server is discoverable; it does not mean anyone has audited what it does with your files, credentials, or network access. An impressive demo video proves even less. What matters is the source code, the documentation, the release history, and the permissions it requests — the same evidence you would demand from any software you install.

The five-question inspection

Before any server gets connected, answer these five questions in writing:

1. Who publishes and maintains it? A named author or organization, a visible repository, recent releases. An anonymous package with no history is a no. 2. What tools, resources, and prompts does it expose? List them. If you cannot enumerate what the agent would gain, you are not ready to grant it. 3. What accounts, files, or network access does it need? Credentials, folder paths, network destinations. Every item here is a door you are opening. 4. Does it run locally, remotely, or both? Local means you can see the boundary. Remote means data leaves your machine and you inherit the operator's security. 5. What is the narrowest useful first test? One read-only call with known expected output — list a folder you filled with dummy files, convert a time you can verify, fetch a page you have already read.

Configuration deserves its own warning. Conceptually, your AI host stores a server's command or URL plus any required environment variables (Class 14's secrets lesson applies in full). Never copy a block of configuration from a forum, video, or chat message without reading every line: which program it runs, which paths it exposes, which secrets it requests, and where those secrets would be sent.

The harmless first-connection pattern is always the same: connect a local reference server or a test project, list its capabilities, then ask the agent to explain them before calling any write action. "List what this server offers and explain each capability. Do not change anything yet." Only after that explanation reads correctly do you permit a single read.

Check your understanding

1. Why is "it is free" not a safety argument for an MCP server? 2. What is the difference between the Registry listing a server and trusting it? 3. Which two reference servers can change things on your machine, and what boundary makes each safe to learn with? 4. What should you ask the agent to do immediately after a first connection — and what should you forbid?

Exercise: fill in an inspection card

Choose one reference server — Filesystem, Memory, Time, Fetch, or Git — from the official MCP project. Fill in this card before connecting it:

MCP SERVER INSPECTION CARD
Server name:
Publisher / source repository:
Local or remote:
Tools / resources / prompts exposed:
Accounts, files, or network access needed:
Single practice folder or repository it may access:
Paths that are explicitly off-limits:
Narrowest first test (read-only):
How to disable or remove it:

For Filesystem or Git, the card is incomplete unless it names the single practice folder or repository and explicitly states which paths are off-limits (for example: "may access ~/practice-mcp/ only; home folder, SSH keys, and all other projects are off-limits").

Finish line: one completed inspection card, every field answered, no connection made until it is. In Lesson 15.4 you will turn this habit into a standing policy for every agent with tools.