Build your minimal MCP server: the loop closes

What we are building, and why it is short

The requirements fit in two lines, inherited from our thread: give the model the means to fetch the raw notes of a meeting, and to distribute the produced summary. Two tools, not one more, you know the rule since step 6: every tool is a privilege, and privileges must be justified.

The language: Python, with the protocol's official SDK. Why it, for learning: its way of declaring tools is the most readable in the ecosystem, a function, a decorator, a docstring, and the SDK builds all the rest (the JSON-RPC from step 5, discovery, schemas). The concept being identical in TypeScript and elsewhere, what you learn here transposes as is.

The skeleton: ten lines that make a server

"""The thread's MCP server: meeting notes + delivery."""
import os
from mcp.server.fastmcp import FastMCP

# The name the host and the logs will see (step 6: name clearly)
mcp = FastMCP("meeting-notes")

# Secrets come from the environment, never from the code.
# This is the "env" of the configuration seen at step 6.
NOTES_TOKEN = os.environ["NOTES_API_TOKEN"]

if __name__ == "__main__":
    mcp.run()   # stdio transport by default: the host runs us as a child

Three observations before going further:

That really is all. Create the server object, run it. Session negotiation, answering tools/list, JSON-RPC validation: the SDK handles it. Your work concentrates where your value is, the tools.

The secret is already in the right place. os.environ["NOTES_API_TOKEN"] materializes what we have repeated since step 2: the server holds the credentials, the code does not contain them, the model will never see them. And accessing via environ[...] (rather than a silent .get(...)) makes the server crash at startup if the token is missing, a server that refuses to start misconfigured beats a server that will fail mid-task.

The transport is step 6's. mcp.run() speaks stdio: the host launches us as a child process, exactly the "local server" case of the local/remote trade-off.

Tool #1 : get_meeting_notes: the hand that looks

@mcp.tool()
def get_meeting_notes(date: str) -> str:
    """Fetches the raw notes of the meetings on a given date.

    Use it to obtain the raw material for a meeting summary,
    minutes or a meeting recap.

    Args:
        date: the meetings' date, in YYYY-MM-DD format.
    """
    notes = notes_api.fetch(date=date, token=NOTES_TOKEN)
    if not notes:
        return (f"No notes found for {date}. "
                "Check the date, or ask the user which "
                "meeting they mean.")
    return format_notes(notes)

Let's dissect, every line applies a principle already met:

The decorator builds the bridge. @mcp.tool() turns an ordinary Python function into a tool the host discovers. The function name becomes the tool name; the type annotations (date: str) become the input schema the protocol will validate at moment ② of step 5's sequence. You write Python; the SDK publishes MCP.

The docstring is the description, hence the trigger. Reread it: it says what the tool does, when to use it, in the trade's words ("meeting summary", "minutes", "recap"). It is exactly the step-② method from step 3, applied to tools: the model picks its tools by reading their descriptions, just as it picks its skills. A vague docstring produces a tool never called, or called at the wrong time. The gate test applies here too, word for word.

The empty case is an answer, not an error. "No notes for this date" is not a failure: it is information, phrased so the model knows what to do next (check the date, ask the user). Remember the move, it becomes central two sections down.

Tool #2 : send_summary: the hand that acts

ALLOWED_RECIPIENTS = ("team@example.com", "management@example.com")

@mcp.tool()
def send_summary(recipient: str, summary: str) -> str:
    """Delivers a finalized summary to one of the team's lists.

    Use only when the summary is complete and the user has
    asked for it to be sent.

    Args:
        recipient: the mailing list (among the team's lists).
        summary: the full summary, in the house format.
    """
    if recipient not in ALLOWED_RECIPIENTS:
        return (f"Recipient refused: {recipient}. "
                f"Allowed lists: {', '.join(ALLOWED_RECIPIENTS)}. "
                "Nothing was sent.")
    if len(summary) < 200:
        return ("Suspiciously short summary: send refused. "
                "Check that the full summary was produced "
                "before requesting delivery.")
    mailer.send(to=recipient, body=summary, token=MAIL_TOKEN)
    return f"Summary delivered to {recipient}."

