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

Consistent with readOnlyHint: true — nothing is created or mutated, and the description reinforces that by stating it 'returns signup, dashboard, and pricing links rather than creating the code.' It goes beyond the annotation by disclosing the account requirement (free via social sign-in) and the Pro tier gating, which the annotations do not convey.

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?

Three sentences, front-loaded with the most important constraint (it does not create anything), which prevents the most likely misuse. The final clause restates the non-creation point already made in sentence one, a minor redundancy that keeps it from a 5.

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?

With no parameters, no output schema, and a single readOnly annotation, the description carries the needed burden: what it returns (signup, dashboard, pricing links), what it does not do, and the account/tier prerequisites. It does not sketch what the returned instructions actually cover, but that omission is small for a documentation-only tool.

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 tool takes zero parameters and the schema is correspondingly empty, so there is nothing for the description to disambiguate. Baseline 4 applies since no parameter meaning is missing or misrepresented.

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 states a specific, falsifiable capability: it returns documentation rather than creating a QR code, and explicitly distinguishes itself from the link-minting behavior ('does not mint a /r/{code} short link'). It stops just short of naming the sibling (generate_qr_code) that would be the alternative, so the contrast is implied rather than explicit.

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?

'Instructions only — does not mint a /r/{code} short link' gives an agent a clear condition for selecting this tool (user wants guidance) versus not selecting it (user wants an actual code). It also flags that Pro is required for destination edits, version history, and scan analytics, which affects whether the guidance even applies to the caller. No sibling is named as the fallback.

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