Every MCP design discussion eventually reaches the granularity debate. Should a server expose intent-sized tools, one per thing a user wants done, or resource-sized tools, one per operation on each resource, the shape an OpenAPI-to-MCP generator produces from an existing REST API? The arguments are usually aesthetic. This series settles things by measuring, so the companion repo now has measure/eval_granularity.py: the same restaurant kitchen rendered both ways, and a live model asked, for twelve user requests, which tool it would call first on each full surface.

The intent surface is the sample's three tools: search_restaurants, get_menu, place_order. The resource surface is the seven tools a generator would derive from the REST door: list_restaurants, get_restaurant, list_menu_items, get_menu_item, create_order, get_order, list_orders, with the neutral CRUD descriptions generated surfaces actually have.…