Get Live Meeting Transcript

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavior details: it fetches only new sentences, supports incremental retrieval via sinceEndInSec, and operates on live/just-ended meetings. No contradictions with annotations.

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 efficient sentences with no wasted words. The first sentence states purpose and scope; the second covers identification and pagination. Front-loaded and easy to parse.

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?

Covers key aspects: state (in-progress/just-ended), identification, pagination. Output schema exists so return values don't need description. Could mention that for fully ended meetings, get_transcript should be used, but the current description is sufficient for correct usage.

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 description coverage is 100%, so baseline is 3. The description adds meaningful context: explains that meetingAssistantEventId is preferred over mediaId, and that sinceEndInSec should be set to the previous nextCursor value. This clarifies the relationship and pagination pattern 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 it fetches new sentences from an in-progress or just-ended meeting transcript. The verb 'fetch' and resource 'live meeting transcript' are specific, and the mention of 'in-progress or just-ended' distinguishes it from sibling tools like get_transcript, which handles completed transcripts.

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?

Provides clear context: use for in-progress or just-ended meetings. Explains how to identify the meeting (meetingAssistantEventId preferred over mediaId) and pagination via sinceEndInSec. However, it does not explicitly state when to avoid this tool (e.g., for completed transcripts) nor name an alternative sibling, though the sibling list includes get_transcript.

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