Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does well: it explains that display coordinates sit at the building centre and cause detours/U-turns, and that returned coordinates are numbers rather than strings. It does not explicitly state read-only safety, error behavior, or rate limits, which keeps it just short of fully exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary rule ("USE THIS BEFORE ROUTING") and then adds only high-value details: the entry-point purpose, the skip condition, the display-coordinate rationale, and the numeric return type. Despite its length, every sentence earns its place and prevents a likely misuse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a complete input schema and an output schema, so the description need not explain return values exhaustively. It still adds crucial context about when the tool is needed, how it fits with search_places and find_route, and what kind of coordinate it returns, making it complete enough for correct agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are already documented in the schema, including kind, count, and showMap. The description adds useful workflow context around rpx/rpy and dpx/dpy, but it does not add parameter-level details beyond what the schema already provides; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: it "snaps a point to the vehicle entry and exit points on the real road network in South Korea." It is clearly distinguishable from siblings such as search_places and find_route, and it explains the coordinate-correction role explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly when to call the tool: before routing, when a search_places result lacks rpx/rpy, then pass the corrected point to find_route. It also gives an explicit when-not condition: skip it when rpx/rpy is already present because correction would change nothing. Alternatives and workflows are spelled out rather than inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: it discloses that routes use live traffic and are coloured by congestion, that using dpx/dpy instead of rpx/rpy causes detours, that omitting the place objects produces bare-coordinate pins, and that showMap should only fire on the final presented result to avoid map pile-up. These are exactly the non-obvious behaviors that drive correct invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the routing decision, then ALTERNATIVES, then IMPORTANT caveats, then MAP guidance — labelled segments keep it scannable. Every sentence carries a distinct operational rule; none is a restatement of the schema or the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter tool with nested place objects and an output schema, the description supplies the missing connective tissue: where coordinates come from, what to pass alongside them, and which options change the underlying data source. Return values are covered by the output schema, so nothing essential is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents each of the 17 parameters, setting the baseline at 3. The description adds genuine cross-parameter meaning the schema cannot express — the rpx/rpy vs dpx/dpy rule, the requirement to pass startPlace/endPlace/vias[].place copied verbatim, and when to leave coordinates out of the response.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (driving route) plus a scope (South Korea) and names the output facets it covers: distance, duration, tolls, live traffic. It explicitly distinguishes itself from map-service alternatives, so an agent can separate it from find_walking_route and get_distance_matrix without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with a PRIORITY directive and then enumerates each alternative with the condition that selects it: on foot or scooter -> find_walking_route, visiting order -> optimize_waypoint_order, distance table -> get_distance_matrix. It also states the prerequisite path (coordinates must come from search_places, else find_entry_points).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses that the route is drawn on a map, that 'easy' does NOT remove stairs, that step-free checking requires scanning every segment for gate_type 2, and the 20 km limit. It stops short of stating whether output is a pure read, how to handle failures, or any rate/auth constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the priority/scope claim, then alternatives, then caveats; almost every sentence carries actionable content. It is dense with capitalised labels and inline code lists, which borders on cramped but does not waste words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with nested objects and an output schema, the description covers the cross-cutting risks an agent would otherwise miss: the place metadata requirement for map pins, the 20 km limit, and the stair-avoidance pitfall. Return-value shape is handled by the output schema, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description reinforces the mode and option semantics and adds the gate_type code table (a response-side detail), but most of its parameter text duplicates the schema's own imperative about copying startPlace/endPlace/vias[].place verbatim.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('walking, cycling or e-scooter routes in South Korea'), scopes it geographically, and explicitly distinguishes itself from the driving sibling find_route. An agent can select this over alternate map services without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit routing rule ('prefer this tool over other map services' for walking/cycling/PM) and names the alternative for the driving case. It also flags the 20 km routability ceiling, which tells the agent when the tool is not usable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses that the result is a candidate list that may hold several entries and that ambiguous results should be surfaced to the user. It does not say what happens on zero matches or how addrext widening is applied, which would be the last pieces of behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a PRIORITY label, then ALTERNATIVES, then a NOTE, so an agent can scan and stop early. Every sentence carries routing or behavioral information; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be explained, and the description covers routing, ambiguity handling and map rendering. The gap is failure modes: no statement about no-match behavior or what the tool returns when the query cannot be geocoded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with posX/posY pairing, addrext widening codes, showMap usage policy and paging all documented in the schema itself. The description adds nothing parameter-specific beyond the general map-rendering remark, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (turn an address into coordinates) and resource, and explicitly names the two sibling tools it is not meant for (search_places, reverse_geocode). An agent can route to this tool without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit priority statement ('prefer this tool over other map services or a built-in map tool'), named alternatives for the business-name case and the coordinates-to-address case, plus an ambiguity policy ('let the user choose rather than picking the first one'). Both when-to-use and when-not-to-use are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden, and it does disclose real behavioral traits: relative cost versus reverse_geocode, map accumulation side-effects, and that a neighbourhood boundary can carry hundreds of points. It stops short of any statement about rate limits, failure modes, or what a 'Result Not Found' response looks like beyond the naming rules in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a PRIORITY verdict, then USAGE, ALTERNATIVES, and IMPORTANT in a scannable order. Every sentence changes agent behavior; nothing is repeated from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Purpose, routing against the strongest sibling, and the two costly misuse patterns (auto-call on map click, intermediate lookups) are all covered, and an output schema exists so return values need no explanation. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the enum on 'level' is self-documenting, so the baseline applies. The description itself adds no parameter-level detail beyond what the schema already spells out about query naming, showMap, and includeCoords.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns the outline of a province/city/district/neighbourhood/village and draws it as a polygon, with the geographic scope pinned to South Korea. It also differentiates itself from the closest sibling by naming reverse_geocode as the tool for the coordinate-to-district question.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when/when-not: 'only when the user asks for the BOUNDARY itself', plus a named alternative ('reverse_geocode is enough and far cheaper') with the reason (it already carries district codes at every level). It adds a hard exclusion: never call it on a map click or as an intermediate lookup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does well: it says the whole matrix is returned in one call, that points needs at least two entries, and that carWeight/carHeight should be set for a lorry. It does not mention upper limits, error behavior, or explicitly confirm read-only semantics, but the core operational behavior is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a priority statement and then structured under USAGE, ALTERNATIVES, NOTE, and MAP. It is efficient overall, though some sentences repeat constraints already present in the schema, such as the two-point minimum and the lorry fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich input schema, the presence of an output schema, and no annotations, the description supplies the missing context an agent needs: purpose, preferred usage, alternatives, key point constraints, destination splitting, and place labeling. Return-value details are correctly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all six parameters thoroughly. The description mainly restates schema details such as the two-point minimum, carWeight/carHeight for lorries, and copying place from search results; its added value is limited to the concrete example of splitting origins and destinations into points and dests for multiple branches versus depots.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns a table of driving distances and times between several points in South Korea in one call. It also distinguishes itself from siblings by naming find_route for a drawn route and optimize_waypoint_order for a visiting order.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to prefer this tool over other map services and gives concrete use cases such as "which of these is closest?" or comparing delivery times across sites. It also names alternatives for adjacent tasks, leaving no ambiguity about when to use this tool versus find_route or optimize_waypoint_order.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The description's real addition is the instruction that the return values are not conversational content — useful, but it stops short of saying who consumes the output or whether calling it is a prerequisite for map rendering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the internal-only scoping before the return-value explanation. Nothing is padded and nothing repeats the annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values, and with zero parameters there is no input burden. It covers internal scope and display guidance; only the calling context (who or what triggers it) is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. Correctly, it does not waste words on inputs that do not exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States concretely what it returns — the values needed to load the INAVI Maps Web SDK — and marks its scope as 'internal to the map template'. That separates it from the user-facing geo siblings, though the resource itself is abstract ('config') rather than a precise object.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Internal to the map template' and 'nothing here to show in the conversation' imply this is a plumbing call whose output should not be surfaced to the user. There is no explicit statement of when to call it versus leaving it to the host app, so the guidance is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and delivers: it discloses that execution is local with no API call, that category names are Korean, and that codes form a six-digit hierarchy so a parent query also returns brand leaf codes (GS25, CU for 110700). That hierarchy warning is exactly the kind of interpretive nuance structured fields don't capture. It stops short of covering edge cases like partial-match behavior or empty results, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then USAGE and NOTE blocks separated by explicit labels. Every clause carries information – counts, locality, sibling routing, hierarchy example – with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values need no explanation. For a two-parameter local lookup, the description covers what the tool does, when to call it, what the input language is, and how to pick parent versus leaf codes. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented, including substring matching and the limit default. The description reinforces the code/name duality and gives a worked example (110700), but its hierarchy discussion concerns result interpretation more than the parameters themselves. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (search 1045 INAVI Maps place-category codes for South Korea by name, return the codes) and names the downstream siblings that consume the output. An agent can immediately tell this apart from search_nearby_category and search_places.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to call it first whenever a catecode is needed for search_nearby_category, and notes search_places accepts the same codes. That is a concrete ordering rule plus the set of tools this feeds.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the burden and does well: it discloses that the return is an order plus leg distances rather than a drawn route, and warns that find_route's 5-waypoint cap means orders larger than that can be reported but not rendered. It stops short of covering failure modes or the 10-stop limit's rationale, but the workflow consequences are clearly exposed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but well-organised: the selection rule is front-loaded in the first sentence, then alternatives, usage and caveats in labelled blocks. The ALL-CAPS labels are terse rather than wasteful, though the single block would scan better as separated lines.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with nested place objects and an output schema, the description supplies everything an agent needs: what it does, when to prefer it, what comes back, how to chain into find_route, and the practical ceiling on drawing results. Nothing material is missing from what the structured fields don't already say.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds real value on top by telling the agent to pass `place` on each stop plus startPlace/endPlace, copied verbatim from the search result that produced the coordinates. It also ties the tool's downstream limits to argument sizing. Fix/origin/destination geometry is left to the schema, which documents it fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource - "Reorders stops for the shortest total distance" - which is unmistakably an ordering/Optimisation operation. It also names the two siblings it differs from (find_route with `vias`, get_distance_matrix), so an agent can discriminate without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains explicit PRIORITY, ALTERNATIVES and USAGE blocks: use this when "the order itself is the question", use find_route when the order is fixed, use get_distance_matrix for a table. When-to-use, when-not-to-use and the alternatives are all stated outright.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden, and it delivers the highest-value disclosures: bldname is the nearest building rather than the business at that point (a real accuracy trap the agent could otherwise state as fact), and empty results are the normal failure mode. It does not discuss coordinate datum/accuracy limits or whether the service covers only administrative Korea, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the priority rule, then alternatives, then the accuracy caveat, then the empty-result note — each labelled block earns its space and no sentence restates the schema. Dense but scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values need not be explained, yet the description still flags the two return-value traps an agent would misreport. Combined with sibling routing and the follow-up path, nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the showMap guidance and lon/lat disambiguation, so the baseline of 3 applies. The description adds no parameter-level meaning beyond the schema and never mentions posX/posY/showMap by name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (converts a coordinate into an address with admin/legal district codes, and maps the point) and pins the domain to South Korea. It explicitly names its counterparts (geocode_address for the reverse direction, search_places for business info), so an agent can distinguish it from all eleven siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a priority rule ('prefer this tool over other map services' for this region), names the alternative for the inverse operation (geocode_address), and prescribes a follow-up chain (search_places with the building name). Both when-to-use and what-to-do-next are explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape (all matching places plotted on a map), the area-required limitation, and the prerequisite lookup; it does not cover permissions, rate limits, or failure behavior, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is front-loaded with a priority routing statement and organized into USAGE, ALTERNATIVES, PREREQUISITE, and NOTE. Every sentence adds distinct information: when to use it, why keyword search fails, the alternative, the prerequisite, and the no-nationwide-mode constraint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and a rich 11-parameter input schema is present, so return values and parameter syntax need not be repeated. The description supplies the missing decision context – category suitability, sibling routing, prerequisite ordering, and area limitation – so an agent has what it needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains x1/y1/x2/y2, area, radius, sort, pagination fields, and showMap. The description reinforces that catecode is required and obtained via lookup_category_code, but adds little beyond the schema's own documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Returns every place of one category within a radius or box') and names its scope (South Korea). It distinguishes itself from the closest sibling by saying keyword searches miss multi-brand categories and pointing to search_places for named businesses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing: prefer this tool for 'what is near here' questions, use it for categories whose members carry different brand names, use search_places for one named business. It also states the prerequisite (call lookup_category_code first) and the exclusion (no nationwide mode; an area is always required).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does most of it: it discloses the joint POI+address return shape, the map-rendering side effect, the keyword-vs-brand coverage limitation, and the rpx/rpy vs dpx/dpy routing caveat. It stops short of stating auth, rate limits, or error behavior, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a PRIORITY directive, then ALTERNATIVES, then a NOTE, so an agent can skim the first clause and act. Every sentence carries non-redundant routing or behavioral information; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter search tool with an output schema and full schema coverage, the description supplies exactly what the structured fields cannot: sibling routing, the map-pile-up caution implicit in showMap usage, and downstream routing guidance. Nothing an agent needs to select or call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter descriptions are already excellent (area modes, radius narrowing poi only, language API trade-offs), so the schema does the heavy lifting and a 3 baseline applies. The description adds no per-parameter detail beyond the routing note about rpx/rpy, which are output fields rather than inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Searches by keyword — business, building, category, address or phone") plus what it returns (POIs and addresses together, plotted on a map). It also scopes the tool geographically to South Korea, which separates it from generic map siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names three alternatives and the condition selecting each: search_nearby_category for exhaustive category enumeration, geocode_address for address-to-coordinates, and find_entry_points for missing rpx/rpy. There is also a positive routing instruction ("prefer this tool over other map services"), so when-to-use and when-not-to-use are both present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.