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

The annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context: it clarifies the tool does not create/edit/delete meetings (reinforcing the annotations), requires a non-empty query, and scans at most 200 recent synced meetings. It also states it returns ids for fetch, which hints at output structure. This adds value beyond annotations, so a 4 is appropriate.

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 organized into three short paragraphs: purpose, usage, and constraints. It front-loads the primary purpose and includes only necessary details. While it repeats 'query must be non-empty' from the schema, it is not overly verbose. The structure is clear and efficient, earning a 4.

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?

The description, combined with the rich annotations and existing output schema, fully equips an agent to call this tool correctly. It covers the search scope, the return behavior (ids for fetch), the usage context, and the 200-meeting limit. There are no obvious missing pieces that would prevent correct invocation. A 5 is warranted.

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 description for `query` is already rich (plain-text, case-insensitive, not a boolean query language). The tool description only reiterates that the query must be non-empty, which is already enforced by schema (required, minLength). Since schema coverage is 100%, the description adds minimal additional meaning, so a baseline of 3 is correct.

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 that the tool performs keyword search across specific fields (titles, notes, action items, participants, transcript) and returns ids for fetch. It distinguishes itself from search_meetings by noting it is the same search but renamed for ChatGPT, and from list_meetings and fetch by its purpose. This is a specific verb-resource description.

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 explicitly states when to use this tool: when the host only exposes `search`/`fetch`, or when following ChatGPT's search-then-fetch flow. It also lists exclusions: not for paging the archive (list_meetings) or opening a known id (fetch / get_meeting). This is exemplary guidance.

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