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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the bar is lower. The description adds genuine behavioral context: the data is cloud-synced, a local-file fallback exists and should be preferred (a cost/latency hint), and summaryOnly returns a 'much smaller' payload.

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 sentences, no filler, and the core fetch action is front-loaded before return values and the summaryOnly/local-file guidance. Every sentence earns its place, though the local-path sentence is dense with environment-specific detail.

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?

No output schema exists, and the description helpfully enumerates the returns (title, start time, post-meeting summary, transcript). Auth expectations are covered by the projectApiKey schema text, leaving little an agent needs beyond this.

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 only 50% (meetingId and summaryOnly are undocumented in the schema), but the description compensates by explaining the meetingId formats and the summaryOnly trade-off. botId and projectApiKey semantics are already carried by the schema text, so combined coverage is strong.

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?

States a specific verb (Fetch) and resource (cloud-synced Meeting Bots transcript) plus the identifier's accepted forms (calendar event id or URL hash for ad-hoc meetings). An agent can distinguish this from get-meeting-set and list-meetings without opening any 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?

Clear conditional guidance: use summaryOnly when only the summary suffices, pull the full transcript only when the summary is not enough, and prefer the local transcript.md when present. It stops short of naming sibling tools like get-meeting-set or list-meetings for metadata-only needs.

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