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

The annotations already indicate readOnlyHint=true, and the description confirms a read operation. It adds transparency by detailing the response content (time, title, etc.), going beyond the annotation. The description is consistent and provides additional context.

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?

The description is a single, efficient sentence that front-loads the purpose and includes all necessary details without extraneous words.

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?

Given the tool's simplicity (one parameter, no output schema), the description covers input format and output fields sufficiently. It does not mention error handling or access permissions, but these are minor for a read operation. The sibling list provides broader context.

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?

The schema has 0% description coverage for 'meetingId', but the description compensates fully by explaining that it is the UUID from the share-link URL (/m/<id>). This adds significant meaning beyond the raw schema definition.

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 explicitly states it reads a meeting by its share-link id, listing specific fields returned (time, title, conference URL, host, alternate times). This is a clear verb+resource with a distinct identifier method, and it distinguishes from sibling tools which handle creation, availability search, and suggestions.

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 description implies when to use this tool (when you have a share-link id) and by listing sibling tools, the agent can infer alternatives. However, it does not explicitly state when not to use it or provide exclusion criteria.

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