Here is where the difference between a demo server and a server you dare to plug in is made. Two guardrails, two philosophies:

The recipient allowlist. The tool structurally refuses to send outside the planned lists, even if the model asked, even if something read in the notes pushed it there (you remember moment ④ from step 5: what enters the context can influence the model). It is least privilege applied in the code, where no instruction, no injection, no reasoning can bypass it. A skill saying "only send to the team" is a wish; an allowlist is a control, step 4's distinction, made executable.

The plausibility check. A summary under 200 characters is probably not a summary: the tool says so and does not send. Every write tool deserves its question: "what does a call I should refuse look like?", then the refusal gets coded. It is your last net before the irreversible.

And note the docstring: "only when the summary is complete and the user has asked for it to be sent". The when is bounded in the description itself, the trigger is a guardrail too.

Errors: what the model sees when things break

The most underrated topic in MCP development. When a tool fails, its error message enters the context window : and the model reasons on it to decide what comes next. Your error message is therefore not a developer log: it is a recovery instruction for the model. Compare:

# ❌ What the model cannot exploit:
#    "KeyError: 'items' at notes_api.py line 42", noise, plus the
#    risk of exposing paths, versions, even configuration fragments
#    into the context.

# ✅ What the model can exploit:
return ("The notes service is temporarily unreachable. "
        "Retry shortly; if it persists, tell the user: "
        "and do not invent content.")

The three rules of the well-mannered error message: it says what happened (in task language, not implementation language), it says what to do next (retry, ask the user, abort cleanly), it forbids invention ("do not invent content", the line that prevents a summary fabricated out of thin air on an outage day). And symmetrically: never a raw stack trace, never infrastructure details, everything you put in an error ends up in the context, hence potentially in a conversation.

Plugging in your own server

Your server plugs in exactly like the ones from step 6, you have simply moved to the other side of the counter:

{
  "mcpServers": {
    "meeting-notes": {
      "command": "python",
      "args": ["/path/to/notes_server.py"],
      "env": {
        "NOTES_API_TOKEN": "${NOTES_API_TOKEN}",
        "MAIL_TOKEN": "${MAIL_TOKEN}"
      }
    }
  }
}

And step 6's ritual applies to your own production: on host restart, check that discovery shows your two tools and nothing else; first try in read mode (get_meeting_notes on a known date); and keep the send confirmation active on send_summary, your own code deserves the same observation period as a third-party server.

The loop closes

Scroll back to the map at the top of this step: for the first time in the path, everything is lit. Let's run the thread one last time, end to end, with your pieces:

1. "Write up this morning's meeting summary and send it to the team"
2. The skill from step 3 loads, its description intercepted "meeting summary"
3. The model calls your get_meeting_notes, its docstring did the rest
4. The notes flow into the context; the model applies the house format, the edge cases, the one-page limit
5. The model calls your send_summary, the allowlist stands guard, the delivery goes out

The manual said how (steps 2-4), the hands supplied what and did (steps 5-7), the brain orchestrated, and every link, you wrote, tested, governed. What remains is armoring the whole (step 8) and knowing where the ecosystem can spare you writing the next piece (step 9).

📍 Skills & MCP path, step 7/9

1. 🗺️ The map before the territory
2. 🔬 Anatomy of a skill
3. 🛠️ Create your first skill
4. 🏛️ Skills in the enterprise: governance
5. 🔌 MCP: the protocol explained
6. ⚡ Use an existing MCP server
7. ⚙️ Build your minimal MCP server ← you are here
8. 🛡️ Secure your MCP servers
9. 📡 The ecosystem: where to find, where it moves

Next step → Secure your MCP servers: the full attack surface, indirect injection, confused deputy, exfiltration by chaining, and the countermeasures, from least privilege to supervision. The step your CISOs will read first.

Your server is running? The AI agent security sheet gives you a 90-second foretaste of step 8.