I built a small Healthy Food MCP server, and the main lesson was that agents need boring tool surfaces

I built a small Healthy Food MCP server recently. On paper it sounds simple: expose recipe content to an agent. But the interesting part was not the food data. The interesting part was realizing how much structure the MCP server needs to provide before the agent becomes useful. If you just give an LLM recipe text, it can summarize it, but it also starts inventing structure, mixing categories, guessing nutrition fields, or returning something that looks correct but is hard to reuse. So I tried to make the tool surface boring and constrained instead: * list high-level calorie categories * list diet / meal / macro groups * list available recipe files with previews * fetch a full structured recipe by slug * search recipe docs by keyword The goal was not to make the agent “smarter.” The goal was to reduce how much it has to guess. A few things I noticed: 1. Small tools are easier for the model to use correctly than one big “do everything” tool. 2. Stable slugs are more useful than asking the model to remember names from free text. 3. The server should own the content model. The agent should mostly choose, fetch, compare, and explain. 4. Skills/prompts help, but they work much better when the MCP tools are already shaped around the task. This made me think MCP is less about exposing APIs to LLMs and more about designing a clean interaction surface for agents. Curious how others are thinking about this: When you build MCP servers, do you prefer many narrow tools, or fewer larger tools with more flexible parameters?