supply

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

With no annotations provided, the description is the sole source of behavioral disclosure. It states the trust boundary (10% limit), the earning mechanism (supply APY), and the testnet-only environment. It does not mention any prerequisites, failure modes, or reversibility, but it covers essential safety and operational constraints that go beyond a simple 'deposit' statement.

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 two short sentences with zero fluff. It front-loads the primary purpose, then immediately provides the APY benefit and key constraints. Every word adds information, and the structure is efficient for an agent to parse quickly.

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 mutative tool with no output schema and no annotations, the description carries the necessary context: what it does, the benefit, a safety limit, and the environment. It doesn't explain the result format or potential risks, but these are somewhat implied and may be covered by the tool's runtime behavior. The description is sufficient for an agent to decide when to use it and how to constrain the 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 coverage is 100%, so parameters are well-documented. The description adds value by imposing a behavioral constraint on the amount ('max 10% of wallet balance'), which is not present in the schema. It also clarifies the concept of 'supply' but does not duplicate schema details. This enriches the meaning of the amount parameter beyond its type definition.

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 verb (supply/deposit), the resource (asset into Kaskad Protocol lending pool), and the intended effect (earn supply APY). It distinguishes itself from siblings like borrow, withdraw, and repay by specifying the action and its benefit. No ambiguity about what the tool does.

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 implicitly communicates when to use this tool (when the user wants to deposit assets to earn interest) and includes a concrete safety constraint ('max 10% of wallet balance per asset per action') and an environment restriction ('Testnet only'). While it does not explicitly list alternatives or say 'use this instead of X', the action is clear and the constraints provide practical guidance.

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