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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it searches only *finished* meetings, matches 'by words or meaning' (keyword plus semantic), and returns overview documents plus transcript parts keyed by an id that opens the full item.

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?

Two sentences: the first front-loads usage triggers, the second front-loads what is searched and what comes back. No filler; every clause adds information about scope, matching mode, or return shape.

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?

An output schema exists, so return values need not be detailed, yet the description still summarizes the return form (documents + transcript parts with ids). It covers scope, matching mode, and output form; missing are result limits, pagination, or whether results are ranked, which an agent searching a meeting corpus might need.

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?

With one parameter at 0% schema description coverage, the description carries the burden, and it partially does so by demonstrating free-form natural-language queries in the trigger examples, implying the query is prose rather than keyword syntax. It never addresses the 300-character cap or minimum length, so the gap is only partly closed.

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 verb and resource ('Searches the connected user's finished meeting minutes and transcripts') and scopes it to finished meetings, which cleanly separates it from siblings like fetch, meetnotes_get_transcript, and meetnotes_list_recordings. An agent can identify what it does without opening the schema.

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 opening clause gives concrete user-utterance triggers ('what did we decide about pricing?', 'when did we talk about the launch?') that map intent to tool selection, which is strong when-to-use guidance. However, it names no explicit alternatives or exclusions (e.g., 'use fetch when you already have a meeting id'), so routing against siblings is left partly to inference.

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