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

With no annotations, the description carries the full behavioral disclosure burden, but it only offers the terse 'Free.' and a list of returned data. It does not explicitly state that the operation is read-only, whether authentication or a wallet connection is required, or whether any state is changed.

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 very short and front-loads the 'Free.' qualifier before listing the three key data points. It is economical, though it could be slightly more explicit about what 'Free.' means.

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 status tool the description is largely sufficient, but without an output schema or annotations it leaves gaps around return format, authentication, and the exact meaning of 'Free.'. It is adequate but not 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?

The input schema has zero parameters, and the description does not need to compensate for any parameter documentation. The baseline of 4 applies; the description simply confirms what the tool returns.

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 what the tool surfaces: current prices, wallet balance, and today's spend against a daily limit. It lacks an explicit verb and does not differentiate itself from siblings, but the resource and information scope are 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?

There is no guidance about when to call this tool versus new_base_pools or verify_claim. The intended use is only implied by the name 'status' and the listed data; no exclusion or alternative scenarios are described.

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 and does so thoroughly: it reveals the monetary cost and payment source, per-call pagination, newest-first ordering, flag value semantics (true/false/unknown), per-fact read blocks, and the condensed vs. full paid answer return shape. This is substantial context well beyond the schema.

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: three sentences cover the resource, ordering, pagination, cost, payment method, filters, flag semantics, and response shape. Every clause adds information and none repeats what the schema already states.

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 no annotations and no output schema, this description covers the critical decision factors: what is listed, how much it costs, how filters and pagination work, and what the response contains (a condensed page plus a path to the full paid answer). Some domain phrasing such as 'Assay's recent window' and 'condensed page' is left undefined, but an agent still has enough to invoke the tool 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 description coverage is 0%, so the description must compensate, and it does by mapping all four parameters (dex, flag, not_flag, cursor) to meaningful roles, including explaining cursor as 'the previous page's next_cursor.' It could go further by listing valid flag names or clarifying the exact flag/not_flag distinction, but it is a strong compensation for empty schema descriptions.

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: 'Liquidity pools created on Base mainnet... newest first, one page per call.' It clearly identifies what is returned, the ordering, and the pagination behavior, which is enough to distinguish it from siblings like verify_claim and assay_status.

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 useful context—filters, the $0.02 cost, wallet payment, and one page per call—so an agent can judge when to use it. However, it does not explicitly mention alternatives or state when not to use it; the usage guidance is implied rather than made explicit.

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, and it delivers: it discloses costs ('$0.50 in USDC on Base, paid from your wallet'), processing constraints ('URLs are not fetched'), output behavior ('No single verdict'), and execution order ('payment settles before the models run'). This is unusually transparent for a tool description.

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 earns its place: core action and output first, then the verdict expectation, cost, input restriction, and payment timing. The description is tight, front-loaded, and free of filler while still packing significant operational 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?

The description covers the return value well enough for a tool with no output schema, and it explains cost, payment flow, and input restrictions. It falls just short of full completeness because the 'questions' parameter is unmentioned and the model families are not identified, though neither is strictly required to invoke the tool 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?

The schema has 0% description coverage, so the description must compensate, but it only indirectly addresses 'claim' and 'sources' via 'Check a claim against passages you paste.' The optional 'questions' parameter is never explained, so an agent has no guidance on what that parameter controls or when to supply it.

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 ('Check'), a clear resource ('a claim against passages you paste'), and an explicit output ('every family's vote with the quotes it relied on'). This makes the tool's function immediately identifiable and clearly distinct from its unrelated siblings, new_base_pools and assay_status.

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 clear usage context: use it when you have a claim and pasted passages to verify against. It also provides a firm exclusion: 'Pasted text only; URLs are not fetched.' It does not name alternatives, but the sibling tools are unrelated, so explicit alternative routing is less necessary.

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