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

With no annotations, the description carries the full burden, and it does add real context beyond the schema: it names the upstream (native public Uniswap HTTP API), states that the caller's OpenAny gateway credentials are used, and warns that charges and authorization are gateway-determined. That is genuinely useful pre-call context. However it says nothing about what a "status" response contains, whether reads are free/idempotent, or any rate limits or error 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?

Sized appropriately at three short sentences with the purpose front-loaded. The two trailing sentences about the Uniswap contract and gateway billing are slightly boilerplate, but they are the only source of auth/cost context given the absence of annotations, so they earn their 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 status-lookup tool with four parameters, no annotations and no output schema, the description is too thin: it never describes what a swap status response includes (status field, block, confirmation state), which is exactly the information an agent needs to decide whether to act on the result. It also omits any link back to the swap-creating tool that would produce the tx/UserOp hashes being queried.

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 the chainId enum, the txHashes/userOpHashes parameters and the "at least one of" constraint. The description adds nothing about parameters. Baseline 3 applies since the schema does the work, though the schema's own param texts ("Native chainId parameter.", "x-agent-info") are near-tautological, which caps the benefit.

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?

"Get swap status" states a specific verb plus resource and, combined with the tool name, makes clear this is a read of swap status rather than a swap execution (uniswap_post_v1_swap). It does not explicitly name any sibling, so an agent must infer that this is the post-submission status check rather than an order/token listing like uniswap_get_v1_orders.

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 no when-to-use guidance: it never says this should be called after uniswap_post_v1_swap to poll for settlement, never mentions polling cadence or terminal states, and never points to alternatives such as uniswap_get_v1_orders. Usage must be inferred entirely from the name and the schema's hash parameters.

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