issues_from_meeting

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

Annotations only supply destructiveHint=false, so the burden is largely on the description, which does disclose the meaningful side effects: issues get created and the source doc gets linked. The dry-run-first advice also clarifies the mutation profile beyond the annotation. It says nothing about idempotency on re-runs, how skipDuplicates actually behaves, or what a dry run returns.

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?

Two fragments, front-loaded with the core transformation before the safety advice; nothing is wasted. The arrow notation and telegraphic style are slightly ambiguous, but the density is appropriate for a short tool description.

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 7-parameter write tool with no output schema and thin schema descriptions, the definition is under-specified: it doesn't say what the result contains (issues created, skipped duplicates, parse failures) or how labels are applied to generated issues. An agent could call it, but cannot predict or verify the outcome.

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 only 29% across 7 parameters, so the description must compensate and largely does not. It implicitly covers dryRun and mentions assignee/due-date extraction, but componentLabel, milestoneLabel, skipDuplicates, workspace, and projectIdentifier get no explanation in either place beyond the bare schema type.

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 gives a concrete transformation: meeting notes become issues, extracting action items with @assignee mentions and due dates, plus a link back to the source document. The verb+resource are unambiguous. It does not, however, distinguish itself from the sibling 'issues_from_document', which reads as a near-equivalent, so differentiation is left to inference.

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?

'Dry run first' is a real usage directive that tells the agent to start with dryRun=true, implying the tool writes by default and should be previewed. What is missing is any statement of when to use this instead of issues_from_document, or which prerequisites (project must exist, doc must be meeting notes with action items) must hold.

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