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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly indicates a read-only check and names the three values that determine the answer, which is far more transparent than a vague 'Check address status'. It does not mention handling of invalid addresses or any network-related assumptions, but the core behavior is clear.

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?

One sentence, front-loaded with the purpose, and every clause adds value by naming the actual flags involved. There is no repetition of the tool name 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?

For a single-parameter, read-only check with no output schema, the description is nearly complete. It tells the agent what will be evaluated and what the key result fields are; there is no other critical information an agent would need before calling the 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 schema already covers the address parameter with a description, and coverage is 100%, so the baseline is 3. The tool description adds a small bit of context by tying the address to launch permission, but it does not add format, chain, or additional parameter meaning beyond the schema.

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 action—checking address launch eligibility on Pons—and enumerates the exact factors involved (canLaunch, whitelistedLaunchers, global launchEnabled flag). This clearly distinguishes it from launch-related siblings like pons_preview_launch and pons_launch_costs.

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 'right now' phrasing implies this is a current-state eligibility check, which is reasonable guidance. However, the description never explicitly contrasts it with sibling tools or says when alternatives such as pons_preview_launch should be chosen instead.

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?

The description adds useful behavioral detail: exact event matching via "deployer = creator," sorting newest-first, and inclusion of per-token graduated status. With no annotations provided, the description carries most of the transparency burden; it does not disclose that results are bounded by limit/lookbackBlocks or address any auth/rate-limit behaviors. "All launches" slightly overstates the default bounded query since defaults include a 20-result limit and 50000-block lookback.

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 a single dense sentence with no filler. The scope is front-loaded, the parenthetical clarifies the matching rule, and ordering/status details are included without excess.

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 simple filtered-list tool, the description plus a fully documented schema covers the purpose, required parameter, optional bounds, ordering, and an output aspect (graduated status). There is no output schema and no annotations, so a bit more information about response shape or pagination would help, but an agent can invoke this tool correctly with what is provided.

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%, so the schema already documents creatorAddress, limit, and lookbackBlocks. The description adds the deployer-to-creator equivalence and clarifies the result ordering, but it does not materially extend the parameter semantics. Baseline 3 applies because the schema does the heavy lifting.

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 identifies the resource as launches by a specific creator and adds ordering and status context: "All launches by a given creator (TokenLaunched with deployer = creator), newest-first, with per-token graduated status." It differentiates from siblings like pons_recent_launches by making the creator filter explicit. It lacks an explicit verb such as "list" or "fetch," but the intent is unmistakable.

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 phrase "by a given creator" implies the intended use case: retrieve a specific deployer's launches. However, the description does not explicitly state when to use this tool over alternatives like pons_recent_launches or pons_v1_launches, nor does it mention exclusions or prerequisites.

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. It discloses the merging of CurveBuy and CurveSell events, the newest-first sort, and the returned fields. It does not cover edge cases (empty results, invalid address) or explicitly state read-only behavior, but the event-query nature makes this low-risk.

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?

One dense sentence with no filler; every phrase adds information about either the event set, fields, or ordering.

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 output schema and no annotations, the description lists the returned union of fields and ordering. It could have been more explicit about return shape or the meaning of 'amounts', but the schema covers input parameters, and the description is sufficient for a simple read-only query.

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?

All three parameters are fully described in the schema (curveAddress, limit, lookbackBlocks), so the description needn't re-explain them. It adds no new parameter-level detail, hence baseline 3.

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 the exact data: CurveBuy + CurveSell events for a single bonding curve, including the fields side, trader, recipient, amounts, fee, tax. It also specifies ordering ('newest-first'). This clearly differentiates it from sibling tools like pons_quote_buy or pons_pair_token_economics.

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 phrase 'on one bonding curve' establishes the scope: use when you need trade-level buy/sell event history for a particular curve. However, it doesn't explicitly mention alternatives or when not to use, so it's clear context but no exclusions.

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?

No annotations are present, so the description carries the burden. It states 'Read-only' and clarifies that native ETH is always returned while token data is conditional. However, it doesn't disclose behavior like zero-balance handling, network specificity, or potential reverts. The description adds the read-only hint but not much beyond that.

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?

One sentence that front-loads the core purpose and key conditional behavior. It is efficient and not padded, though slightly dense with multiple clauses. No wasted words.

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?

