WonderKit Discover

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the tool only produces links and the server itself cannot persist or share anything, which corrects the expectation set by the name "continue".

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 sentences, no filler: the usage trigger leads, the return value follows, and the capability limitation closes it out. Every sentence carries information an agent needs.

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, so the description need not enumerate return fields, and it still names what comes back. For a zero-required-parameter, read-only handoff tool the description is nearly complete; only the absence of explicit sibling routing (e.g., when to prefer plan_trip_link) leaves a small gap.

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 both parameters (city, slug) are fully documented in the schema, including format hints like "paris-france". The description mentions the city guide, itinerary, and guest planner, which loosely maps to the city/slug inputs but adds no syntax or format detail beyond the schema, 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?

The description names the concrete output (WonderKit web links for the city guide, itinerary, and guest planner) and the trigger context, so an agent knows it is a link-handoff tool rather than a data fetcher. It stops short of explicitly distinguishing itself from close siblings like plan_trip_link or get_itinerary, so the differentiation is implied rather than stated.

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 a clear when-to-use condition ("when someone wants to save, share, or keep working on a plan from a public guide or itinerary") and states a firm boundary ("This server cannot save or share anything itself"). No alternative sibling is named for cases where the user wants actual data rather than a handoff link.

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 covered. The description adds real context beyond them: the result source (published WonderKit city guide picks plus page URL) and the scope limitation that only single activities, not multi-day plans or private trips, are visible.

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 tight sentences, front-loaded with the trigger condition, then the return shape, then the exclusions. Every sentence carries distinct information with no repetition of the schema or 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?

An output schema exists so return values need not be detailed, yet the description still summarizes the return (published picks plus page URL). Combined with annotations covering safety and the schema covering all three parameters, an agent has everything needed to select and call this 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?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by mapping natural-language phrasing onto the parameters: 'weekend ideas, events, food' illustrate query terms and 'kid-friendly, date-night, or group activities' correspond to the audience enum values families/couples/friends, which helps map a user request to the right field.

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 ('find activities in one city') and immediately scopes it: published picks from the WonderKit city guide with a page URL. It explicitly rules out adjacent capabilities ('returns single activities, not multi-day plans') and distinguishes itself from trip/itinerary 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?

