A parks department exposes five near-identical single-purpose tools: get_field_name, get_field_capacity, get_field_surface, get_field_hours, and get_field_contact, each returning one attribute of the same reservation record. What redesign improves this?

Tool surface is a cost paid on every turn: each tool must be read, distinguished from its neighbors, and correctly selected. Five near-identical getters over the same reservation record multiply that cost without adding capability, since all of them resolve to the same underlying lookup.

A single get_field_details tool returning name, capacity, surface, hours, and contact in one structured response collapses five selection decisions into one and five round-trips into one. The model no longer has to guess which of five similar names it needs, and typical questions spanning two or three attributes are answered in a single call.

Adding a sixth aggregate tool that calls the other five internally keeps every bit of the original clutter and adds another item to choose among, worsening the exact problem it claims to solve; shortening the names treats a structural redundancy as a labeling issue; asserting that single-attribute tools are inherently more precise confuses narrowness with precision, since precision comes from a well-specified response shape, not from splitting one record across five endpoints.

Exam caveat: merging is right when the fields come from one lookup at comparable cost—if contact information requires a separate, slow, or access-controlled query, it may legitimately stay its own tool. Operational check: trace a typical reservation question end to end and count tool calls before and after the merge; if the count does not fall, the fields probably were not from one lookup.