No output schema exists, so the description must explain return values. It does name vesting state fields (totalLocked, vested, releasable, terms) but leaves the fee balance return shape unspecified. For a read-only balance tool, an agent likely needs field names for the fee balances, which are missing. Partially complete.

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%, and the schema already documents both parameters: 'address' as recipient to check and 'tokenAddress' as optional token adding escrow balance and vesting state. The description repeats this without adding new semantics, so it meets the baseline of 3.

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 resource (shared PonsV2FeeEscrow) and the precise outputs: claimable fee balances (native ETH always, per-token when tokenAddress is given) plus buyback-vault vesting state (totalLocked, vested, releasable, terms). Clearly distinguishes from sibling tools that cover protocol overview, token info, launches, etc. Verb is implicit but the scope is unambiguous.

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?

Implies usage: check claimable fees for an address, optionally with a token to get token-specific balances and vesting state. No explicit exclusions or alternatives are named, but the description is distinct enough among siblings that an agent would select it when needing fee/vesting data. Lacks explicit when-not-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, the description carries the behavioral burden. It discloses the error condition NOT_A_LAUNCH for non-Pons-launched tokens and differentiates real vs phantom curve reserves, going well beyond the tool name. It does not explicitly state read-only semantics, but 'get' and 'Full state' plus the absence of side-effect warnings make the behavior reasonably transparent.

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?

A single information-dense sentence front-loads the core purpose and then lists the exact return areas and the key error. Every clause earns its place; there is no filler or repetition of the schema.

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 read tool with no output schema, the description covers the input domain, the major return sections, and the main error case. It does not spell out exact field names or types, but the listed categories are enough for an agent to decide whether this tool satisfies the user's request.

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 describes tokenAddress as 'Token contract address,' and coverage is 100%. The description adds important semantic scope: the address must correspond to a token launched via the Pons factory, otherwise the call errors. That extra constraint justifies a score above the high-coverage baseline.

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 retrieval action ('Full state of one Pons-launched token') and enumerates what is included: getLaunchedToken struct, ERC-20 metadata, curve reserves, graduation progress, snipe tax, and fees. This distinguishes it from sibling tools that target single metrics or protocol-level overviews, even without naming them.

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 context is implied: it is the tool to call when you need the complete state of one Pons-launched token, and the NOT_A_LAUNCH error signals a validity constraint. However, it never explicitly names alternatives or states when to use a sibling tool instead, so the agent must infer routing from the field list.

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 does well by disclosing that the measured values are static, dated 2026-09, clearly labelled, and that eth_gasPrice is live. This prevents an agent from treating old measured values as current, though it does not describe output format or units.

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?

A single dense sentence conveys scope, data vintage, static nature, labelling, and live comparison with no filler. Every segment earns its place.

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 parameterless lookup tool with no output schema, the description is mostly complete: it tells the agent what data is included and how current it is. It stops short of specifying units or exact return shape, but 'clearly labelled' partly compensates.

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 has zero properties, so there are no parameter semantics to document. The baseline of 4 applies, and the description appropriately does not attempt to describe parameters.

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 clearly states the tool reports measured launch/buy/sell gas costs on Pons plus live ETH gas price for comparison. It names the specific resource and metric, and is distinct enough from sibling tools even though no sibling is explicitly referenced.

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?

Usage is implied: call it when needing Pons gas cost data or when comparing historical measured costs against the current eth_gasPrice. However, it does not explicitly state when not to use it or mention alternative sibling tools.

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?

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only lists returned economics fields and does not state whether the operation is read-only, whether special authorization is needed, or any limitations or edge-case behavior. For a query tool this is a meaningful gap.

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 a single concise sentence that front-loads the core resource and then enumerates the key economics fields. It contains no filler, repetition, or unnecessary 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?

