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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scoping context (results are limited to tours currently in progress, and no query yields the complete list) but says nothing about result volume, pagination, or ordering.

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?

Two compact sentences with zero filler; the core action and its examples come first and the empty-query fallback is stated last. Every element earns its place.

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 read-only, two-parameter search with annotations covering the safety profile and no output schema, the description covers scope, accepted inputs, and the no-query case. The only gap is not routing the agent away from the near-duplicate find_nearby_tours.

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 both parameters are already documented in the schema. The examples of acceptable query values ('남원', '부산 영도', '해인사') add modest clarity, but receipt_event_only is unexplained beyond the schema wording, so 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?

States a specific verb and resource: finds in-progress stamp tours by region, tour, or place name, with concrete examples ('남원', '부산 영도', '해인사'). It is distinguishable from get_tour (single lookup) but never references find_nearby_tours, so the differentiation from the location-based sibling is left to inference.

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 one clear usage rule — an empty search term returns the full list — which tells the agent how to enumerate everything. However, it never states when to prefer this tool over find_nearby_tours (name search vs. proximity search) or over get_tour.

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