Launch-window bundles

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

Annotations already mark this read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those: bundles are counted on peak net exposure rather than raw buy count, wallets that flipped are excluded, and heavy bundling that is still held is a rug predictor. It also discloses API-unit cost. This is rich, non-obvious behavioral disclosure with no contradiction.

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 one focused paragraph that front-loads the core definition, explains why the metric matters, gives explicit use and non-use cases, and closes with arguments and cost. Every sentence earns its place without repetition or filler.

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 the output schema exists, annotations cover safety, and the schema covers both parameters at 100%, the description is complete. It adds the missing contextual layer: when to use it, when not to, what the signal means, and what it costs. No important gap remains for an agent selecting and invoking this 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?

Schema description coverage is 100%, and both the chain enum/descriptions and the address format guidance are already fully detailed in the input schema. The tool description only names 'address and chain' and adds an API-unit cost note, which is useful but not needed for parameter semantics. Baseline 3 is appropriate.

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 verb and resource: 'bundle detection for one token'. It also explains the methodology (coordinated buys plus delayed sweeps, accounted on peak net exposure) and explicitly distinguishes itself from sibling tools like get_launch_snipers, get_lookalike_clusters, and get_dev_tracker. No ambiguity about what this tool does.

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?

It gives an explicit use case: any 'was this launch bundled' question. It then states what it is not for, naming concrete alternatives for lone fast buyers, post-launch clusters, and creator selling. It also adds cost context with 'one API unit on any chain', which helps an agent decide when to invoke it.

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