new_base_pools

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.