Where MCP Actually Makes Sense

The introduction to A Hands-On Deep Dive into MCP Servers. No code in this chapter, just the reasoning behind the example the whole series builds on. The technical parts start with Part 1.

Opinions on MCP tend to land on one of two ends. Either the protocol is dead, one more spec that peaked at its announcement post, or it's the obvious future and every company should already be shipping servers. Neither take ever helped me build anything. What I wanted was a concrete kind of service where MCP clearly earns its keep. This series is a hands-on walk through one: government services.

The shape underneath

A government service looks like a form, but behind the form sits a tree of decisions.

Take the example this series builds: a permit to use public land. You want to hold a weekend festival in a park, or run a market stall, or farm a plot at the edge of town. Before the city can say yes, a chain of questions has to be answered in order. Which permit type is this? Which parcel? Is that combination even allowed? Given the type and the parcel, which documents are required? What are the fees? Each answer prunes the options for the next question.

Take just one of those questions, the documents, and it already branches. Which papers you owe depends on which permit you're after:

And this is only the checklist. The parcel can still add items on top: protected land, a plot next to a waterway, each brings its own paper.

The parcel prunes from its side too. Zoning decides which permit types are even possible on it, so the menu changes from plot to plot:

A stall can go almost anywhere, a house only where the zoning says residential, and the fenced park by the river allows almost nothing. Every question in the chain branches like this. That tree is the service. The form is just a flattened, unfriendly projection of it.

Walking the tree blind

Today the citizen walks that tree without seeing it. The website assumes you already know which permit you need, so you guess. The map shows parcels but says nothing about what each one allows. You submit, wait two weeks, and a letter tells you that events are not permitted on the parcel you picked, or that you filed under the wrong permit type. Then you start over from a higher branch.

Nobody designed this to be hostile. The rules are reasonable on their own. The problem is that the whole decision tree lives inside the office, and the citizen only meets it one rejection at a time.

The same tree as a conversation

This is where an AI assistant changes the errand. You say what you want to do: a two day festival, a couple hundred people, some food stalls. The assistant asks the office what permit types exist and picks the one that fits. It searches parcels that allow events of that size. It checks the combination before you commit to anything. When you settle on a parcel, it tells you which documents this permit on this parcel requires, and what the fees are.

The tree hasn't changed. What changed is who walks it. The assistant explores the branches, and wrong guesses cost seconds instead of weeks. Nothing is filed until you say so, and when it is filed, it's complete: a valid type, an allowed parcel, every required document. The application that reaches a clerk is one they can actually decide on.

Why this needs an MCP?

First thing that comes to mind - "just build a chatbot for this service". It's good idea, when you're basically an aggregator of hunders of services, and you wanna have your own UX for all of them. (that was the case when building the Diia AI) But I would not recommend it as a first choice. You would need to govern the LLM costs, re-implement chat interface.

The office should not build a chatbot. That would mean, that you need to govern LLM youself.

Chat interfaces change every year, and a city IT department is the wrong place to chase them.

What the office can build instead is an MCP server: the decision tree published as a set of tools that any assistant can use. Whichever assistant the citizen already talks to can read the menu of tools and run the errand on their behalf. The office writes its side once. The guarantees stay on the server, enforced by the process itself rather than promised by the model. The assistant cannot skip a step, invent a parcel, or file an incomplete application.

This is the shape I think makes MCP viable: a multi-step service with real rules, where exploration should be free and commitment should be guarded. Single-shot lookups don't need a protocol. Decision trees do.

Where the series goes

Part 1 builds the exploration half with nothing but tools: pick a permit type, find a parcel, check the combination, lock it in. Part 2 is the back half, where almost every tool writes and the design questions get harder. Part 3 is the moment the office itself has a question, and what happens at the edge of the protocol.

The whole server is real, tested, and in the repo. Start with Part 1.