maeil

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 explains possible return values (sent, accepted, declined, failed) and the nuanced behavior of the revealed email being null until acceptance. This is useful, though it doesn't mention side effects or authentication requirements, which are likely minimal.

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 two concise sentences, front-loaded with purpose and immediately followed by return value details. Every sentence earns its place with no fluff or repetition.

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 simple one-parameter read-only tool with no output schema, the description is remarkably complete: it explains the statuses, the email retrieval behavior, and the null-until-accepted nuance. There's no missing critical information for an agent to use the tool correctly.

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?

The input schema already fully documents the single parameter 'invite_id' with a description pointing to send_calendar_invite. The tool description doesn't add semantic value beyond that, so the baseline of 3 applies given 100% schema coverage.

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 purpose: to check invite status (accepted/declined) and retrieve the recipient's email once accepted. It uses a specific verb+resource ('check whether a sent invite...') and naturally distinguishes itself from the sibling 'send_calendar_invite' by focusing on status retrieval rather than sending.

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 implies usage after sending an invite ('sent invite') and clarifies that the email is only available after acceptance, giving clear context. However, it does not explicitly mention when not to use it or compare it to the sibling tool, 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.

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

With no annotations, the description carries the full burden. It discloses key behaviors: the invite is sent as a text message, the recipient's email is returned on acceptance, and it can be retrieved via get_invite_status or callback_url. It also notes legal consent requirements. However, it doesn't clarify what happens on decline or the direct response format, leaving a minor gap.

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 concise, front-loaded with the core purpose, and uses four sentences that each add critical information: what it does, how it works, regional restriction, and consent requirement. No filler or redundancy.

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?

The tool is moderately complex with 9 parameters and no output schema. The description explains the invitation flow and constraints well, but it does not specify what the direct API response contains (e.g., an invite ID, success status) or mention error scenarios/async behavior. Since there is no output schema, this absence leaves a completeness gap for agents handling the response.

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?

The schema provides 100% description coverage for all parameters, so the baseline is 3. The description adds contextual flow (SMS delivery, email reveal, callback behavior) but does not add parameter-level syntax beyond what the schema already provides. It reiterates the consent requirement but adds little semantic value.

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 purpose: inviting a person to a calendar event via phone number and SMS. It distinguishes itself from the sibling tool get_invite_status by describing the invitation flow and where to retrieve the recipient's email.

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 explicit usage context: it mentions using get_invite_status as an alternative for retrieving the revealed email, restricts to US/Canada phone numbers, and mandates consent attestation. This gives clear when-to-use and when-not-to-use guidance.

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