It states a clear trigger ('when someone asks what to do in one city: weekend ideas, events, food, or kid-friendly, date-night, or group activities') and two boundaries (no multi-day plans, cannot see anyone's own trips). It stops short of naming the sibling to use instead (e.g. search_itineraries for multi-day plans), so it is strong but not fully explicit about alternatives.

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 read-only, idempotent, non-destructive, non-open-world behavior, so 'Read-only; it cannot change a plan' is largely redundant. However, the description adds genuine non-obvious context: the dayCount/stopCount semantics change before 2026-09-28, what stopCount counts (anchors plus backups), and that planUrl opens a prefilled planner.

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 usage trigger is front-loaded and each clause carries information, but the single dense sentence packs return-field details and a historical caveat into one block, making it heavier to scan than ideal. Nothing is padding, yet it could be split for readability.

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, so return values needn't be explained, yet the description still summarizes the key response fields and the planUrl behavior helpfully. Combined with the usage trigger and slug sourcing, an agent has everything needed to invoke 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 coverage is 100%, and both parameters already document accepted forms and example values ('Paris' or 'paris-france'; '3-day-weekend-for-couples'). The description only reinforces that lookup is by slug without adding format or validation detail beyond the schema, so the baseline of 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 states a specific verb and resource with scope: retrieve the full plan for one public itinerary keyed by slug. It enumerates what the plan contains (day-by-day or themed stops, venues, map links, rainy-day and where-to-eat sections, best season), which clearly separates it from list_itineraries and search_itineraries that return collections.

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 opens with an explicit trigger ('Use this when someone wants the full plan for one public itinerary, by its slug'), and the slug parameter points to list_itineraries or search_itineraries as the source of valid slugs. It never states when NOT to use it or names a true alternative for other needs, so it falls short of a 5.

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, but the description adds meaningful traits: it reads public guides only, covers only cities with a published guide, and cannot mutate or access private trips. It does not discuss rate limits or result ordering, so it is strong but not 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?

Two sentences, zero waste: the usage trigger is front-loaded, followed by the capability and limitation. Every clause 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?

With an output schema present and zero parameters, the description only needs to establish purpose, scope, and limits — all of which it does. Nothing required to invoke 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?

The tool takes zero parameters, so the baseline is 4. The description does add that each city comes back 'with their keys', which is modest but useful context beyond the empty input schema.

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 ('Lists cities that have a published city guide of real things to do, with their keys') plus a scope qualifier that separates it from itinerary/trip tools. An agent can distinguish it from siblings like list_itineraries or plan_trip_link 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?

Gives an explicit trigger ('when someone asks which cities WonderKit covers or needs a valid city key') and explicit exclusions ('it cannot plan, save, or look up a private trip'), which routes the agent away from the sibling tool families. Both when-to-use and when-not 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description layers on non-obvious behavior: in-season plans sort first, and each summary carries dayCount/stopCount. The version caveat ('before 2026-09-28 stopCount held the day count') is the kind of data-format quirk an agent could never infer from schema or annotations.

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 usage trigger, then scope, then ordering, then return-shape caveats, then exclusions. Every sentence carries distinct information; nothing is repeated from the schema or 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 document return values, and it still flags the one field whose historical meaning changed. Combined with annotations covering safety and idempotency, an agent has everything needed to select and call this 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?

Schema description coverage is 100%, and both parameters (city, audience) are fully documented there with format examples and an enum, so the baseline is 3. The description restates the browse dimensions ('by city and audience only') but adds no syntax or format detail beyond the schema.

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 opens with a specific verb and resource ('browse WonderKit's public multi-day itineraries and place guides') plus its scope ('for all cities or one city and audience'). It also distinguishes itself from the ranking sibling by noting it 'does not rank by a free-text description', so an agent can separate it from search_itineraries and get_itinerary 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?

It gives an explicit trigger ('Use this when someone wants to browse...') and clear exclusions ('does not rank by a free-text description', 'Does not book or edit a trip'), which routes the agent away from search_itineraries and the booking/planning siblings. It stops short of naming those alternatives outright, leaving a small step of inference.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds non-obvious behavior beyond them: it creates nothing, cannot book, the traveler supplies dates and headcount later in the planner, and the returned artifact is a planner link rather than a citable page. It does not cover rate limits or reuse semantics for the generated link.

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?

Four short sentences, front-loaded with the usage trigger, then output, then boundaries. Every sentence carries distinct information; nothing is restated from the title or 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?

With a rich output schema and full annotation coverage, the description only needs to supply when-to-use and capability boundaries, which it does. An agent has everything needed to decide to call it and to set expectations for the user.

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 baseline is 3 and the schema already documents all six params well. The description adds real meaning on top: only city/vibe are baked into the link, while dates, travelers and kids' ages can be deferred to the planner, explaining why only city is required and how the optional params are used.

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 action and artifact: returns one guest-planner link with city/vibe prefilled plus a one-line description. It also draws the boundary against adjacent things (a booking, a citable guide page), so an agent can distinguish it from guide/search siblings without opening their schemas.

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?

"Use this when someone wants to start planning their own trip to a destination in WonderKit" gives an explicit trigger condition. It clarifies context but never names a specific sibling tool as the alternative when the user does not want a self-planning link, so it stops short of full routing guidance.

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?

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety and idempotency are covered. The description adds behavior the annotations don't: it ranks results by user words, audience, and season fit, and clarifies the scoping effect of passing a city. It still says nothing about result shape or fallback behavior when no match is found.

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 tight sentences: the trigger scenario comes first, ranking behavior second, the exclusion last. Every sentence carries distinct information and nothing is repeated from the schema or 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, return values need no explanation, and the annotations cover the safety profile. The description supplies what remains: trigger contexts, ranking logic, city scoping, and the create/save exclusion, leaving no practical gap for correct invocation.

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 all seven parameters documented including enum meanings ("now" means the current month) and the month-over-season precedence rule, so the schema carries the load. The description mostly echoes this ("Pass a city to stay in one city", "season fit") without adding syntax or format detail beyond the schema, which is the expected baseline-3 outcome.

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 -- searching matching public itineraries across cities -- and grounds it with concrete example queries ("romantic weekend in October", "Christmas markets"). It clearly marks itself as read-only published-guide retrieval, but it never distinguishes itself from near-name siblings like list_itineraries or get_itinerary, which an agent could plausibly confuse it with.

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 trigger condition ("when someone describes the trip they want...") plus a negative constraint ("Do not use it to create or save a trip; it only reads published guides"). However, it names no alternative sibling tools, so the agent gets when/when-not but no routing guidance against list_itineraries, get_itinerary, or find_activities.

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