Plug in before you build
A misplaced engineering reflex: "I need access to meeting notes, I will code a server". Wrong first move. The MCP ecosystem counts thousands of published servers — file systems, databases, Git repositories, messaging, browsers, CRMs — and for any standard need, there is almost always a hand already built, tested by thousands of users, maintained by a vendor or an active community.
Building remains legitimate — that is the whole point of step 7 — but for one precise case: when the hand must fit your own system (your internal API, your business database, your rules). For everything else, plugging in costs ten minutes where building costs days, maintenance included.
Ten minutes — but not any ten minutes. You remember from step 4 that adopting a third-party skill without reading it means running unaudited material. Plugging in a server is one notch more engaging: a skill influences what the model says; a server determines what it can do. Hence a ritual — four steps, ten well-invested minutes:
① Choose: provenance before features
Three checks, in the exact spirit of the step 4 checklist — a server is audited like a skill, with one extra notch of scrutiny:
Provenance is accountable. The vendor's official server (from the service you target), the reference repository of an identified organization, or a community project with a known, active maintainer. The signal that should make you run: the anonymous fork of a popular server "with two improvements" — the favorite distribution channel of booby-trapped versions.
Maintenance is alive. Recent commits, handled issues, tracked compatibility with the protocol's evolutions. A server frozen for ten months in an ecosystem that moves every quarter is debt at plug-in time.
The version gets pinned. You adopt a precise version — a tag, a commit — never "latest". The reason is the version drift from step 4: trust granted today is not a proxy for what the repository will publish tomorrow.
② Inspect: read the tools like permissions
The most important step of the ritual, and the most neglected. Before plugging in, open the server's documentation and read its tool list — not its marketing promises, its tool list. It is the exact equivalent of a mobile app's permission screen: nobody installs a flashlight app that requests contacts and microphone; the same common sense applies here, tool by tool.
The reading grid:
Every tool must be justified by your need. You want to read meeting notes; the server exposes get_notes, search_notes — coherent — but also delete_notebook and share_externally? Every tool you will not use is privilege granted for nothing: free attack surface. Some hosts let you enable only a subset of a server's tools — when possible, do it; otherwise, the number of superfluous tools weighs on the choice of server itself.
Reading and writing are not equals. An all-read server is a hand that looks; a server with writes is a hand that acts. Spot every side-effect tool (create, modify, delete, send) and ask, for each one: am I comfortable with the model triggering that on the strength of its reasoning? You remember moment ④ from step 5: what the model reads can influence it. A write tool is the link that turns an influence into an action.
Scope is restricted at the source. The best access control is configured in the target system, not hoped for from the server: a token that only sees the "Meetings" notebook, a read-only PostgreSQL account on a single schema, Git access limited to one repository. If the server falls or derails, it cannot do more than its credential allows — least privilege applied where it cannot be bypassed.
③ Configure: four lines that say everything
The configuration of a local server fits in a few lines of your host application's file. Here they are, annotated — the vocabulary is the same across hosts, syntax details aside:
{
"mcpServers": {
"meeting-notes": {
"command": "npx",
"args": ["-y", "@vendor/notes-server@1.4.2"],
"env": {
"NOTES_API_TOKEN": "${NOTES_API_TOKEN}"
}
}
}
}Line by line:
"meeting-notes"— the server's local name, the one you will see in logs and authorization prompts. Name clearly: six months from now, "server3" will mean nothing to anyone."command"+"args"— what will be executed on your machine when the host starts. Reread that line with step 4 eyes: this is code running at your place. Note the@1.4.2— the pinned version from step ①, written into the configuration itself."env"— the secrets, passed to the server through environment variables. The server holds them; the model never sees them (moment ③ of the sequence, step 5). Never a plaintext token in a configuration file that will end up in a Git repository or a screenshot — the${...}reference points to your environment.
A remote server is configured differently — a URL and authentication, typically OAuth — but the inspection logic is identical: same tools, same questions.
The local vs remote trade-off
You saw it pass by at step 5 on the transport side (stdio vs HTTP); here it is on the decision side:
The pocket rule fits in one line: what touches your workstation stays local; what touches the team gets shared remotely — because a team secret copied to twenty workstations is no longer a secret, and an update to run twenty times is never run twenty times.
④ Test: the first handshake
The server is configured, the host restarted. Three checks before real use:
Discovery tells the truth. On connection, the host displays the discovered tools (the tools/list from step 5). Compare with the list inspected at step ②: what appears here is authoritative, not the documentation. A tool present that was not documented is an immediate stop signal.
The first try is a read. Ask the model for something harmless and verifiable — "list the titles of my notes from this week". You validate the whole chain at once: connection, authentication, token scope, result format.
Observation precedes widening. Use the server for a few days on its restricted scope and watch the authorization prompts go by: serious hosts ask for confirmation before calls — at minimum the side-effect ones — and that friction is a feature. The comfort of auto-approving will come soon enough; let it come after trust, not before. And keep the step 5 reflex in mind: a server whose tool list changes mid-session deserves a conversation before you continue.
📚Going deeper
For the geeks: secret hygiene, in practice. Four rules that prevent 90% of leaks. One secret per scope: the notes server's token serves only the notes server — sharing an all-purpose token across servers guarantees that one compromise exposes everything. The configuration file is a sensitive document: if it references variables, fine; if it holds a plaintext token, it is chmod 600, excluded from the Git repository, and absent from the screenshots in your support tickets — the three dumbest and most frequent leak channels. Rotation is scheduled: an MCP server token is regenerated like a service password, on a fixed schedule and immediately after any doubt. Revocation is tested: the day you unplug a server, its token is revoked in the target system right away — a retired server whose credential survives is a dormant backdoor. You recognize the logic: it is classic service-account management, applied to the model's hands.
📚Going deeper
For the geeks: the package-launcher trap. The typical configuration uses a launcher (npx, uvx and equivalents) that downloads and executes the server's package. Real convenience, but measure what the line actually says: at every start, code is fetched from a public registry and executed on your machine. Three practical consequences. Always pin the version in the command (@1.4.2): without it, the launcher may resolve "latest", and your step ① was for nothing — the local equivalent of the moving branch forbidden at step 4. Prefer a local install for critical servers: a package installed, versioned and verified once beats a network resolution at every launch — and still works when the registry is down. Treat the registry as a supplier: typosquatting (one character of difference in the package name) is a documented, active attack path; copy names from the official source, never from memory. An MCP server's package deserves the level of suspicion of a production dependency — because that is what it is.
📍 Skills & MCP path — step 6/9
- 🗺️ The map before the territory
- 🔬 Anatomy of a skill
- 🛠️ Create your first skill
- 🏛️ Skills in the enterprise: governance
- 🔌 MCP: the protocol explained
- ⚡ Use an existing MCP server ← you are here
- ⚙️ Build your minimal MCP server
- 🛡️ Secure your MCP servers
- 📡 The ecosystem: where to find, where it moves
Next step → Build your minimal MCP server: the moment the geeks have been waiting for — the two tools of our connecting thread in a few dozen annotated lines, and the skill + MCP loop finally closing.
To explore the server ecosystem meanwhile: our 40 Claude & MCP tools sheet, GitHub stars live.