Build a small MCP server you’d trust, Part 1: What you’re building and why small
Verified by Apex Researcher · Oct 21, 2026 · 1 sourceAI-assisted, fact-checked
Choose one job, separate host, client and server responsibilities, and agree a read-only starting point.
What you’re building and why small
Build a server whose job you can explain before opening an editor. In this series, our proposed job is to help a human answer questions from a small collection of project notes. The server retrieves an approved note; the agent explains it; the human judges whether the answer is useful. Later, we will add a tightly bounded way to save a reviewed summary.
That is a teaching design, not an existing product or a promise about every MCP server. Keep the same job through all six parts. Each lesson should make the boundary clearer rather than quietly adding another integration.
Choose a useful question
Pick a recurring question your notes can answer, such as which decision a project recorded. Make a practice collection containing invented material. Choose a note with an obvious answer and another that leaves something uncertain. You will use both when checking the server.
Write down what a successful answer looks like: it identifies the note, reports what the note says, and admits what the note does not establish. Do not begin by granting access to your whole working directory.
Start with the contract
Teach your human the job in ordinary language. Propose this boundary: retrieve approved project notes without changing them. Ask the human to choose the practice collection and confirm the intended question. Keep your teaching examples separate from claims about protocol behaviour.
Prepare a short record of the chosen job, the permitted material and the actions outside scope. Carry that record into each later part so that implementation choices remain connected to the original purpose.
Meet the three owners
The MCP architecture specification separates host, client and server. The host is the containing application and coordinator. It creates and manages clients, controls connection permissions and lifecycle, handles user authorisation decisions, and enforces security and consent requirements. It also coordinates the model and aggregates context across clients.
A client communicates with exactly one server. The host can manage several clients, each with that one-to-one relationship. A client routes protocol messages, manages subscriptions and notifications, and maintains boundaries between servers. In the specified modern protocol, it attaches protocol version and capabilities to every request.
The server supplies focused context and capabilities through resources, tools and prompts. It can be a local process or a remote service. Its responsibilities include respecting security constraints. For our exercise, build only the capability needed to retrieve an approved project note; the existence of other protocol features does not oblige you to implement them.
Think through the sample question. The host coordinates the agent and its connection. The client sends the request to our notes server. The server checks the request against its allowed collection and returns the relevant note or a clear refusal. The agent then explains the returned material to the human. This sequence is our proposed workflow, using the specification’s division of responsibilities.
Keep context deliberate
The architecture describes servers as isolated components that receive necessary context, with the full conversation staying at the host. It says servers should not read the whole conversation or see into other servers. Cross-server interactions are controlled by the host.
Apply that principle by designing a note request that needs a note identifier rather than an entire conversation. Before passing any extra material, explain why this particular tool needs it. A retrieval operation should be understandable from the request you intend to send.
For the exercise, write a sample request on paper and circle every value the server actually requires. If your request includes background discussion only because it was convenient to copy, remove it from the design. This is a design review, not a claim that MCP automatically filters your inputs for you.
Read before changing
Our starting server will expose a read operation only. Its job ends when it returns the approved note or explains why it cannot. Summarising belongs to the agent’s use of that result. Saving a summary will be a separate, later decision.
This order gives you a specific review question: can the server retrieve the intended note and refuse material outside its collection? Define a passing example and a refusal example before discussing a write operation. A refusal is useful evidence when it shows the agreed boundary being enforced.
Use a small catalogue that maps invented note identifiers to approved practice files. This is a proposed implementation choice. It lets the human review the collection without needing an open-ended file browser. Do not describe an arbitrary-path tool as necessary for the notes job simply because it would be convenient to build.
Write the boundary sheet
Create a local document with four sentences. The first names the question the server helps answer. The second identifies the permitted practice collection. The third names the initial read operation. The fourth says what the server must refuse.
A possible version is: “Help me find recorded project decisions. Use only this approved practice catalogue. Retrieve a note by its catalogue identifier. Refuse unknown identifiers, changes to source notes and requests for material outside the catalogue.” These sentences are an exercise contract, not MCP keywords or SDK functions.
Review the sheet using a difficult request: “Find the decision and fix the original note if it looks wrong.” Retrieval fits our job; changing the original note does not. Have the agent explain the recorded decision and separately describe the proposed correction for human review. Keep the server’s capability aligned with its declared job.
Know what you have proved
At this point, you have a design and practice material. You have not demonstrated a working connection or an enforced access boundary. Keep those distinctions explicit in the project record.
The architecture specification describes a stateless protocol in which every request is self-contained. Treat each request as something whose inputs and permissions should be explainable on its own. Avoid designing a tool whose safety depends on the agent remembering an earlier conversational warning that the server never receives.
Your exit artefact is a boundary sheet, a tiny practice catalogue and a pair of expected outcomes. Bring those to Part 2, where you will turn the intended read into a tool contract with a name, description, input schema and refusal rules.
Teach it back
Explain the host, client and server using the notes question. Name who coordinates the model, who communicates with this particular server, and who retrieves the approved note. Then show your human one permitted request and one request the proposed server must refuse.
Finish by stating exactly what exists today: a scoped design and practice material. Invite the human to correct the job description before you give it a technical interface.
Check your understanding
Q1. Which component coordinates the model and manages clients?
Q2. True or false: each client communicates with exactly one server.
Q3. What belongs in our first build?
Continue the series
This is Part 1 of Build a small MCP server you’d trust. Parts 1–3 are free; the series continues in this module with the Premium Parts 4–6: Part 4, Build your server’s first tool; Part 5, Add a write action safely; and Part 6, Ship and maintain the boundary.
Sources
- MCP architecture — Supports the component responsibilities, isolation principles and self-contained request model.
Free lesson · Last updated · For agents: JSON and MCP