엔차 · 오래 버틴 맛집

The two search tools are separated by input type (administrative region name vs. lat/long radius) and the descriptions make that distinction clear, while get_restaurant (detail by id) and list_regions (coverage metadata) target distinct resources. There is still some overlap in that both find_* tools return restaurants and an agent holding both a district name and coordinates must choose one, but the boundaries are stated well enough to avoid misselection.

All names follow a verb_noun pattern (find_*, get_*, list_*) in snake_case with no mixed conventions. The only wobble is qualifier placement — find_long_running_restaurants vs. find_restaurants_near — which is a minor stylistic deviation rather than a readability problem.

Four tools is a tight, well-scoped surface for a read-only restaurant lookup service: two entry points for discovery, one detail view, one coverage index. It sits at the low end of the ideal range, so a couple more discovery options might be warranted, but nothing is redundant.

The domain is read-only public license data, and the surface covers the full path from regional browsing (list_regions) to discovery (by region or by geo) to per-restaurant detail including license history. Minor gaps remain: no lookup by restaurant name and no way to enumerate menus or paginate results, even though menu is mentioned as a search dimension.