hawkes.aiKey ideas
- The one idea — An MCP server is small: pick a capability, write a plain function, describe it for MCP (name, description, input schema), register it with a server library and run it, then a client can discover and call it.
- How it is shown — A minimal "get_weather" server built live — a plain function + a schema, registered and started, then a client connecting, listing tools, and the model calling it.
- The trap to avoid — Over-engineering the first server or reaching for a big framework — start with one tool; the protocol handles discovery, calling, and transport.
- What it sets up — The moment your server can act and connect, is it safe?
An MCP server sounds like infrastructure. It's a plain function plus a description: name, purpose, inputs. Expose that, and any client can discover and call it.
The one idea
An MCP server is small: pick a capability, write a plain function, describe it for MCP (name, description, input schema), register it with a server library and run it, then a client can discover and call it.
Enough theory — let's build an MCP server. And the good news, like the thirty-line agent before it, is that a server is small. Define a capability, describe it, expose it, and any MCP client can discover and call it. Let's walk the whole thing, step by step, and watch it come together. Step one: pick a capability. Keep it simple — say, a get-weather tool, or a search-my-notes tool. Just one thing your server will offer. You're not building a platform; you're wrapping a single function so a model can reach it. Start with the smallest useful thing. Step two: write the function. This is plain code — no AI in it at all.
How it works — the demo
A minimal "get_weather" server built live — a plain function + a schema, registered and started, then a client connecting, listing tools, and the model calling it.
Given a city, it fetches the weather and returns it. It's the same function you'd write for any program. The MCP part isn't the logic; it's how you expose the logic. So far, nothing new — just ordinary code. Step three: describe it for MCP. Give the tool a name, a one-line description of what it does, and its input schema — the arguments and their types. This is the tool-schema idea from earlier, now written in MCP's standard format, so any client can read it. The description is what the model actually sees. Step four: register and run. Hand your function and its description to an MCP server library, and start the server. It now listens for connections — locally, over a simple channel — waiting for a client to reach out and ask what it offers.
The trap to avoid
Over-engineering the first server or reaching for a big framework — start with one tool; the protocol handles discovery, calling, and transport.
Why it matters — and what’s next
The moment your server can act and connect, is it safe?
The library handles the protocol machinery; you supplied only the function and the tag. Step five: connect a client. Point your host app at the server. The client connects, calls list-tools, and there's your weather tool. The model can now discover it and call it — the whole loop working, end to end. That's a functioning MCP server: your one function, reachable by any MCP client that connects. And that's it — a working server in a few dozen lines, small and composable like the thirty-line agent. The trap is over-engineering the first one, or reaching for a heavy framework; start with one tool and let the protocol handle discovery, calling, and transport. But the moment your server can act and connect, a sharper question arrives: is it safe? Next: MCP's security surface.
This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.
Full transcript 3:00 of narration
Enough theory — let's build an MCP server. And the good news, like the thirty-line agent before it, is that a server is small. Define a capability, describe it, expose it, and any MCP client can discover and call it. Let's walk the whole thing, step by step, and watch it come together.
Step one: pick a capability. Keep it simple — say, a get-weather tool, or a search-my-notes tool. Just one thing your server will offer. You're not building a platform; you're wrapping a single function so a model can reach it. Start with the smallest useful thing.
Step two: write the function. This is plain code — no AI in it at all. Given a city, it fetches the weather and returns it. It's the same function you'd write for any program. The MCP part isn't the logic; it's how you expose the logic. So far, nothing new — just ordinary code.
Step three: describe it for MCP. Give the tool a name, a one-line description of what it does, and its input schema — the arguments and their types. This is the tool-schema idea from earlier, now written in MCP's standard format, so any client can read it. The description is what the model actually sees.
Step four: register and run. Hand your function and its description to an MCP server library, and start the server. It now listens for connections — locally, over a simple channel — waiting for a client to reach out and ask what it offers. The library handles the protocol machinery; you supplied only the function and the tag.
Step five: connect a client. Point your host app at the server. The client connects, calls list-tools, and there's your weather tool. The model can now discover it and call it — the whole loop working, end to end. That's a functioning MCP server: your one function, reachable by any MCP client that connects.
And that's it — a working server in a few dozen lines, small and composable like the thirty-line agent. The trap is over-engineering the first one, or reaching for a heavy framework; start with one tool and let the protocol handle discovery, calling, and transport. But the moment your server can act and connect, a sharper question arrives: is it safe? Next: MCP's security surface.