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

With no annotations supplied, the description carries the full burden and does disclose two useful behaviors: no signing/broadcasting happens here, and charges/authorization come from the OpenAny gateway using the caller's credentials. It does not state that this is a fund-affecting mutation, whether the returned payload is calldata or a plan object, or whether approval must be checked first (a check_approval sibling exists but is not referenced).

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 action before the operational caveats about signing and gateway billing. No filler, though the phrase "Builds or reads LP operation data" is slightly vague about which the caller gets back.

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 nested 12-field mutation with no annotations and no output schema, the definition covers the execution model and billing context but leaves the response shape, approval prerequisites, and protocol-conditional parameters unexplained. An agent can identify the tool but may still mis-populate the body on the first call.

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 reported at 100%, but the actual field descriptions are placeholders ("body", "x-agent-info"), so the schema names do the work. The description adds no meaning for key fields whose names are ambiguous: nftTokenId (required for V3/V4 positions), slippageTolerance, urgency, deadline, withdrawAsWeth, and simulateTransaction are all left for the agent to infer.

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 ("Decrease an LP position"), which clearly separates it from the sibling uniswap_post_lp_increase, uniswap_post_lp_create and uniswap_post_lp_claim_fees without needing the schema. It stops short of naming those siblings or stating the scope (which chains/protocols), so it is clear but not differentiating by name.

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 line "Builds or reads LP operation data; signing and on-chain broadcasting are separate" gives a real usage signal: this tool prepares the operation and does not submit it, so an agent knows it must follow with a signer/broadcaster. However, there is no guidance on when to prefer decrease over create/increase, nor on prerequisites such as an existing position, prior token approval, or the V3/V4 nftTokenId requirement.

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