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

Annotations already establish this as read-only, idempotent, and non-destructive; the description adds important behavioral limits: maximum 10 results, only id/title/url fields, and the fact that richer detail is deliberately omitted. This goes well beyond annotation coverage and gives the agent realistic expectations.

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, each with a distinct purpose: compatibility reason, core behavior, alternative routing, and follow-up action. There is no filler or redundant restatement, and the most decision-relevant information is front-loaded.

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 still specifies return shape, result count cap, and query scope. It also points to the alternative for richer data and to fetch for record details, making the tool fully actionable on its own.

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 schema only describes query as 'What to look for,' but the description explains that it accepts a city, topic, company, or conference name and is a single string argument. This materially enriches the parameter meaning 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 clearly states this is a compatibility tool for OpenAI connectors, searches conferences by free text, and returns at most 10 results as id, title, and url. It further distinguishes itself from search_conferences by noting the single-string-argument and limited-detail nature of this tool.

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?

Explicitly states when to use this tool (when OpenAI connectors require the exact name and one string argument) and when to use the alternative (search_conferences for separate arguments and more detail). It also routes id-based follow-ups to fetch, giving clear decision guidance.

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