import_meeting_apply

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

With no annotations, the description carries the full burden and delivers: credits cost of 0, idempotent replay behavior, the exact key rights required (memory:write vs content:write plus a content write role), and that facts land in 'YOUR brain' while rules/personas/profile go to the project. It even describes the response echoing the idempotency key. This is unusually rich disclosure for a mutation 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?

Front-loads the essential facts (what it writes, cost, idempotency) in the first line, then the payload shape and permission model. Dense but each sentence adds operative information; the parenthetical field lists are long but necessary given the 0% schema coverage.

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 mutation with no annotations and no schema descriptions, the description covers the payload shape, the permission/key-right model, idempotency semantics, and the return echo. An output schema exists, so it does not need to detail return values further; nothing an agent needs to call it correctly is missing.

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% across 7 parameters, so the description must compensate, and it does for the domain-shaped ones — it explains that facts carry content/category/entities, rules carry rule_type plus term or note, and lists personas and brand_profile fields, all in the shape the preview returned. It does not explain 'source' or 'project_id', leaving two parameters undocumented anywhere.

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 concrete verb+resource ('Write the reviewed selection from import_meeting_preview') and explicitly ties itself to its sibling preview tool, so an agent can tell it is the apply step of a two-phase import. No ambiguity about what is being written or where it comes from.

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?

Implies the workflow condition: use this after import_meeting_preview, passing only the items the user approved. That is clear context for invocation, but there is no explicit when-not or alternative path (e.g., what to do if the user rejects everything or the preview is stale).

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