This is a low-complexity tool with one required parameter, no enums, and no nested objects. The description provides enough information to select the tool and invoke it with a pair-token address. Exact output formatting and deeper meanings of terms like 'phantom quote' are not documented, but the core selection and invocation context is present.

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 already fully documents the single parameter as 'Pair token contract address', giving 100% schema description coverage. The description adds useful context by clarifying that these are pair-token economics from the factory and giving example pair types (ETH or USDG pairs), but it does not add format, constraints, or additional parameter detail.

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 ('pair-token economics from the factory') and lists concrete data fields: approved status, phantom quote, graduation threshold, and decimals. This makes the tool's intent clear and separates it from generic token tools such as pons_get_token, though it lacks an explicit verb like 'retrieves'.

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 implies when to use the tool: when you need pair-token economics such as approved status, phantom quote, graduation threshold, or decimals. However, it does not explicitly mention alternatives or say when not to use it, leaving some selection burden on the agent.

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 full burden. It clearly states the operation is a read ('Read the factory's...'), discloses the specific data returned, and mentions the use of live timelock and execution-window constants for status computation, which is useful transparency. It does not discuss error cases or side effects, but as a read operation, that 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?

A single compact sentence that front-loads the action and resource, then lists outputs and method. No fluff.

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 description is complete for a simple one-parameter read tool: it specifies input, output fields, and how the status is computed. Even without an output schema, an agent knows what to expect. The only minor omission is behavior when no pending change exists, but that is an 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 description coverage is 100%—`tokenAddress` is described as 'Launched token address'. The description adds no new parameter semantics beyond the schema, 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 uses a specific verb ('Read') and identifies the exact resource (`factory's pendingCreatorFeeRecipient` for a token), then enumerates the returned fields. This distinguishes it clearly from sibling tools like `pons_fee_balances` or `pons_get_token`.

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 doesn't explicitly name alternatives or say when not to use it, but the focused purpose of reading a pending fee change is clear from the description. An agent can infer this is the tool to check the status of a scheduled creator fee change, distinct from fee balance reads.

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 burden. It explicitly guarantees 'performs no writes' and enumerates what the agent should expect to receive. It doesn't cover error behavior or authentication, but for a read-only preview the key safety trait is 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?

Two dense, front-loaded sentences with no filler. Every clause adds value: the action, the output list, the explanation promise, and the no-writes safety guarantee.

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 tool with two optional parameters, no output schema, and no annotations, the description covers the return contents, the safety profile, and the intended use. Listing the decoded fields and the bytes32 guard gives an agent enough to invoke the tool and interpret the result.

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 baseline is 3. The description reinforces that pairToken relates to pair-token economics and launchConfigId selects the launch config, but it adds no syntax, default, or format details beyond what the input schema already 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 opens with a specific action, 'Preview a launch config before launching,' and lists concrete outputs: decoded getLaunchConfig fields, the previewLaunchEconomics bytes32 guard, and pair-token economics. This makes it easy to distinguish from the many pons_ sibling tools even without naming them.

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 clearly states the intended use case ('before launching') and explicitly notes that it 'performs no writes,' signaling it's a safe pre-flight check. It doesn't name alternatives like pons_can_launch, but the context is clear enough for an agent to pick this over mutation or quote tools.

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 must convey behavioral traits itself. It states that launch configs are 'decoded' and describes a read-only-looking overview of protocol parameters, but it does not explicitly confirm the operation is non-mutating, require no auth, or describe response shape. The absence of side-effect language is mildly informative but not a full disclosure.

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 a single compact sentence that front-loads the core purpose ('protocol parameters on Robinhood Chain') and then efficiently lists the concrete contents. No filler or redundant wording is present.

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 there are no parameters and no output schema, the description does a good job of explaining what the agent will receive by listing the major data categories and an explorer link. It could be slightly more explicit about the overall return container or the fact that this is a read-only protocol snapshot, but the coverage is strong for a zero-parameter overview 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 has zero parameters, so the schema already fully covers parameter semantics and the description needs to add nothing about parameters. The baseline of 4 applies here because there is no parameter documentation burden to compensate for.

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 identifies the tool as providing Pons launchpad protocol parameters on Robinhood Chain and enumerates the specific contents (launch fee, enabled flag, max creator tax, snipe-tax start/duration, decoded configs, contract addresses, explorer link). This distinguishes it from the token- and pair-specific sibling tools without needing to open any 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?

The description implies this tool is for protocol-level launchpad settings rather than token-specific data, but it does not explicitly say when to prefer it over siblings like pons_snipe_tax, pons_launch_costs, or pons_pair_token_economics. The usage context is inferable from the content list, but no direct guidance or exclusions 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 provided, the description carries the burden. It clearly explains the behavior: local exact curve math, cross-checking against an on-chain eth_call, and disclosing specific outputs (tokensOut, fee legs, price impact, cross-check result). It also mentions the clamp at reserved allocation and live snipe tax, giving agents insight into the calculation's nature.

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 a single, well-constructed sentence that front-loads the purpose and includes essential details without redundancy. Every phrase contributes to understanding the tool's function and output.

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 tool's complexity (3 params, no output schema), the description provides sufficient context: it lists the return values and the key computational aspects. It implies a read-only operation via 'Quote' and covers the main behavioral nuances. Minor gaps like error conditions or execution limitations could be added, but the description is adequate for safe invocation.

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%, so the schema already documents all parameters. The description does not add significant meaning beyond the schema; it mentions 'snipe tax' but the schema already explains recipient's role in pricing it. Thus, no added value beyond baseline.

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 ('Quote') and resource ('bonding-curve buy'), and distinguishes itself from siblings by focusing on buy operations. It details the exact math and cross-check, making the tool's function unambiguous.

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 implies usage for quote buy operations but does not explicitly state when to use this tool over siblings like pons_quote_sell or pons_quote_swap. No alternatives or exclusions are mentioned, leaving the selection inference to the tool name and 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?

No annotations are provided, so the description carries the full transparency burden. It discloses the calculation approach, fees-on-output handling, state-diff overrides, the eth_call cross-check, and the quote result fields. It doesn't explicitly state 'no transaction is executed', but 'eth_call' and 'quote' strongly imply read-only behavior.

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 a single dense sentence with no filler. Every clause adds value: the operation, the math model, the on-chain cross-check, and the returned fields.

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 there is no output schema, the description helpfully names the return values and the cross-check result. It gives a solid mental model for a quote tool, though it stops short of defining the meaning or units of each returned field or explicitly stating that no trade is executed.

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%, so the baseline is 3. The description adds useful context around fees and output fields, but it doesn't elaborate on how tokenAmount or seller map into the quoted result beyond what the schema already states.

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 and resource, 'Quote a bonding-curve sell', immediately distinguishing it from buy/swap siblings. It also specifies the mechanism: local exact curve math cross-checked against an on-chain eth_call of sell().

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 use case is clear: quote a sell on a bonding curve. However, it never explicitly says when to prefer this over pons_quote_buy or pons_quote_swap, nor does it mention any exclusions or prerequisites.

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 burden and does add useful facts: it is on-chain via V4Quoter, includes hook fees, supports both native-ETH and ERC-20 quoted pools, and returns amountOut, gas estimate, pool key, and price/liquidity state. It does not explicitly state that quoting is read-only or describe error/failure behavior, so it falls short of fully transparent.

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 compact and front-loaded, with the core action and scope in the first sentence. The output list is dense and informative, though the compressed notation 'sqrtPrice/tick/liquidity' and the fragment-style second sentence keep it from being perfectly polished.

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 and no output schema, the description supplies most necessary context: the quoting mechanism, fee behavior, supported pool types, and the returned values. The main missing pieces are explicit guidance for choosing between sibling quote tools and a fuller description of return-value format, but an agent can still invoke the tool correctly using the schema.

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 the schema already documents the nuanced side/amount semantics, including the buy/sell distinction and pair-token versus ETH units. The tool description reinforces the existence of native-ETH and ERC-20 pools but adds no new parameter-level detail beyond the schema, so the 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 the action ('Quote a Uniswap V4 swap') and the exact resource scope ('GRADUATED token', 'on-chain V4Quoter', 'hook fees included'). It also enumerates the returned fields, giving it stronger identity than a generic quote tool. It does not explicitly name sibling tools, but its specificity is enough to distinguish it from vague alternatives.

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 phrase 'for a GRADUATED token' implies the tool is meant for post-graduation pools, and 'Native ETH-quoted and ERC-20-quoted pools' clarifies the pool types it supports. However, it never explicitly says when to use this tool instead of pons_quote_buy or pons_quote_sell, leaving sibling selection 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 provided, the description carries the full burden. It discloses ordering ('newest-first'), the event source, and output fields, but does not explicitly state that this is a read-only operation, clarify what 'swept token/pair amounts' precisely means, or mention behavior such as empty results or block-range edge cases. Acceptable but not rich.

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?

One dense sentence with no filler. The action, ordering, and output fields are front-loaded, and every phrase earns its place. This is an ideal length for a simple event-scanning tool.

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 straightforward read-only scanner with 100% schema coverage, the description is largely complete: it lists the returned fields, which matters because there is no output schema. It could add a touch more context about the factory contract or result shape, but nothing essential is missing for invocation.

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%, so the baseline is 3 even though the tool description adds no parameter-level detail. The schema fully documents 'limit' and 'lookbackBlocks', including defaults, ranges, and units, so the description does not need to compensate.

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 verb ('Scan'), a concrete resource ('factory PoolGraduated events'), an explicit ordering ('newest-first'), and the exact returned fields. This clearly differentiates it from siblings like pons_recent_launches and pons_creator_launches without needing to inspect the schema.

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?

Usage context is implied rather than stated: an agent can infer 'use this when needing recent PoolGraduated events' from the description. However, there is no explicit when-to-use versus alternatives, no mention of exclusions, and no guidance about which sibling to choose for other graduation-related queries.

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 behavioral burden. It adds useful context beyond the schema: the event source, newest-first ordering, server-side vs client-side filtering behavior, and the exact output fields. It could mention pagination or error behavior, but for a simple read-only scan this is reasonably transparent.

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 short sentences with no filler. The action, source, ordering, filters, and return fields are covered in a dense, front-loaded structure.

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 zero-required-parameter query tool, the description covers the essential aspects: event source, sort order, optional filters, and return values. The schema covers limit and lookbackBlocks semantics. The main gap is the absence of explicit guidance on when to prefer this over sibling launch-list tools.

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%, so the schema already documents all four parameters. The description restates the deployer and pairToken filters in prose and adds 'server-side topic' for deployer, but it does not materially enrich parameter 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 uses a specific verb ('Scan') with a precise resource ('factory TokenLaunched events'), adds ordering ('newest-first'), and lists the returned fields. This clearly distinguishes it from related siblings like pons_recent_graduations, pons_creator_launches, and pons_v1_launches.

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 context is clear: use this tool to scan recent factory TokenLaunched events, with optional deployer and pairToken filters. It does not explicitly contrast itself with the sibling launch-list tools, so an agent must infer when this is the right choice over pons_creator_launches or pons_v1_launches.

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 states the data source (on-chain only), the scoring criteria (unique buyers excluding deployer, ETH in curve, buy/sell mix, age), the serial-deployer filter, and the no-LLM/no-spend constraints. It also discloses the sort order. This is unusually transparent about how the tool behaves.

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 definition is a single information-dense sentence with the core purpose front-loaded. The parenthetical metric list packs many details together and could be reformatted for readability, but every clause earns its place.

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 simple two-parameter scan tool with no output schema, the description covers what it computes, on what data, and how results are ordered. It does not describe the return payload shape, which would help, but the absence of an output schema lowers that burden.

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 describes both parameters completely, including limits and defaults, so the description does not need to repeat them. The description adds only high-level context, which is adequate given 100% 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?

The description opens with a specific action ('Score') and a clear resource ('recent Pons v2 launches'), then lists the traction metrics used. This makes the purpose immediately understandable, but it does not explicitly differentiate it from sibling tools such as pons_recent_launches or pons_creator_launches.

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 implies the tool is for screening recent launches via on-chain metrics, and 'No LLM, no spend' hints at a cost-sensitive use case. However, it gives no explicit guidance on when to choose this tool over the many related Pons siblings.

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 burden of behavioral disclosure. It explains the dynamic decay of the tax (99% at launch → ~0% after 3s), lists the returned data (exemption status, launchedAt, seconds since launch, active window), and implies this is a read-only lookup. It does not explicitly state 'read-only' or cover edge cases, but it is substantially more transparent than a generic getter.

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 a single dense sentence that front-loads the core concept and packs in the key behavioral and output details without wasted words. Every clause earns its place.

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 that there is no output schema, the description does well to enumerate the returned fields: tax percentage, exemption status, launchedAt, seconds since launch, and active-window flag. It is complete enough for an agent to invoke the tool correctly, though it does not describe the output structure or mention any error conditions.

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 the schema already explains both curveAddress and recipient, including the default for recipient. The description adds color by referring to 'recipient on a curve' but does not provide significant additional parameter semantics beyond the schema.

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 identifies the resource (snipe tax on a bonding curve) and the recipient, and the unique 'snipe tax' concept distinguishes it from sibling tools. However, it lacks an explicit verb such as 'Gets' or 'Returns', so the action is implied rather than stated.

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?

No guidance is given about when to use this tool versus siblings like pons_quote_buy or pons_pair_token_economics. The intended use is only implied by the tool name and the description's focus on snipe tax data, with no explicit context, prerequisites, or exclusions.

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. It does add behavioral detail by explaining how burned amounts are derived (balances at 0x...dEaD and 0x0...0) and that a burn percentage is computed. However, it never explicitly states the tool is read-only or side-effect-free, nor does it cover edge cases or response shape.

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 compact sentences with the core purpose and burn computation front-loaded, followed by the default-token note. There is no wasted wording, though the second sentence is a bit terse.

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 optional-parameter read with no output schema, the description communicates what is calculated. Still, it lacks detail on the return format (e.g., human-readable vs raw units) and doesn't explain when the default is used vs. when an explicit address is required, so an agent still has some ambiguity.

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%; tokenAddress's description already says 'default: PONS token', and the tool description merely repeats that default. No additional parameter semantics are added, so the schema-covered baseline of 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 operation: calculating ERC-20 total supply and burned amounts derived from the zero/dead addresses, plus burn percentage. It also identifies the resource (PONS token by default). It doesn't explicitly distinguish itself from siblings like pons_get_token or pons_protocol_overview, but the semantics are clear enough.

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?

No usage guidance is provided. The description doesn't mention when to use this tool instead of a sibling (e.g., pons_get_token), nor any exclusions, prerequisites, or contextual conditions. An agent must infer when this tool is relevant.

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?

No annotations are provided, so the description carries the full disclosure burden. It honestly describes the returned data categories and, importantly, mentions the NOT_A_LAUNCH error condition for tokens absent from the legacy factory. It could say explicitly that this is a read-only query or describe how 'live' data is sourced, but overall it gives meaningful behavioral context beyond the tool name.

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 compact and information-dense, with no redundant fluff. The front-loaded 'V1 (legacy...) Pons launch state' quickly orients the agent, and the remaining sentences add necessary scope and error context. It is slightly list-heavy, but every clause earns its place.

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 read-only lookup tool, the description is largely complete: it enumerates what data is returned, clarifies legacy scope, mentions the closure date, and states the expected error. The lack of an output schema means the description should carry return-value information, which it does at a summary level. It does not explain the graduationStatus values themselves, but this is likely available elsewhere via sibling tools or documentation.

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 tokenAddress parameter with 'V1-launched token contract address', and schema description coverage is 100%. The description reinforces that the address must correspond to a legacy-factory token, but it does not add new format, validation, or normalization details. A baseline score of 3 is appropriate when the schema fully covers the parameter.

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 rather nerdy but exact definition states that this tool returns the V1 Pons launch state for a given token, covering legacy-factory record, graduation status, ERC-20 metadata, and getTokenInfo metadata. It clearly distinguishes this from the sibling pons_get_token by emphasizing the V1 legacy scope. The verb 'get' plus the resource 'V1 launch state' is 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?

The description provides clear context for when to use the tool: for tokens launched in the V1 legacy factory, and it notes that V1 is closed to new launches since 2026-08-12. It also gives an exclusion signal by stating that NOT_A_LAUNCH is returned if the token is not in the legacy factory. However, it does not explicitly name an alternative tool for non-V1 tokens, so it stops short of full when/alternatives 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, the description carries the behavioral burden. It discloses that this is a scan of events, returns newest-first, lists the event fields, and notes the deployer filter is applied server-side via topic. Minor details like pagination or empty-result behavior are not mentioned, but the core behavior is transparent.

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 no wasted words. The action and target resource are front-loaded, the field list is compact but informative, and the optional filter is stated after the core behavior. It does not restate schema details.

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 query tool with no output schema and no annotations, the description supplies the key return fields, ordering, and filter behavior, while the schema covers all parameter semantics. It could be slightly more explicit about the return envelope or pagination, but it is sufficient for correct invocation.

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%, so the parameters are already well-documented. The description adds only the 'server-side topic' nuance for the deployer filter, which is useful but not a significant extension beyond the schema. 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 names the exact resource ('V1 legacy factory's TokenLaunched events'), distinguishes its generation ('Uniswap V3 generation'), specifies ordering ('newest-first'), and enumerates the returned fields. This clearly separates it from siblings like pons_recent_launches and pons_v1_get_token.

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 provides clear context by scoping to the V1 legacy factory and noting the optional deployer filter as a server-side topic. It does not explicitly name alternatives or state when-not-to-use, but the V1-specific framing makes the intended use case reasonably clear.

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