Building your first MCP server

0:00 Build your first MCP server

Ready-made MCP servers exist for plenty of popular apps. But the systems that make your business different, your booking rules, your price list, your client portal, need a server you control. The good news: with the official SDKs, a useful, safe server is a few dozen lines. In this lesson you'll design, build, test, connect and harden a first MCP server for a small photography studio.

0:29 Why build your own

Why build your own? Because the systems that make your business different are exactly the ones nobody else will build a server for. Here's an analogy. Ready-made servers are like standard plugs in a hotel room. Useful, but they only fit what they were made for. Building your own server is like fitting a socket exactly where your equipment is, with a switch you control. It's less work than it sounds, and the rules of good tool design still apply.

1:04 Design first

Design first. Use the tool principles you already know. Our studio server offers check availability, which is read-only; hold slot, which places a twenty-four-hour provisional hold rather than a confirmed booking; a packages resource listing durations and price ranges; and a prompt template for drafting booking replies in the studio's voice. And notice what's missing: no cancellations, no refunds, no payments. Start read-first with one low-risk write, and expand only when you have evidence it's safe.

1:37 Simplest server

A simple example before the studio server. The smallest useful MCP server has one tool: add two numbers. You write a Python function with type hints for two integers and a one-line docstring, decorate it as a tool, and run the file. Open it in the Inspector, call add with one and two, and you get three back. No JSON schema written by hand, no protocol code. Once that works, everything else is just more useful functions with better descriptions and validation.

2:13 The code

Now the code. With the Python SDK's current major version, you create an MCP server object, then decorate ordinary Python functions. The type hints become the input schema. The docstring becomes the description the model reads, so write it like a good tool description: what it does, when to use it, formats and limits. Validation lives in the function: a helper rejects badly formatted or past dates with a message that tells the model what to ask the client. Raise the SDK's tool error for anything the model can fix, and your message comes back flagged as an error the model can read and recover from.

2:59 Resources, prompts, run

Resources and prompts are just as simple. A decorated function registered with a URI like packages colon slash slash list becomes a resource the host can include as context. A decorated prompt function becomes a template the user can pick, often as a slash command. And one line at the bottom runs the server over standard input and output, the default for local servers.

3:27 Test three ways

Test in three ways. Interactively, the MCP Inspector launches your server so you can list tools, call them and read resources by hand. Automatically, the SDK's client can connect to your server object in memory, so you write normal tests, like confirming that a badly formatted date returns an error. And with a real model, connect the server to a desktop chat app or IDE and try awkward requests. Book me for yesterday. The family one, whatever time. Cancel someone else's booking. Watch what the model does with your descriptions and errors.

4:07 Going remote

When several people or apps need the server, run it remotely over Streamable HTTP, which the SDK can do with a single transport setting. But before it leaves your machine, add authentication and authorisation as the current specification describes, TLS, rate limits and logging. The good news from the 2026 revision is that the protocol is stateless, so you can run several identical copies behind an ordinary load balancer.

4:37 Harden

Finally, harden. Validate every argument and never build SQL or shell commands from model text. Enforce the calling user's permissions inside the server. Keep destructive operations out of version one, or make them explicit tools that hosts can require approval for. Log every call and review the logs weekly for the first month. And version your server with a changelog, because a changed tool description is a changed behaviour.

5:07 Common mistakes

Common mistakes on a first server. Returning an error message as a normal string, so it looks like success; raise the SDK's tool error instead. Printing debug output to standard output on a stdio server, which corrupts the protocol stream; use logging. Exposing a generic query tool that accepts SQL. Forgetting to validate dates and IDs. And deploying remotely without authentication because it worked fine on localhost.

5:36 How you'll know it's good

How will you know your server is good? Tools are selected correctly when you test with a real model, including awkward requests. Invalid inputs produce clear tool errors, and the model recovers by asking the user. Automated tests pass on every change. Logs show who called what, with no sensitive data leaking into them. And a colleague can read the tool descriptions and predict exactly what each tool does.

6:06 Business example (illustrative)

A deeper business example, illustrative. The Dubai studio connected this server to its website assistant and staff's desktop assistant. In the first month, about a hundred and forty availability checks and sixty holds went through it, with staff confirming holds each morning. Invalid dates dropped to almost zero after the error messages were improved, and the studio stopped double-booking weekend slots, which had happened a few times a month when bookings were handled across WhatsApp and email.

6:39 Watch me do it: studio_server.py

Watch me do it. I open studio server dot py. First, I import MCPServer and ToolError and create the server with the studio's name. Next, the valid date helper parses an ISO date, raising a tool error that says use year-month-day if it fails, and another if the date is in the past. Then check availability validates the date and package and returns free times. Hold slot validates the date, the time and the email, then adds the hold and returns held twenty-four hours. The packages resource returns the package table, and the prompt returns drafting instructions. At the bottom, mcp dot run starts stdio. I run mcp dev and open the Inspector. I call check availability for the third of October, mini, and see two free times. I call it with a slash-formatted date and see the error flagged. Finally, I run the pytest test, which asserts that result dot is error is true.

7:46 Recap

To recap: design read-first, build with typed functions and honest docstrings, test manually, automatically and with a real model, add proper auth before going remote, and harden with validation, permissions and logs. Your next step: design a four-item server for a system you use, build it, open it in the Inspector, and write one test for an invalid input. The Model Context Protocol flagship course takes you on to OAuth, extensions and production deployment.

8:18 Try this now (about an hour)

Try this now. Choose a small system you know, even a spreadsheet of products or bookings. Design four items: two tools, one read and one low-risk write, one resource and one prompt. Build them with the SDK, open the server in the Inspector, and call each one. Then write one automated test that sends an invalid input and confirms the result is flagged as an error. Allow about an hour.