growsurf_capture_referral_flow_screenshots

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

Annotations provide no safety hints (all false), so the description must carry the transparency burden. It discloses that URLs are short-lived, that the tool targets campaignId or falls back to GROWSURF_CAMPAIGN_ID, that it does not prove installed sites, and that it rejects arbitrary inputs. This is meaningful behavioral disclosure. A minor gap is that it doesn't mention any side effects (e.g., whether it stores or modifies anything), but given the read-like nature, this is acceptable.

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 three sentences, front-loaded with the core action, then constraints and targeting. It avoids filler but does repeat 'screenshot' a few times. Overall it is efficient and well-structured for an agent to parse quickly.

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 an output schema exists (which will define the return structure), the description covers everything an agent needs to decide when to use it and how to invoke it: the exact trigger, the limitation (does not prove installation), the rejection of arbitrary inputs, and the default behavior for the campaignId parameter. No critical context 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?

The single parameter `campaignId` is fully documented in the schema with 100% coverage, and the description only restates the same information ('Targets campaignId if you pass it, otherwise GROWSURF_CAMPAIGN_ID'). Since the schema already covers the semantics, the description adds no new meaning, so the baseline of 3 applies.

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 action: 'Capture temporary GrowSurf preview screenshots'—a specific verb with a specific resource. It also explicitly scopes the tool to the controlled referrer window and referred-friend experience, and disambiguates from any generic screenshot tool by stating it does not accept arbitrary URLs or external targets. This strongly distinguishes it from the listed sibling tools, none of which are screenshot-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?

Contains an explicit trigger condition: 'after the user explicitly asks for screenshots or screenshot proof.' It also names an alternative ('use browser automation for that') to clarify what this tool does not prove, and clearly states what it does not accept (arbitrary URLs, HTML, JavaScript, external targets). This leaves no doubt about when to use this tool versus alternatives.

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