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

With no annotations provided, the description carries the full burden and succeeds: it warns 'This sends real email and changes who can read their content,' states the first call 'shares nothing,' and discloses that strangers are invited to sign up. These are precisely the side effects an agent must know before invoking a sharing 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?

Four sentences with zero filler: purpose, recipient behavior, two-call workflow, and side effects each earn their place. The 'TWO CALLS' marker is unmistakable, and the side-effect warning lands at the end where it punctuates the confirm step.

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 side-effect-heavy tool with no annotations and no output schema, the description covers the preview/confirm contract, email sending, access changes, and recipient differentiation. It stops slightly short of describing what the confirm call returns or failure modes, but nothing needed to avoid a harmful call 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 coverage is 100%, so the schema already documents all six parameters. The description adds value beyond it by explaining the confirm_token's role in the two-call protocol and enriching the emails parameter with recipient-class outcomes (ordinary grant vs 'Shared with me' vs signup invite).

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 opening sentence names a specific verb and resource: 'Share a folder or document with people by email, so they can read or edit it.' The email-grant mechanism plus the 'TWO CALLS' preview/confirm pattern clearly distinguishes it from sibling tools like create_org_share_link and claim_share_link.

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 explicit workflow guidance: run the first call to preview exactly who would be mailed and at what level, 'Show that to the user, then call again with the token.' Recipient classes (org member vs other user vs stranger) are spelled out, but no alternative tools are named and there is no explicit when-not-to-use condition.

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