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

No annotations are present, so the description carries the burden. 'Aggregate' and 'stats' convey a read-only operation, and it adds a useful behavioral detail: results are computed over a rolling window with optional windowHours. It does not document the default window length or response shape, but it does not imply any hidden side effect.

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?

Two concise sentences with the behavior front-loaded, the use case captured in one quoted phrase, and the optional parameter mentioned without repeating schema constraints. There is no filler or redundant detail.

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 no annotations, no output schema, and one optional parameter, this description covers the core purpose, the intended query, and the general counts returned. The main missing piece is the exact default window and whether results are grouped per launchpad, but the 'which launchpads are hot' cue makes the return semantics reasonably clear.

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 schema only provides an integer type and a minimum with no textual description, so the description's mention of 'Optional windowHours' and 'rolling window' adds the needed conceptual meaning. It does not say what the default window is when omitted, but for a single, clearly named optional parameter this is solid compensation for zero schema coverage.

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?

States a specific action ('Aggregate launchpad stats'), the resource ('launchpad'), and the key output dimensions ('creations/graduations counts') over a time window. It also clearly differentiates this from sibling per-token metadata/price tools and from list_creations/list_graduations.

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?

Provides a clear usage condition: use for 'which launchpads are hot'. It does not explicitly list alternatives or say when not to use it, so it stops short of a 5, but the quoted use case gives an agent enough context for selection.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals a useful error semantic (404 → mint not in Anaxer yet) and implies a read-only lookup, which meaningfully helps the agent anticipate outcomes beyond simple success.

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?

Two short sentences carry the full payload: what is returned, when to use it, and a special error case. No filler or redundant restatement of the tool name.

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 single-parameter lookup with no output schema, the description tells the agent what fields to expect and how to interpret a 404. It is slightly light on details about the shape of 'socials' or why a mint might not be in Anaxer, but these are minor gaps.

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 input schema already documents the single 'mint' parameter with type and length constraints (100% schema coverage). The description adds only the phrase 'one mint,' which confirms singularity but does not add much beyond what the schema already conveys.

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 resource ('one mint') and the kind of data returned (name, symbol, supply, socials), and distinguishes this singular-lookup tool from its plural sibling get_tokens_metadata by emphasizing 'one mint.' The phrase 'metadata lookups' also separates it from price/trade tools.

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: 'Use for "what is this token" / metadata lookups.' It does not explicitly name alternatives or state when not to use it, but the singular vs. plural distinction and the lookup vs. price/trade framing provide clear context.

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

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

Without annotations, the description carries the burden; it discloses the 404 condition, which is a non-obvious failure mode. It doesn't mention any side effects or output structure beyond the price/mcap summary, but for a simple lookup this is adequate.

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?

Two sentences with all essential information: output, use case, and error semantics. No redundancy.

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?

