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

Goes well beyond readOnlyHint=true: it discloses a hard result cap (up to 10), sort order (soonest first), that each hit carries a ConferenceFindr link where pricing/size/audience live, and the degradation behavior to past editions. The only missing behavioral detail is whether the 10-result cap is truncating (no offset/pagination exists), though the schema offers no continuation parameter either.

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 purpose and primary filters, then return behavior, then the last-edition fallback. Slightly redundant: the ConferenceFindr link is mentioned both in the return description and again in the closing presentation instruction, which could be merged into one sentence.

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 — count, ordering, per-result link, and fallback shape. Seven params (including a nested `near` object) are covered at 71% by the schema; the remaining gap (region enum, radius default) is either self-evident or documented in-schema.

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?

At 71% schema coverage the description sensibly adds semantics the schema lacks — that `query` matches event names, acronyms, and short names, and that `near`/distance supports 'near me' or regional phrasing. It does not expand on `region`'s enum or the inclusive/exclusive nuance of `from`/`to`, which the schema already handles reasonably.

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?

Specific verb + resource ('Find upcoming business conferences and trade shows') followed by an enumeration of the filter dimensions (keyword, industry, place, distance, date). The keyword-matching note ('nacds', 'obl main event') further pins down what the search actually does. No siblings exist, so no differentiation is required.

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?

Usage context is clear: search by topic/name, industry, geography, distance, or date window, and the description explains the important fallback — when nothing upcoming matches, ended events are returned with their last-held date, so an agent won't mistake stale results for a bug. It stops short of explicit when-not-to-use guidance, but there are no alternative tools to route between.

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