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

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It discloses the collateral prerequisite, variable-rate default, a quantitative trust boundary ('max 10% of available borrows per action'), and the testnet-only environment. This goes well beyond the schema and does not contradict any annotation.

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 five short statements, each adding a distinct fact: purpose, collateral requirement, rate default, trust cap, and environment restriction. It is front-loaded, dense, and contains no filler or redundant wording.

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 three-parameter action with a fully documented schema, the description adds the critical non-schema context: collateral, variable-rate default, per-action trust cap, and testnet-only availability. It does not describe return values or debt accrual, but those are not essential for correct selection and invocation of this simple action.

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 input schema already covers all three parameters with 100% detail, including asset symbols, token-unit semantics, and interestRateMode codes. The tool description only restates the variable-rate default already present in the schema, so it adds no meaningful parameter information beyond the baseline.

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 first sentence states the exact verb and resource: 'Borrow an asset from the Kaskad Protocol lending pool.' This makes the tool's function immediately clear and distinguishes it from sibling tools like supply, repay, and withdraw without requiring schema inspection.

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 clear context for when to use the tool: borrowing requires sufficient collateral, is limited to testnet, and carries a 10% trust cap per action. It does not explicitly name alternatives or when-not-to-use scenarios, but the verb and sibling set make the selection context unambiguous.

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

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

