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

The retry/idempotency-key contract ("reuse it for uncertain retries, including across HTTP/MCP clients") is genuinely valuable context that annotations do not convey. However, annotations declare destructiveHint=true and openWorldHint=true, and the description never explains what is destructive here (e.g., host notification emails, external visibility) nor mentions the emailAccess side effect; the personalUrl/url sentence describes outputs the schema does not declare.

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?

Only three sentences and correctly front-loaded with the retry contract, which is the highest-value detail. But the middle sentence is spent on personalUrl/url fields that do not exist as inputs, consuming scarce space that could have documented timezone, agent, or emailAccess.

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 an 8-parameter, non-read-only creation tool with no output schema and zero schema descriptions, the definition answers only a fraction of what a caller needs: how to retry safely and that email is required. Six parameters and the meaning of destructiveHint=true are left entirely unexplained, and one sentence points at parameters the schema does not have.

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 8 parameters, so the description must carry the burden, yet it only explains requestId and confirms email is required. The remaining parameters — title, timezone, name, agent, description, emailAccess — are undocumented, and it references 'personalUrl' and 'url', which are not in the input schema at all, which is actively misleading for a caller building the payload.

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?

"Create an event and register its host" gives a specific verb plus two concrete resources (event and host), so an agent knows exactly what side effect to expect. It does not explicitly distinguish itself from update_event or get_event, which are present in the sibling list, so routing still requires 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?

The description gives real operational rules: reuse requestId for uncertain retries, keep personalUrl for the host, share plain url with invitees, email is required for updates. These are useful usage constraints, but there is no guidance on when to create versus update an existing event, nor any prerequisites or exclusions relative to siblings.

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