Building your first MCP server for an internal workflow
A short, opinionated guide to building a useful MCP server in a weekend. What to expose, what to leave out, and how to make sure it stays safe to run in production.
The first MCP server you build does not need to be ambitious. The point is to feel the shape of the protocol, see how Claude Code actually uses tools, and end up with something useful for your team. A weekend is enough to ship something real if you stay narrow.
Pick a workflow that already annoys someone
The best first server targets a workflow that someone on your team does often, manually, and grudgingly. Looking up the status of an order, finding the right runbook, and summarising the last week of issues from a project tracker are all small enough to scope and big enough to feel useful.
Understand the three primitives
MCP servers expose three kinds of things. Tools are functions the model can invoke with arguments. Resources are pieces of data the model can read. Prompts are reusable templates. Most useful first servers consist of one or two tools and maybe one resource. You do not need to use all three.
Design the smallest useful interface
Resist exposing the entire underlying API. Pick the two or three operations that cover the workflow and write thin wrappers for them. Each tool should have a name a person can read, a clear description, and arguments that map cleanly to the real domain. The model behaves much better with a small, well-described surface than a large, generic one.
Authenticate and scope
Decide who can run the server and what credentials it carries before you write the first line of code. A token scoped to a single project, a read replica, or a sandbox account is almost always the right starting point. Never put a credential into a server that has more permissions than the workflow needs.
Log everything from day one
Every tool call should produce a log line that includes who triggered it, what was called, the arguments, and the outcome. This is your only window into what the model is actually doing once people are using the server. Without it, tuning the descriptions and scope becomes guesswork.
Test it the way it will be used
Hook the server up to Claude Code and try the workflow end-to-end. Ask the kinds of questions a real user would ask. Watch which tools the model picks, which arguments it passes, and where it gets confused. The first few iterations of an MCP server are mostly about tightening descriptions until the model uses it the way you intended.
