meet_get_live_status

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

No annotations are provided, so the description carries the full behavioral burden. It discloses read-only intent via 'Retrieves' and lists response contents, but omits auth expectations (significant given meet_check_auth/meet_setup_auth siblings), the precondition that the session must be active/live, and error behavior for stale or nonexistent sessions.

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?

One efficient sentence with the verb and resource front-loaded, followed by a tight enumeration of response fields. No filler; every element names a distinct piece of returned data and earns its place.

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 are covered elsewhere and the field enumeration is a helpful bonus. The tool is low-complexity (2 params, 1 required), but the description fails to state the live-session prerequisite and session_id provenance, both of which an agent needs to call it correctly without erroring.

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 0%, so the description must compensate but only weakly does. 'Recent utterances' loosely hints at recent_lines' purpose, yet session_id provenance is never explained — an agent cannot tell it should come from meet_start_session or meet_list_sessions — and the mapping from recent_lines to the returned utterances is only implicit.

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?

Specific verb ('Retrieves'), clear resource ('live status of a meeting'), and an explicit enumeration of the returned data (duration, word count, utterance count, speaker breakdown, recent utterances). The 'live status' framing distinguishes it from the transcript-fetching siblings (meet_fetch_google_transcript, meet_fetch_drive_transcript) and session-management tools without needing to open their schemas.

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?

No guidance on when to use this tool versus alternatives. The 'live' qualifier implies it is meant for in-progress meetings, but there is no explicit statement of when to prefer it over transcript-fetching or session-list tools, and no mention that a session must already exist before calling.

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