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

With no annotations, the description does carry useful behavior: results are permission-scoped to the key ('this key can see'), sorted newest-first, and include share links — real information beyond the schema. However, it says nothing about pagination, result limits, or whether share links are publicly accessible, which matter for a listing tool.

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?

A single front-loaded sentence that packs scope, ordering, and return content with zero filler. Every clause 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?

For a simple read-only list with no output schema, stating ordering and return content covers a lot, but the purpose of the 'meeting' parameter and any pagination behavior remain unaddressed, leaving the caller to guess on the one input it has.

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% for the single 'meeting' parameter, and the description never explains it — whether it's an ID filter, a name, or a scope restriction. The description therefore fails to compensate for the undocumented parameter.

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+resource ('Recordings ... list') with scope ('this key can see'), ordering ('newest first'), and return payload ('share links'). It's distinguishable from list_meetings by naming recordings rather than meetings, though it doesn't explicitly reference the recording-vs-meeting distinction.

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 statement of when to use this versus list_meetings, get_transcript, or get_notes, and no mention of what happens with or without the optional 'meeting' argument. The agent must infer the scoping behavior entirely.

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