This lesson is part of Learn MCP, our free course on the Model Context Protocol, within The MCP Guide.
In this lesson you will plan a real MCP server from start to finish. You will write a one-page design document that covers the problem, the users, the tools, the transport, sign-in, security, logging, versioning and launch. Each section points back to the lesson that taught it.
This is the final lesson of the core Learn MCP course. You won't write new code here. Planning is the step most first servers skip, and it is where most of the expensive mistakes are made. A good plan also lets you hand the build to a teammate or a vendor and get back what you meant.
The result should fit on one page. If it doesn't, your first version is probably too big.
Key Takeaways
- Start from one job a person does repeatedly, not from an API you want to expose.
- Keep version one small: a few narrow tools with clear names, schemas and read/write separation.
- Decide local or remote early, because it drives transport, sign-in, hosting and threat model.
- Put security, logging and versioning in the plan from day one; they are much harder to bolt on later.
- Define how you will test (MCP Inspector, both protocol eras) and what "done" means before anyone writes code.
The example we will plan
To make this concrete, we'll plan an illustrative server: an overdue-invoice assistant for a small bookkeeping team. Staff want to ask an AI app "Which clients are more than 30 days overdue?" and "Draft a polite reminder for this client." They do this every week by hand today.
You will then repeat every step for your own idea in the Try it section.
Step 1: Write the problem in two sentences
Name the person, the task and the pain. For the example: "Bookkeepers spend about an hour each week finding overdue invoices and writing reminders. They want to do it from their AI assistant without opening the accounting system."
If you can't name a person and a repeated task, stop here. A server without a clear job becomes a pile of loosely related tools. Lesson 1 covers which problems MCP is good at.
Step 2: Choose the smallest set of tools
List the tools, with a name, one-line description, inputs and whether each reads or writes. Apply the design rules from Lesson 23:
| Tool | Reads or writes | Inputs | Notes |
|---|---|---|---|
list_overdue_invoices | Read | min_days_overdue (integer, 1–365) | Returns ID, client, amount, days overdue |
get_client_contact | Read | client_id | Name and billing email only |
draft_reminder_email | Read | invoice_id, tone (enum: friendly, firm) | Returns draft text; does not send |
Notice what is missing: no send_email and no void_invoice. The person reviews and sends. You can add a write tool in version two, once you trust the logs.
Also decide on resources and prompts. A prompt such as "weekly overdue review" could guide the model through the three tools in order. Lesson 17 shows how to add one.
Step 3: Pick local or remote
Answer three questions from Lesson 12:
- Does more than one person need it? If yes, lean remote.
- Does it need files on one person's computer? If yes, lean local.
- Who will run and patch it? Remote servers need hosting, monitoring and an owner.
The example is used by a team and talks to a cloud accounting API, so it should be remote, over Streamable HTTP.
Step 4: Plan sign-in and scopes
For a remote server, write down:
- How users sign in (OAuth 2.1, per Lesson 22 and the authorization spec).
- The starting scope (for example
invoices:read) and any step-up scope for later write tools. - The downstream credential the server uses, and its permissions. For the example: a read-only API key for invoices and contacts.
- A firm rule: the server never forwards the user's MCP token to the accounting API. The Security Best Practices page forbids token passthrough.
Step 5: Write the threat model
Use the one-page method from Lesson 24. For the example, the top threats might be:
- Prompt injection hidden in an invoice note that tries to make the model pull every client's contact details.
- A stolen token used to export the client list.
- Reminder drafts that leak another client's data due to a bug.
Then list the mitigations: per-call limits on results, output that includes only the requested client, rate limits, and audit logs.
Step 6: Plan logging and alerts
From Lesson 26, specify:
- One structured audit record per tool call, written to stderr or your platform's log collector, with secrets redacted.
- Two or three alerts, such as "more than 200
get_client_contactcalls by one user in an hour." - A log retention period agreed with whoever handles compliance.
Step 7: Plan versions, testing and launch
Write down:
- The protocol versions you support. As of October 2026, plan to serve 2026-07-28 clients and older 2025-era clients, as the versioning spec allows (Lesson 27).
- Your server's starting version (
0.1.0for a pilot,1.0.0for general release). - Your test plan: MCP Inspector in both protocol eras, plus a short script of real prompts staff will try.
- Distribution: the MCP Registry does not accept private servers, so an internal tool is shared through your own client configuration or an internal registry instead. A public server can follow Lesson 28.
Step 8: Define done and the owner
Finish the page with success criteria and names:
- "Bookkeepers can produce the weekly overdue list and drafts in under 10 minutes."
- "Zero tool calls return another client's data in testing."
- "Owner for updates and incidents: [name]."
If you plan to hire help, this page is the core of your brief. Our MCP RFP template shows what else a vendor will need.
Try it
Write your own one-page plan using this outline:
- Problem: two sentences, naming a person and a repeated task.
- Tools: a table of three to five tools with read/write, inputs and notes.
- Resources and prompts: any you need, or "none."
- Transport: local or remote, with one sentence why.
- Sign-in and scopes: method, starting scope, downstream credential.
- Top three threats and mitigations.
- Logging: what each record contains and two alerts.
- Versions and tests: protocol versions, server version, test plan.
- Done means: two measurable criteria and an owner.
Then ask a colleague to read it and tell you what the server does in their own words. If they can't, simplify.
Recap
Across 30 lessons you learned what MCP is, how to use and choose servers, how to build tools, resources and prompts, and how to secure, monitor, version and publish a server. This capstone tied it together into a single plan you can build from or hand off. The plan is short on purpose: small, clear servers are easier to secure and easier for an AI model to use well.
If you want to prove what you learned, the next four lessons prepare you for the official MCPA exam.
Course navigation
Previous lesson: Lesson 29: Long-Running Tasks and MCP Apps.
Next lesson: MCPA Study Guide: Domain by Domain.
Back to the Learn MCP course outline.
Frequently asked questions
How many tools should my first server have?
As few as the job needs. Three to five narrow tools is a common, manageable starting point. More tools mean more for the model to choose from and more to secure.
Should my first version include write tools?
Only if the job can't be done without them. Read-only first lets you watch real usage in the logs. Add write tools later, with confirmation prompts and narrower scopes.
Do I need a plan for a small personal server?
A short one, yes. Even a local server runs with your account's access to files and credentials. Five minutes on the threat model and logging steps can save you from a painful mistake.
What if I want someone else to build it?
Use this plan as your brief and ask vendors how they would handle each section. Our guide on build vs buy helps you decide between a custom server and a managed platform.
Is there a real example of a production MCP server I can look at?
Yes. LedgerMCP (built by eSEOspace) is an accounting MCP server; see the LedgerMCP client spotlight. The official MCP servers repository on GitHub also has many open-source reference servers to study.
