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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds one useful behavioral note ("participant keys only" for get_free_slots) but omits return shape, pagination behavior for take, and whether filters like status apply across modes.

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 lead sentence front-loads the resource, and the follow-up clause enumerates the four actions with their parameter requirements in a tight, waste-free list. Every clause earns its place by documenting a mode's contract.

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 9-parameter, output-schema-less tool, the description covers the action dispatch and parameter requirements well enough to call it correctly. It is slightly thin on what each mode returns and how take/pagination behaves, but the core invocation contract is present.

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?

With 0% schema description coverage the description must carry the load, and it maps every one of the 9 parameters to its action and marks them required or optional (list: matchId/status/take; get: meetingId; list_action_items: matchId/actionItemStatus; get_free_slots: membershipId/fromDate/toDate). It stops short of explaining value semantics like the take limit or the status/actionItemStatus enum meanings, which the schema's enums partially cover.

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 and resource ("Read meetings and action items") and enumerates the four operation modes, so the agent immediately understands this is a multi-mode read tool for meetings. The resource (meetings/action items) is distinct from siblings like matches_query or cohorts_query, making it separable without opening 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?

Each action is paired with the parameter conditions that select it ("get" requires meetingId, "get_free_slots" requires membershipId/fromDate/toDate), which effectively routes the agent to the right mode. It does not, however, say when to prefer this tool over sibling query tools such as matches_query for match-linked meetings, nor any exclusions.

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