Your MCP server is an agent interface. Design it as one.

Ask an agent whether a building is at risk of overheating, and the register answers with one field: 3.59. The model decides what that means: 3.59 hours, well within the norm, low risk. It is a unitless indicator with a limit of 1.5. The building is more than twice over it.

The application used to carry that meaning. A backend and a frontend turned 3.59 into a red marker and the word "significant". An agent gets the raw number, and the layer that used to explain what it meant is gone. Your MCP server is the agent interface, and many were never designed as one.

At Warmtebouw, a 350-person Dutch building services contractor, I built and run sixteen production MCP servers with 103 tools, used by more than 100 colleagues, most of them non-developers. This talk is about designing those servers for the agent: what it can do, what it understands, and whether that understanding actually reaches it.

What I found surprised me. Sometimes one line of meaning was enough. Often it wasn't: the server had to derive the value, expose the data a rule needs, or reject a bad call with enough information to recover. Knowledge only helps if it reaches the model, and different clients deliver different parts of the interface. One plausible but wrong line can be worse than no guidance at all. I turned those assumptions into evals, and published the runs.

We learned to design for users. Now we design for agents. You will leave with a practical way to design an MCP server as an agent interface: what the model needs to know, what the server should do instead of explain, how that context reaches the model, and how to measure whether it changed behaviour.