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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fully discloses the return values (admin URL, participation URL), a security note (keep admin URL private), and an important prerequisite side effect (verification email sent automatically if creator email is unverified). This is rich, actionable behavioral context beyond what a schema would provide.

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?

The description is four sentences, each earning its place. It opens with the core purpose, then immediately covers the two return URLs, and closes with the critical email verification behavior. There is zero fluff or repetition, and the most important operational detail (the verification email) is saved for last, which is a logical build-up.

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 the tool's moderate complexity (5 params, 3 required, no output schema), the description explains the crucial return values and the key edge case (verification email). It does not explicitly state the format of timeSlots or error handling, but the schema covers parameter structure, and the description covers the non-obvious workflow. A small gap is that it does not mention what happens if the email is already verified, but this is minor. Overall, it is sufficiently complete.

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 100%, so the baseline is 3. The description does not add any additional parameter semantics beyond the schema; it only mentions 'timeSlots' implicitly via 'a time that works for a group.' Since the schema already fully documents all five parameters, there is no need for the description to compensate, but it also does not add extra value here.

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 clearly states the tool's function with a specific verb and resource: 'Create a scheduling poll to find a time that works for a group.' It also uniquely identifies the tool by mentioning the admin and participation URLs, distinguishing it from sibling tools like close_poll or get_results. The purpose is unambiguous and specific.

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 provides clear context for when to use the tool: when a group needs to find a mutually available time. It also gives a specific usage flow for handling unverified emails ('Ask the user to check their inbox... then retry'). However, it does not explicitly contrast with sibling tools or mention when NOT to use it, so it falls short of a 5.

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