wolt_collections

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

With no annotations, the description carries full responsibility, and it delivers: it discloses the source endpoint, the dynamic/ops-curated nature of collections, field parity with /wolt/search, and the crucial is_serviceable semantics explaining that an empty collection list can mean coverage failure. This prevents a serious misinterpretation of empty results.

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 purpose and includes a valuable edge-case explanation. Some redundancy exists: 'curated homepage restaurant/store collections/lists for a location' appears twice nearly verbatim, but the overall length is justified by the non-obvious is_serviceable behavior.

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 tool with only two parameters and no output schema, the description covers the important non-obvious return semantics: field parity with /wolt/search, is_serviceable, and the meaning of an empty collections list. It does not specify the exact response envelope or pagination, but provides enough for correct invocation and interpretation.

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 already describes both latitude and longitude with 100% coverage, so the baseline is 3. The description reinforces that these are location coordinates tied to delivery coverage but adds no format, range, or precision details 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 states a specific action and resource: 'Get Wolt's curated homepage restaurant/store collections for a location.' It also gives concrete examples (top-rated, newest, hot-this-week) and distinguishes itself from search tools by clarifying it returns Wolt's own curated homepage lists, not search results.

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 implies usage for fetching curated homepage collections for given coordinates and mentions the anonymous homepage endpoint, but it does not explicitly state when to prefer this over wolt_search, wolt_search_filters, or other Wolt siblings. Usage guidance is present but not made explicit with alternatives or exclusions.

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