The tool is simple (1 param, no output schema, no annotations), and the description covers purpose, selection, and error handling. It clearly states the key data returned (USD price, SOL price, market cap) and the 404 edge case.

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 already fully documents the only parameter ('Base58 mint address'), so coverage is 100%. The description adds no additional meaning beyond the singular 'one mint' context, which slightly reinforces cardinality.

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 names a specific resource ('one mint') and the exact outputs ('USD + SOL price and market cap'). It also gives a concrete use case ('what's X worth now'), which distinguishes it from sibling list tools like get_token_prices.

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 explicitly provides a use case ('what's X worth now') and error context (404 = no live price). It doesn't name sibling alternatives, but the singular 'one mint' contrasts with the plural get_token_prices, giving implied selection criteria.

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

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

With no annotations, the description carries the full disclosure burden. It usefully reveals that missing prices are omitted rather than causing an error, but it does not mention auth needs, rate limits, or invalid-input handling. The one behavioral detail is valuable but not comprehensive.

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?

Each sentence earns its place: the core operation, the missing-price behavior, and the sibling comparison. There is no filler or redundant explanation.

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 one-parameter tool with fully documented schema, the description is largely sufficient. It explains the output behavior for missing prices and how to choose it over get_token_price. A fuller return-structure note would help since there is no output schema, but the essential invocation context is clear.

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 the 'mints' parameter and its limits. The description repeats the 50-mint limit but adds no new parameter-level meaning beyond what the schema provides.

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: batch retrieval of latest prices for up to 50 mints. It clearly differentiates from the closely related sibling get_token_price by framing this as the batched counterpart.

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 explicit routing guidance: 'Prefer over many get_token_price calls' tells the agent when to use this tool versus the single-price sibling. This is direct and actionable, with no ambiguity about the intended use case.

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

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

With no annotations, the description carries the burden of behavior disclosure. It reveals a non-obvious behavior: missing/never-observed mints are omitted rather than causing an error. It also caps the batch at 50. It does not explicitly state this is read-only, but 'metadata' strongly implies a read operation and no mutation is suggested.

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?

Two short sentences, each earning its place: one states the core operation and limit, the other documents a key edge-case behavior and the recommended use relative to the sibling. No filler or redundancy.

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 one-parameter batch read tool, the description covers the essential calling context: batch size, handling of absent mints, and the preferred use pattern. It lacks an explicit note about the return format or ordering, but the absence is minor given the simple resource and sibling naming.

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 the mints parameter thoroughly, including type, length limits, min/max array size, and base58 encoding. The description adds little beyond restating 'up to 50 mints,' but it does reinforce the batching semantic. 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 clearly states a specific verb and resource: 'Batch metadata for up to 50 mints,' which immediately distinguishes it from the singular sibling tool get_token_metadata. The behavior for missing mints adds further precision about what the 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?

The description explicitly tells the agent when to use this tool: 'Prefer over many get_token_metadata calls.' It also implicitly contrasts with the singular sibling, giving clear routing guidance without needing to inspect either tool's schema.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It reveals paging behavior, cursor contract, source cardinality, and mayhem filtering. It does not describe the page payload or the semantics of to/from, so it falls just short of a 5.

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, each carrying a distinct actionable constraint: resource/scope, source cardinality, mayhem filter, and pagination. No filler or repetition; critical caveats are inline where they matter.

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 six-parameter paginated list with no annotations and no output schema, the description covers the main invocation path well. But the undocumented to/from parameters and unspecified page fields beyond next leave meaningful gaps for an agent.

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 50%, and the description adds real value: source is clarified as a singularity ('NOT an array'), excludeMayhem is explained as dropping mayhem-mode launches, and cursor is tied to the previous response's next. However, to and from remain entirely unexplained in both schema and description.

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?

Description states the exact resource ('recent token creations (launches)') and scope ('one page') with a clear verb. It also distinguishes itself from tail_stream by noting this is not a multi-source array tool, which removes ambiguity among siblings.

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?

Explicitly names the alternative for live multi-source use ('tail_stream with sources'), gives the single-source constraint, and provides the full pagination procedure: pass previous next, stop when next is null. This is direct when-to-use and how-to-use guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains pagination behavior (cursor/next, stop when next is null), the singular constraint on source, and the purpose of filter parameters. It does not mention rate limits, safety, or response format, but for a read-only listing tool the disclosed behaviors cover the key usage pitfalls.

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 four short sentences, front-loaded with the purpose, then usage details. There is no fluff or repetition. It could be slightly more compact by merging the filter guidance, but every sentence earns its place, covering the essential calling pattern.

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 7 parameters, no annotations, and no output schema, the description is not fully complete. It thoroughly covers pagination and filter intent, but omits the purpose of 'to' and 'from' and gives no indication of the response shape beyond the 'next' field. An agent could still call it correctly if it knows the domain, but there are notable gaps in parameter meaning.

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 only 43% (3 of 7 params have descriptions), so the description must compensate. It adds meaning for minLiquiditySol and excludeMayhem ('filter junk') and reinforces that source is not an array. However, it leaves 'to' and 'from' entirely unexplained (likely a time range), and does not clarify the semantics of 'limit' beyond what the schema already states. Partial compensation for the gap.

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: 'One page of recent graduations/migrations.' It clearly identifies the scope (recent, one page) and the resource type, which distinguishes it from siblings like list_creations by subject matter. However, it does not explicitly name sibling tools to help disambiguation, so it falls short of a 5.

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 operational guidance on pagination ('call again with cursor set to previous next') and filtering ('Use minLiquiditySol / excludeMayhem to filter junk'), which helps when calling the tool. But it does not explain when to choose this tool over alternatives like list_creations or list_token_trades; the context is implied by the resource name only. No explicit exclusions or alternatives are given.

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

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

With no annotations, the description carries the full burden, and it discloses the key behaviors: this is a snapshot REST query rather than a live stream, quote assets are rejected as mint, solOnly filters to SOL-paired rows, and pagination terminates when `next` is null. It does not mention auth requirements, rate limits, or error conditions, but for a read-only list tool the most decision-relevant behaviors (paging, filtering semantics, live-vs-history) are all disclosed.

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?

Five dense sentences, each carrying a distinct concern: scope, inclusion behavior, rejected inputs + alternatives, solOnly/paging/limit guidance. Front-loaded with the core purpose and sibling differentiation. It is longer than the TDQS high example but every sentence earns its place — no filler or repetition of annotation data (there are none).

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 7-parameter tool with no output schema and no annotations, the description covers the essential ground: result scope, paging protocol, param semantics, and alternative routing. The main gap is the return row shape — with no output schema, an agent must infer what a swap row contains — but the paging and filtering behavior needed to call it correctly is fully specified.

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 baseline is 3. The description still adds meaning beyond the schema: the mint param's rejection of quote assets (SOL/USDC/USDT) is a semantic constraint absent from the schema's 'Base58 mint address', and the cursor param's termination condition ('stop when `next` is null') extends the schema's paging note. It also frames source as singular and routes array-style filtering to tail_stream, reinforcing the schema's warning.

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 opens with a specific verb+resource+scope: 'One page of recent swaps where `mint` is either swap leg' — precise about what is returned and how the result is bounded. It also distinguishes itself from tail_stream by labeling itself 'REST history, not a live tail', and states the inclusion of token↔token rows. An agent can tell exactly what this tool does and how it differs from siblings without opening schemas.

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?

Alternatives are named explicitly with the conditions that select them: quote assets should go to get_token_metadata / get_token_price, and live multi-source filtering should use tail_stream with `sources`. It also gives operational when-to guidance: paging protocol ('pass `cursor` = previous `next`; stop when `next` is null') and 'Prefer limit ≤ 20 (default) to conserve context'. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and delivers: it discloses bounded collection, automatic termination, unsubscribing, event/time caps, and per-channel valid filter keys. It also flags a critical schema nuance ('sources' is an array unlike REST tools) and the solOnly quote-asset rejection. This is rich behavioral context beyond any structured annotation.

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?

Every sentence carries distinct information: core behavior first, termination semantics second, filter nuance third, and usage boundaries last. The length is justified by the tool's complexity, and there is no 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?

For a 4-parameter tool with nested filter objects, no output schema, and no annotations, the description covers inputs, termination guarantees, per-channel semantics, exclusions, and when-to-use guidance. No critical operational fact is missing for an agent to invoke it correctly.

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 only 25%, and the description compensates thoroughly: it enumerates valid filter keys for every channel, explains the sources array shape, and details the solOnly edge case. It also restates maxEvents/timeout semantics in behavioral terms, adding meaning beyond bare schema constraints.

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?

Description opens with a specific verb-object pair ('Collect a bounded batch of live WebSocket events') and immediately describes the terminal behavior (return and unsubscribe), distinguishing it from streaming or historical tools. It also explicitly says 'No transfers channel in v1' and contrasts with list_* tools, leaving no ambiguity about what the tool is for.

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 last sentence gives direct usage guidance: 'Use for short live watches / summaries, not history (history → list_* tools).' It also clarifies that there is no transfers channel in v1, preventing invalid calls. This explicitly routes the agent to alternatives for historical use.

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