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

With only readOnlyHint=true declared, the description carries most of the burden and does so well: it discloses that badges are auto-resolved from the account, that poolProfile and badge fields are minted in the same transaction, that the pool unit cannot be named at creation, that emptyReserves leaves other holders with nothing to redeem, and that freezing is irreversible and must be confirmed with the user. It also states the return contract ("Returns the manifest for the user to sign").

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?

Purpose is front-loaded and every clause carries real information, but the single dense paragraph packs seven operations into one run-on sentence, making per-operation lookup harder than a short bulleted list would be. Nothing is wasted; the structure could be tighter.

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 19-parameter, seven-operation manifest builder with no output schema, the description covers the transaction grouping, badge requirements, irreversibility hazards and the returned artifact — everything an agent needs to pick an operation and avoid a destructive mistake. Remaining gaps (network, locale) are fully documented in the schema.

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 coverage is 100%, so the baseline is 3; the description earns above that by mapping parameters to operations ("poolProfile and the badge fields are written in the same transaction", "kind" implied for create, managerBadge vs. fresh mint) and by explaining conditional applicability the flat schema cannot express. It does not, however, describe the shape of the amounts map beyond what the schema already says.

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+resource ("Builds one native pool transaction") and then enumerates all seven operations with their distinct semantics, which lets an agent distinguish this from build_dex_manifest, build_locker_manifest and other manifest builders in the sibling list. The scope (native pool only, one transaction, returns a signable manifest) is unambiguous.

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?

Per-operation guidance is unusually strong: each of create/contribute/deposit/withdraw/redeem/profile/manage is tagged with its precondition ("needs the manager badge", "public", "needs the owner badge"). It does not, however, say when to prefer this over the sibling manifest builders or mention what to do if the user has no pool yet, so it stops short of explicit alternatives.

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