The situation

Your notes server works. You want to share it, or you want to evaluate somebody else’s before
running it. Same checklist either way.

What “trust” means for a stdio server

A stdio MCP server runs as a subprocess with your permissions. Installing one is exactly as
consequential as installing any other package, and rather more than most people treat it.

Before you run one:

That is not paranoia. It is the same reading you would do before adding a dependency, applied
to something that will be handed to a model and invoked automatically.

What makes a server good to publish

Six things, roughly in order of how much they help the person using it:

1. Descriptions with trigger sentences. Everything in Module 2. Your descriptions are the
entire interface for the model, and the person installing your server cannot fix them without
forking you.

2. A narrow scope. A notes server should touch notes. A server that adds “and also runs
shell commands, for convenience” is now a shell server with a notes feature.

3. Useful errors. Lesson 2.5, over a pipe. "There is no note 7. There are 3 notes."
saves a turn every time.

4. Read-only where possible. Split reading from writing. If someone only needs to query,
do not make them accept a server that can also delete.

5. Honest names. delete_note deletes a note. Do not call a destructive tool
update_note because it sounds gentler — the model reads the name too.

6. A README that says what it touches. Which files, which network hosts, which
credentials. Three lines, and it is the thing every careful person looks for and rarely finds.

Confirmation belongs to the client

You may be tempted to build “are you sure?” into your server. Do not.

The permission layer belongs in the client, where the human is — that is Lesson 3.4, and it is
the right place because the client knows the user, the interface, and the policy. Your server
cannot prompt anybody; it is talking down a pipe.

What you can do is make it obvious which tools need care: name them clearly, describe the
consequence in the description, and keep destructive operations separate from safe ones so a
client can treat them differently.

Versioning the menu

The tool list is your API. Removing a tool or renaming an argument breaks every agent using
you, and it breaks in a particularly annoying way — the model calls a tool that no longer
exists and improvises around the failure.

Add rather than change. If you must change, keep the old name working for a while. The
protocol has a version field, but your menu is the contract, and nothing enforces it but
you.

A stdio MCP server runs with the user’s permissions. Publishing one is a promise, and the
tool list is the promise you are making.

Try this before the next module

Write a README for your notes server. Three sections: what it does, what it touches, how to
run it.

Then read it as somebody who has never seen it. Would you run this on your own machine? If
not, fix the server, not the README.