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

Goes beyond the annotations by disclosing the two-tier execution model (SQL offering-rule filter first, on-chain checks only for the current page), which tells the agent about cost, latency, and that results are page-scoped. 'Informational only' reinforces non-authoritative output and matches the readOnly/non-destructive hints. It does not state whether cached or on-chain status can disagree across pages.

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, front-loaded with the resource and the eligibility outcome, then execution behavior, then the disclaimer. No filler. The telegraphic phrasing of 'SQL-filters offering rules first' is efficient though slightly opaque.

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?

An output schema exists, so return-value detail is unnecessary, and the description covers what the screen returns and how it is computed. Against six parameters with zero schema coverage, a nested filters object, and cursor pagination, the definition leaves meaningful gaps an agent would need to call 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 description coverage is 0% across six parameters, so the description must carry parameter meaning and it largely does not: jurisdiction, investorType, walletAddress, limit, cursor, and the nested filters (chain/category/minYield) are never explained. Only a loose mapping from 'investor profile' to investorType/jurisdiction can be inferred, and the nested filters are undocumented in both places.

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 verb ('Screens') and a specific resource ('the UNIALL index'), plus the outcome classes it returns (ELIGIBLE or REQUIRES_ONBOARDING), so an agent knows this is a bulk screen rather than a single-asset check. It does not name any sibling, so the boundary with check_eligibility or find_assets must be inferred.

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: use this to enumerate what an investor profile can buy across the index. 'Informational only' signals it is not an authorization step, which helps. However, there is no explicit when-to-use/when-not guidance and no routing to check_eligibility for a single asset, so the agent must guess the split.

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