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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), yet the description adds genuinely new behavioral context: the composer URL carries post text with no link, the fan must attach an image saved from the card page, and it 'Never publishes or posts on their behalf.' That last clause is the key reassurance an agent needs before calling a share-flavored tool. The unresolved piece is what 'a ticket counts' actually means, which is left opaque.

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?

It is a single dense sentence plus a short safety clause, with the primary return value front-loaded and the conditional secondary return following. The parenthetical about the fan attaching their own saved card image is slightly convoluted, but every clause carries information.

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?

An output schema exists, so the description is not obligated to enumerate return fields, and it correctly focuses on the non-obvious parts: the conditional composer URL, the no-link constraint, and the no-posting guarantee. The one gap is that 'once a ticket counts' depends on ticket state known only through sibling tools, which an agent cannot resolve from this definition alone.

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?

There are zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description does not waste space restating schema content.

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 uses a specific verb ('Returns') tied to concrete resources: the fan's public card/profile link, and conditionally an X post composer URL plus post text. That is clearly distinct from sibling readers like get_fan or get_ticket_status. It stops short of explicitly naming which sibling to use instead when the caller actually wants profile data, so no direct sibling routing.

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?

A usage precondition is implied by 'once a ticket counts', which tells the agent output varies by state, and the fallback ('If there is none, explains why') sets the failure expectation. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative among the many siblings, so the agent must infer the trigger conditions.

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