With no annotations, the description carries the behavioral burden. It discloses the boolean alert result, the threshold comparison, and defines alert tiers (safe/warning/danger/critical) with numeric cutoffs. It does not specify the full response shape or error behavior, but the key monitoring semantics are present.

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 definition opens with the core purpose, then return semantics, usage loop, and alert tiers. It is compact and front-loaded, with each sentence adding distinct value; the only minor redundancy is 'warning (below threshold)' after the earlier alert:true statement.

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 simple read-style monitoring tool with full schema coverage, the description covers purpose, usage loop, threshold behavior, and alert levels. It lacks a formal output schema, but none exists, and the described behavior is sufficient for an agent to invoke and react to it.

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%; both address and threshold already have descriptions, including default and range. The description adds no new parameter-level detail beyond referencing the threshold, so baseline 3 is appropriate.

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 ('Check'), a specific resource ('a wallet's health factor'), and the comparison ('against a threshold'). It also names the alerting behavior, which separates it from read tools like getPosition or getMarkets.

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?

Explicitly prescribes a monitoring loop: call on a cron interval and trigger repay() or supply() when alert:true. This is clear usage context. It doesn't explicitly name exclusions or alternatives, but the intended use case is unambiguous.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well: it states that the tool checks the claimable balance first and skips the transaction if nothing to claim, which is a non-obvious behavioral trait. It also explains the reward-earning mechanism (epoch uptime and minimum position thresholds). However, it doesn't disclose whether the claim is a state-changing transaction (it is, by implication), whether it requires any authentication, or what the return value looks like. Still, for a zero-parameter tool, this is solid.

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 sentences, each earning its place: the first states the action and target, the second discloses the conditional skip behavior, the third explains how rewards are earned. No fluff, no repetition of the name, and the most important behavioral detail (skip if nothing to claim) is front-loaded in the second sentence.

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 zero-parameter, no-output-schema tool, the description is nearly complete. It explains what the tool does, the precondition, and the reward mechanism. The only missing context is what happens after a successful claim (e.g., where the rewards go, whether there's a transaction hash returned) and whether there are any risks (e.g., gas costs). But given the tool's simplicity and the absence of annotations, this is a strong showing.

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 tool has zero parameters, so the schema is trivially complete (100% coverage). The description adds context about what the tool operates on (the MCP wallet's accrued rewards) and the condition for action (claimable balance > 0). Since there are no parameters to document, the description's job is to explain the tool's behavior, which it does. Baseline 4 for zero params is appropriate.

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 action (claim), the resource (accrued KSKD rewards for the MCP wallet), and the mechanism (RewardsController). It also explains the precondition (checks claimable balance first) and the reward-earning context, which distinguishes it from sibling tools like getUserRewards (which likely only queries rewards) and stakeKSKD/unstakeKSKD (staking operations).

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 implies when to use this tool: when there are accrued KSKD rewards to claim. It explicitly states that it skips the transaction if nothing to claim, which is a clear behavioral guideline. However, it doesn't explicitly name alternatives like getUserRewards for checking rewards first, nor does it state when not to use it (e.g., if the user wants to check rewards without claiming). This is a minor gap.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly implies a read-only operation and lists what is returned, but does not mention error conditions, data freshness, or whether any state is accessed asynchronously. This is adequate but not rich.

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?

Two sentences, front-loaded with the tool's purpose and output, followed by a practical use case. No filler or repetition.

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 zero-parameter getter with no output schema, the description enumerates all major return components and explains the intended interpretation. Nothing essential for calling this tool is missing.

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?

There are no parameters, so the baseline is 4. The description adds meaningful context about what the returned state represents, even though there is nothing to document about parameter usage.

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 uses a specific verb ('Returns') and resource ('KSKD emission state') and enumerates the exact data fields returned. This clearly distinguishes it from sibling getters like getStakingInfo and getMarkets.

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 explicitly states when to use it: 'Use this to understand current emission APY context and vault depletion trajectory.' It provides clear context but does not mention alternatives or when not to use it.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive 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?

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?

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?

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?

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?

It provides a strong usage rule, so it is more than minimal guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses that the tool is read-only by saying 'Returns' and even names the subgraph data source, but it does not describe ordering, freshness, pagination, or any response-shape behavior. This is adequate for a simple query but not rich.

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 sentences, front-loads the main return categories, and avoids redundant phrasing. The only minor issue is a slightly long enumeration, but every clause contributes useful information.

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 no output schema and no annotations, the description gives a reasonable overview of return categories but does not define the response structure, ordering, or how 'active positions over time' relates to the user history. It is enough to select the tool but not fully enough to predict the exact result shape.

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 both parameters fully. The description only restates the address behavior ('Pass an address to get user-specific history') without adding new semantic details beyond the schema, so the baseline score of 3 applies.

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 uses a specific verb ('Returns') and identifies the resource ('historical data from the Kaskad Protocol subgraph') plus enumerates concrete contents: liquidations, APY snapshots, transaction history, and active positions. It clearly signals a read/history-oriented tool, though it does not explicitly differentiate itself from current-state siblings like getMarkets or getPosition.

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 implies usage context: use it when historical or user-specific data is needed, and it instructs to pass an address for user-specific history. However, it does not explicitly state when not to use it or mention alternatives such as getMarkets or getPosition for current data.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It conveys that this is a current-state query and lists the returned data, which implies a read-only operation. However, it does not explicitly state that no state is modified, nor does it mention rate limits, data freshness, or auth requirements.

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?

One sentence with no filler. It front-loads the resource and network, then compactly lists the relevant market metrics. Every phrase earns its 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 parameterless read tool, this is nearly sufficient: it names the network, the resource, and the key returned fields, and there is no output schema to compensate. It could add an explicit statement of the return shape (e.g., array keyed by asset) and a clearer read-only guarantee, but an agent can invoke it correctly without further details.

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 input schema is empty with zero parameters and 100% schema coverage, so there are no parameter semantics to document. The description appropriately focuses on the return payload instead, which satisfies the zero-parameter baseline.

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 identifies a specific verb ('Returns'), a specific resource ('all Kaskad Protocol lending markets'), and a specific environment ('Igra Galleon Testnet'). It also itemizes the return fields (APY, totals, utilization, liquidity), which clearly differentiates it from sibling tools like getProtocolInfo or getPosition.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention that other getters exist for user-specific positions or protocol parameters, nor does it state any exclusions or prerequisites. The only implied usage is that it serves as a market overview.

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

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

With no annotations, the description must carry the behavioral burden. It conveys a read-only operation via 'Returns' and details the returned data, but it does not explicitly state that no state is modified, what happens for an invalid address, or whether any authentication is needed. This is adequate for a simple getter but not fully transparent.

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?

A single, front-loaded sentence states the core action and then lists the specific return components. No filler or redundant restatement of the tool name is present.

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 one-parameter read-only getter with no output schema, the description covers the return essentials (collateral, debt, available borrows, health factor, per-asset breakdown). It lacks minor context such as error behavior or whether the address must already be registered, but nothing critical is missing for invoking it.

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% and the single 'address' parameter is already well documented as an Ethereum wallet address. The description adds only the protocol-specific context that the address is a wallet whose position is returned, which is marginal beyond the schema.

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 names a specific verb ('Returns'), a resource ('a wallet's current lending/borrowing position on Kaskad Protocol'), and enumerates the key output fields. It is clear but does not explicitly contrast itself with sibling getters such as getHistory or checkHealthFactor, so it stops short of full sibling differentiation.

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 implies when to call it (when a current position snapshot is needed) but provides no explicit when-to-use/when-not-to-use guidance and names no alternatives among the many sibling tools. There is no exclusion, such as 'for historical activity use getHistory'.

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

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

With no annotations provided, the description carries the full burden and does disclose the key behavioral trait — 'static — which tells the agent the data is stable reference material, not live state. It adds context about what the response contains, but says nothing about response format, payload size (the full AGENTS.md guide may be large), or failure 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?

A single front-loaded sentence opens with the core action and object, then uses a clean colon-delimited list to enumerate contents. Every component earns its place with no filler or redundancy. The structure makes the scope instantly scannable.

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 0-parameter, no-output-schema tool, the description thoroughly covers what the agent will receive, enumerating both high-level categories (network info, contract addresses, supported assets) and the nested integration guide contents (emission schedule, eligibility, gas requirements, strategy context). Minor gaps are the lack of return format or error-behavior disclosure, but nothing an agent critically needs to invoke a no-arg getter is missing.

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 tool has zero parameters and schema coverage is 100%, so the baseline of 4 applies and the description needs no parameter detail. The description is fully compatible with the empty schema and adds nothing that could confuse parameter handling.

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 uses a specific verb and resource: 'Returns static metadata about Kaskad Protocol,' followed by a precise enumeration of contents (network info, contract addresses, supported assets, documentation links, AGENTS.md guide). This content scope clearly distinguishes it from all 16 siblings, which target markets, positions, rewards, and governance data. An agent reading this could not confuse it with getMarkets or getPosition.

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 usage context is implied through the content list — the AGENTS.md integration guide, eligibility rules, gas requirements, and strategy context strongly suggest this is meant to be fetched before interacting with the protocol. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives, leaving the agent to infer the call order.

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

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

No annotations are provided, so the description carries the behavioral burden. The verb 'Get' plus 'state' strongly implies a non-mutating read operation, but the description does not explicitly confirm there are no side effects, permission requirements, or special failure cases.

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 entire description is one compact, front-loaded sentence with a colon-separated list of outputs. Every word adds information and there is no filler.

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 low-complexity, single-parameter read tool, the description is nearly complete: it names the resource, the scope, and the returned fields. Lacking only explicit non-mutation confirmation and units for holding duration, both minor for this simple case.

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 input schema already documents the sole address parameter to 100% coverage. The description adds no new meaning about the parameter beyond the schema, so the baseline 3 applies.

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 uses a specific verb-resource pair ('Get stKSKD vault state') and enumerates the exact data returned, so an agent can identify what this tool does. It does not explicitly contrast it with siblings like getPosition, but the phrase 'for a wallet' and the listed staking-specific fields are sufficiently distinguishing.

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 wording implies a read-only query for a wallet's staking status, which is a clear use case. However, it never states when to choose this over likely alternatives (e.g., getPosition or getUserRewards) or any exclusions.

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

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

With no annotations, the description carries the behavioral burden. It conveys a non-mutating read operation via 'Returns' and 'Shows', and adds eligibility context. It does not disclose behavior for ineligible addresses or empty reward states, but for a simple query tool this is a minor gap.

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?

Two short sentences deliver the core purpose and a key eligibility constraint with no filler. The most important information is front-loaded in the first sentence.

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 single-parameter read tool, the description explains what it returns, for whom, and under what conditions. There is no output schema, but the 'accrued and claimable amounts' phrasing sufficiently previews the result. Only minor edge-case behavior, such as the response for ineligible wallets, is missing.

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% and the only parameter, address, is already described accurately in the schema. The description adds no additional parameter detail, so the baseline score of 3 is appropriate.

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 identifies the operation ('Returns'), the resource ('KSKD rewards'), and the scope ('for a wallet address'). It distinguishes the tool as a read-only rewards lookup, unlike action-oriented siblings like claimRewards, though it doesn't name the sibling explicitly.

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 eligibility note ('meeting uptime and minimum position thresholds') gives useful context for when results are meaningful, and 'claimable' implies this could precede claimRewards. However, it doesn't explicitly state when to prefer this over getEmissions or claimRewards, so guidance is implied rather than direct.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states the action and the -1 full-repayment sentinel, but does not disclose side effects, prerequisites like an existing debt, whether repayment is partial or full beyond the sentinel, or what the transaction outcome/return is.

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 with no fluff. The action is front-loaded, the critical -1 behavior is included, and the testnet restriction is stated. Every sentence earns its 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?

The description plus schema is sufficient for a basic call: asset, amount, -1 behavior, and testnet-only. But with no annotations and no output schema, it lacks detail on return values, failure modes, or required preconditions for a state-changing DeFi operation.

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 input schema already documents asset, amount, and interestRateMode. The description repeats the -1 full-debt behavior but adds no new parameter meaning beyond the schema.

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 uses a specific verb and resource: 'Repay a borrowed asset on Kaskad Protocol.' It clearly distinguishes this from sibling tools like supply, borrow, and withdraw, and adds the useful environment qualifier 'Testnet only.'

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 intended use is clear: repay a borrowed asset. The 'Testnet only' note is an explicit environment restriction. However, it does not name alternatives or describe when not to use this tool beyond the testnet limitation.

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

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

With no annotations, the description carries the behavioral burden and does well by stating the state-changing effect on the connected wallet and the key protocol constraint about one active isolated asset. It does not mention gas transactions, reversion behavior, or that toggling collateral affects health factor/liquidation risk, but the core action and its main edge case are disclosed clearly.

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 sentences with no filler. The first sentence states the operation, the second gives the broader purpose, and the third provides an actionable protocol rule. Every sentence earns its place, and critical information is front-loaded.

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 2-parameter mutation tool with no annotations and no output schema, the description covers purpose, scope, principal constraint, and isolated-mode sequencing. It does not explain return values or prerequisite state (e.g., asset must be supplied), but the description is sufficient for an agent to invoke the tool correctly in the main intended scenarios.

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 both parameters are already fully documented by the schema. The description adds no new parameter-level detail beyond naming WiKAS/IKAS, which is already present in the asset property list. This is baseline acceptable.

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?

Description states a specific verb ('enable or disable'), a specific resource ('an asset as collateral'), and a scope ('for the connected wallet on Kaskad Protocol'). It is clearly distinct from sibling actions like supply, borrow, or withdraw because it targets collateral status rather than liquidity or debt.

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 says when the tool is required: switching between isolated (WiKAS/IKAS) and standard collateral modes. It also gives an actionable rule for Aave v3 isolation mode: disable other collaterals before enabling an isolated asset. It does not name alternative tools, but no sibling provides the same collateral-toggle function, so the guidance is sufficient.

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

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

No annotations are present, so the description carries the transparency burden. It discloses useful behavioral context: the 1:1 exchange rate, the governance effect, and the required wallet key. It does not describe return values or reversal behavior, but for a one-parameter staking action this is a moderate gap rather than a severe one.

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 compact and front-loaded: action and rate, then outcome, then prerequisite. Every sentence adds distinct information and there is no filler.

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 simple one-parameter tool with no output schema, the description covers the action, exchange rate, resulting eligibility, and the required authentication condition. It omits return-value or lockup details, but the sibling tools like unstakeKSKD and getStakingInfo partially mitigate that need.

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 input schema already fully documents the only parameter, amount, including human-units example and meaning. The description's 1:1 ratio adds context around the amount but does not introduce new parameter constraints or syntax, so the baseline schema-driven score is appropriate.

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 states a specific verb ('Stake'), a specific resource ('KSKD tokens into the stKSKD vault'), and a key rate detail (1:1). It also names the governance outcome, which clearly distinguishes it from sibling tools like unstakeKSKD or supply.

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?

It clearly implies when to use this tool: to gain governance eligibility through isEligibleSupplier/isEligibleBorrower. It also provides a prerequisite, MCP_WALLET_KEY, which helps an agent know whether it can call the tool, though it does not explicitly name alternatives or exclusions.

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

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.

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

With no annotations provided, the description carries the full burden. It adds meaningful behavioral warnings: the governance eligibility reset on zero balance and the MCP_WALLET_KEY requirement. It does not describe the return value or transaction outcome, but the core behavioral risks are disclosed.

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 deliver the action, the conversion ratio, a critical warning, and an authentication requirement with no filler. Every sentence earns its 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 single-parameter unstake operation, the description covers what the tool does, the conversion rate, an important edge-case warning, and a prerequisite. The only notable omission is the return format, but the tool is simple enough that this is not a serious gap.

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 schema already documents the shares parameter with an example. The description reinforces the 'shares' concept and the 1:1 ratio but adds little semantic detail beyond the schema. Baseline 3 is appropriate.

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 the exact operation ('Unstake stKSKD shares back to KSKD') with a clear verb, resource, and conversion ratio (1:1). It naturally differentiates from the sibling stakeKSKD by naming the reverse direction explicitly.

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 use case is clearly implied: call this when converting stKSKD back to KSKD. It does not explicitly name stakeKSKD as the alternative or state when not to use it, but the reverse-action wording makes the intended context unambiguous.

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

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

With no annotations, the description carries the behavioral burden. It provides useful context: the testnet-only constraint and the -1 withdraw-all sentinel. But it does not disclose potential side effects, such as health-factor impacts, collateral implications, or failure conditions when withdrawing supplied assets.

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?

Two compact sentences deliver the core action, the critical -1 edge case, and the testnet-only constraint. No filler, and the most decision-relevant information is front-loaded.

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 simple two-parameter write tool with full schema coverage and no output schema, the description plus schema cover the purpose, special value, and environment. It lacks only explicit guidance about side effects or sequencing with health-factor checks, but the low complexity keeps this from being a major gap.

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%, and both asset and amount are clearly documented there. The description repeats the -1 sentinel already present in the schema, so it adds no new parameter meaning beyond emphasizing an edge case.

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 states a precise verb ('Withdraw'), a specific resource ('supplied asset from the Kaskad Protocol lending pool'), and a special behavior (amount=-1 means withdraw all). This clearly differentiates it from siblings like supply, borrow, repay, and unstakeKSKD.

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 implies usage through 'Withdraw a supplied asset' and adds the important environment note 'Testnet only.' However, it does not explicitly contrast with alternatives such as repay or unstakeKSKD, nor state when not to use it, leaving some inference to the agent.

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