purchase_uniswap_reward

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

Given that annotations are entirely absent, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explicitly states that rewards are never claimed, no wallet credentials are accepted, exactly one logical GET request is made, continuation pages are not auto-fetched, responses are limited to 100 rows and 256 KiB, truncation is reported, and oversized records are refused without partial fields. This is comprehensive and transparent, leaving no ambiguity about the tool's safety and operational characteristics.

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 dense block of text containing multiple clauses and qualifiers. It front-loads the core purpose but then dives into many behavioral caveats. Some sentences, such as 'Required inputs reflect tool policy as well as measured upstream requirements' and 'Other declared filters are forwarded as supplied; their effectiveness is not implied by the schema,' are vague and arguably irrelevant given the schema only has one parameter. It is not concise, though it is not excessively long either, earning a middle score.

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 a single parameter and no output schema, the description is quite complete in explaining what the agent can expect: read-only behavior, return type for decimal values (strings), response size limits, pagination behavior, and refusal of oversized records. It covers most operational aspects the agent needs to know. However, it does not describe the structure of the returned rows beyond 'liquidity reward rows', nor does it mention how to handle errors beyond truncation.

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 only one parameter, 'address', with no description in the schema (0% coverage). The description merely restates 'explicitly supplied blockchain address', which adds no meaning beyond the property name. It does not specify address format (e.g., 0x-prefixed), validation rules, or any additional context that would help an agent correctly populate the parameter. With such low schema coverage, the description should compensate, but it fails to do so.

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 tool reads public liquidity reward rows for a specific blockchain address, with a specific verb (read) and resource (liquidity reward rows). It distinguishes itself from the misleading 'purchase' prefix by clarifying it is a read operation. However, it does not explicitly differentiate from similar sibling tools like land_liquidity_allrewards, which might also read liquidity reward data, so it stops short of a perfect score.

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 no guidance on when to use this tool versus alternatives. It does not mention any sibling tools or conditions that would select this one. While it states that it never claims rewards and accepts no credentials, that is behavioral rather than usage routing. There is no 'use this when X, otherwise use Y' guidance, so the agent must infer usage from the name and description alone.

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