Snap a coordinate to road entry points in South Korea

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.