Follow-up draft

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with the crucial 'Griasa sends nothing' guarantee plus the follow-up action required from the caller. It also discloses a real limitation — the returned addresses are only the ones Griasa knows — which the annotations cannot convey. No auth or coverage caveats, hence not a 5.

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?

Front-loaded with what the tool produces, then the person variant, then the no-send rule and the id prerequisite. The return-value sentence borders on restating the output schema, but it is short and decision-relevant.

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 an output schema exists, the description needn't enumerate fields in detail; it covers purpose, both parameter modes, the id prerequisite, the side-effect profile and the required post-call action. Nothing an agent needs in order to call this correctly is absent.

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 coverage is 100%, so both parameters are already documented. The description's phrasing about `person` (only that person's and the user's promises, addressed to them) largely mirrors the schema text, so it adds little beyond the baseline that full coverage already earns.

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 (draft a follow-up email for one meeting) and scopes it to Griasa's notes covering the summary and who promised what. The `person` variant is described in the same breath, so an agent can tell exactly what output it will get in either mode and how that differs from get_transcript or list_commitments.

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?

Explicitly names search_meetings as the source of the required id, and gives operative guidance: Griasa sends nothing, so hand the mailto link to the user or send via the user's own mail tool after confirmation. What's missing is an explicit 'don't use this when you only need raw meeting details — use get_meeting' style exclusion against siblings.

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