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

Annotations only say non-readonly, non-idempotent, non-destructive. The description adds genuinely unavailable context: classic goes live immediately, ai becomes a draft and nothing is mailed or charged until sent, sending costs one credit, and invalid combinations are refused rather than silently converted. It also states the write-permission requirement.

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 'Two kinds of event' followed by two tightly packed sentences that each carry new constraints. Dense but every clause earns its place; only marginal polish would improve readability.

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 six-parameter creation tool with an output schema, the description covers mode semantics, draft versus live behavior, invite requirements, billing, permission needs, and refusal behavior. Nothing an agent needs to invoke 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%, so the description carries the full burden and largely meets it: mode maps to the two behaviors, dates is described as days or a daypart (classic) versus exact start times (ai), and invites is constrained to email-only guests. It leaves timeLabel and description unexplained, but adds substantial meaning the schema cannot convey, justifying a high score.

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 ('create event') and immediately partitions it into two named modes, classic vs ai, each with its own behavior. An agent can tell this apart from siblings like add_guests, add_dates, or send_invites without opening any schema.

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?

Gives explicit conditions for choosing each mode: classic for link-based day polls with no guest list, ai for autopilot events with a guest list and exact times, and routes the user to send_invites for sending. It also states a refusal rule for invalid combinations. It does not name sibling alternatives for modifying an existing event, so it stops just short of full when/when-not coverage.

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