Road traffic & incidents around a hotspot

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation through the verb 'Get' and describes the returned data (speed, congestion, incidents). It does not mention side effects, permissions, or error behavior, but for a straightforward data-retrieval tool, this is reasonably transparent.

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 brief and front-loaded with the main function. It includes a Korean translation and an example, all in about 30 words. The translation is somewhat redundant for English speakers but does not bloat the description excessively. Overall, it is concise and well-structured.

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 simple tool with one parameter and no output schema, the description covers the essential context: what data is returned, the geographic scope, and a usage example. It does not mention output format or data freshness, but these are not critical for understanding how to invoke the tool 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?

The input schema describes the parameter 'place' as '핫스팟 장소명' (hotspot place name). The description adds significant meaning by specifying 'around a Seoul hotspot' and giving an example (Gwanghwamun), clarifying the geographic scope and what kind of place is expected. This goes beyond the schema's minimal description.

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 clearly states the tool's function: 'Get average road speed, congestion message, and accident/control incidents around a Seoul hotspot.' It specifies a concrete verb (Get), the data returned, and the geographic scope. This clearly distinguishes it from sibling tools like get_disaster_alerts or get_weather.

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?

The description provides a specific usage example: '"광화문 근처 길 막혀?" 류 질문에 사용' (use for questions like 'Is the road near Gwanghwamun blocked?'). This gives clear context on when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative tools, so it stops short of a perfect score.

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