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

Annotations already declare readOnly, openWorld, non-idempotent and non-destructive. The description layers on genuinely useful behavioral context: coverage is the published catalogue not the whole web, these are enquiries not confirmed seasonal dates, it does not book or charge, and it returns source facts, photos, opening info, maps and an enquiry link. Funded model provider (AI MAXX) is also disclosed.

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 content is dense and largely example-driven; the actual purpose is buried behind two sentences of activity and seasonal-event examples. Every sentence is informative, but the front-loading is poor and the prose reads as a run-on block rather than progressive disclosure.

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 no output schema, the description carries the return burden and does so by naming what comes back (source facts, photos, opening info, maps, enquiry link). It also covers coverage limits, follow-up behavior and the non-booking nature, leaving only the limit parameter unexplained.

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 75%, so the schema already documents query, country_code and response_depth. The description adds guidance on preserving the requested location and indoor/outdoor preferences/constraints and on reuse in follow-ups, but it never mentions the limit parameter or adds anything beyond the schema for response_depth.

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 verb+resource is present – it asks an AI specialist to interpret a customer need and select relevant published services from the catalogue. However, it opens with a raw list of activity examples (laser tag, Prison Break, VR) rather than a purpose statement, and it never explicitly contrasts itself with the sibling consult_events/consult_venues/consult_hospitality tools, only names get_passport.

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 clear context for use (interpret a direct or indirect need, preserve location and indoor/outdoor preferences) and routes follow-ups explicitly: refine the need after clarification, or use get_passport for full details. It also states the sending constraint (nonpersonal need only). It stops short of stating when NOT to use it versus the other consult_* siblings.

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