gage

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

Annotations already establish the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description does add return-content context not covered by annotations (per-loan limits, leverage flag, a lend-asset column appearing conditionally 'once there is more than USDG'), but with no output schema this remains cryptic and jargon-heavy rather than clear behavioral disclosure.

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?

It is a single compact sentence with the core purpose front-loaded, which is good, but the trailing clause structure ('a row names the lend asset it is borrowed in, once there is more than USDG') is convoluted and hard to parse on first read.

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 read-only listing with no output schema, the description carries the full burden of explaining what comes back. It gestures at the return shape but leaves the conditional field and the meaning of 'USDG'/'leverage buys them' underspecified, so an agent has only a partial picture.

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 takes zero parameters and schema coverage is 100%, so there is nothing for the description to compensate for. Baseline of 4 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 names a concrete resource (tokens accepted as collateral) and the specific attributes returned (per-loan limits, leverage eligibility), so the agent knows what it is fetching. It does not explicitly differentiate itself from siblings like gage_borrow_quote or gage_portfolio, and the phrasing 'gage takes as collateral now' is a bit obscure, but the purpose is inferable.

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?

No explicit when-to-use or when-not-to-use guidance is given, and no sibling (e.g. gage_borrow_quote, gage_leverage_quote) is named as an alternative. Usage is only implied by the fact that it is a zero-parameter reference listing of collateral assets, which an agent would call when it needs collateral metadata.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the quote reflects what the vaults 'fund now' and that it returns a prepare object, which is useful, but it omits staleness/rate-limit behavior and what the quote payload contains.

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?

Everything is packed into a single front-loaded sentence with no filler, and the scope constraint ('at most maxCollateral') comes early. The grammar is dense and slightly hard to parse, which costs a point but not readability of intent.

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?

With no output schema, the description should explain the return value; it only gestures at 'a prepare object for gage_prepare_borrow.' It covers the input bounds and downstream handoff but leaves the quote payload, term semantics, and wallet's role to 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 60%: term, lendAsset, and maxCollateral are documented in the schema, and the description reinforces token, maxCollateral, and the USDG/lend-asset default. But term and wallet are not elaborated anywhere beyond the schema, and the description adds little syntax or format detail beyond what is already structured.

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 resource (the largest loan the partner vaults will fund) and the inputs that bound it (maxCollateral, token, lend asset), and it names the downstream consumer gage_prepare_borrow. It does not, however, distinguish itself from the sibling gage_leverage_quote, so an agent must infer which quote tool applies.

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?

Usage is only implied through the phrase 'with a prepare object for gage_prepare_borrow,' which hints at the quote-then-prepare workflow. There is no explicit when-to-use or when-not-to-use guidance versus gage_leverage_quote or gage_capabilities.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety and idempotence need no restating. The description adds that the payload is configuration-like (contracts, terms, fees), but says nothing about freshness, caching, or whether the returned terms are authoritative for quoting.

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 fragments with no filler, and the imperative 'Start here' is placed last as the call-to-action. The comma-separated field list is slightly jumbled ('the rules' interleaved with concrete items), costing a bit of scannability, but nothing is wasteful.

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?

With no input schema fields and no output schema, the description is the only specification of what comes back, and its field list is only semi-explicit ('the rules'). For a bootstrap tool whose entire value is its return payload, the agent would benefit from knowing the shape or key sections of the response.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless full-snapshot read rather than a filtered query.

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 enumerates the resources surfaced (chain, contracts, loan terms, fees, rules, non-USDG lend assets), which is specific enough to distinguish this discovery tool from action-oriented siblings like gage_prepare_borrow or gage_loan. It lacks an explicit verb ('returns'/'describes') and the phrase 'the rules' is vague, so the purpose must be partly inferred.

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?

'Start here' is a direct sequencing instruction that tells the agent to call this before the other gage_* tools, which is exactly the guidance needed for a capabilities/bootstrap endpoint. It stops short of naming which sibling to call next or when to skip this tool (e.g., once cached).

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds the set of values available ('tokens, fees, size, free cash and share value'), which is useful but does not go beyond what appears to be the return payload.

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?

It is a single terse sentence with no wasted words, and the resource is front-loaded. The fragmentary phrasing slightly undercuts clarity, but the economy is appropriate.

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?

With no output schema, the description carries the burden of explaining return values, and it only sketches them loosely ('tokens, fees, size, free cash and share value') without structure or units. For a zero-parameter read tool this is adequate but thin.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. The description does not need to compensate for any schema gaps.

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 the resource ('partner vaults that lend') and enumerates the returned fields, but it is a bare noun phrase with no verb, so the action (list/retrieve) is only implied. It does not explicitly differentiate itself from siblings like gage_assets or gage_portfolio, leaving the agent to infer the distinction.

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 statement of when to call this tool versus alternatives such as gage_assets, gage_portfolio, or gage_prepare_earn_deposit. The word 'lend' offers a faint contextual hint, but no explicit usage condition or exclusion is provided.

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?

Annotations already convey readOnly, idempotent, and non-destructive behavior; the description reinforces this with 'Signs nothing,' which usefully confirms no transaction is committed. It does say the preview yields amounts and cost, but adds nothing about auth requirements, rate limits, or failure modes, so it clears the lower bar without being 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?

A single front-loaded sentence with no padding; the verb 'Preview' leads. The clause 'the most the purchase costs' is slightly awkward and vague, but overall the entry is tight and earns its space.

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?

With no output schema and a non-trivial six-parameter operation, the description is on the thin side: it names the previewed outputs loosely ('amounts, cost, the most the purchase costs') but omits the required term source and the relationship to the prepare step. Adequate but leaves real gaps an agent would want filled.

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 67%, so most parameters are documented structurally. The description references 'pledge' (own) and 'multiple', but adds no syntax, ranges, or units beyond what the schema provides, and never addresses term, wallet, lendAsset, or token. Baseline 3 is appropriate given the schema does most of the work.

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 gives a specific verb and resource — 'Preview a leveraged loop' with a pledge and multiple — and the phrase 'Signs nothing' implicitly separates it from the prepare/execute siblings. It stops short of naming gage_prepare_leverage as the alternative, so the distinction is inferred rather than stated.

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?

No explicit when-to-use, when-not-to-use, or named alternatives appear. 'Signs nothing' hints this is a pre-flight preview, but the agent must infer that gage_prepare_leverage is the follow-up step and there is no guidance on prerequisites, prerequisites order, or when a quote is even valid.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful content about what the response contains (state, amounts, deadlines, available actions), but says nothing about authentication, engine defaults, or failure modes. Adds moderate value beyond annotations.

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 short sentence with no filler, and the key noun (the loan) is front-loaded. However, the brevity crosses into under-specification, which hurts other dimensions rather than conciseness itself.

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?

With no output schema, the description does carry some of the return-value burden by listing state, amounts, deadlines and permitted actions, which is appropriate. But it omits the meaning of the required loanId, the engine default behavior, and how it relates to the prepare_* workflow, leaving real gaps for a two-parameter read tool.

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 only 50%: the optional 'engine' parameter is documented in the schema, but the required 'loanId' has no description anywhere, and the tool description mentions neither parameter. With a required, undocumented identifier, the description fails to compensate for the coverage gap.

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 enumerates what the tool exposes about a single loan (state, amounts, deadlines, permitted actions), which implies a read/getter, but it is a noun-phrase fragment with no verb and never explicitly says it retrieves or returns anything. An agent can infer the purpose, but only by reading the enumeration. Sibling differentiation is implicit at best — the prepare_* tools are never referenced.

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 statement of when this tool should be used, no prerequisites, and no mention of any alternative despite thirteen siblings including gage_prepare_borrow and gage_portfolio. The agent must guess whether this is the read step before a prepare_* call or something else.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered and the description does not contradict it. What the description adds is scope: that a single call aggregates loans, Earn holdings and credits rather than one category. It says nothing about refresh/latency or whether the result is a point-in-time snapshot, which is the kind of detail that would justify a 4.

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 short sentence with no padding, which is structurally efficient. However, the trailing parenthetical is cryptic to the point of being unparsable, so the brevity comes partly from under-specification rather than disciplined concision.

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 tool with no output schema, the description does at least name the three portfolio components, giving a rough sense of the return shape. It stops short of explaining how those components are structured or what the credit values mean, which is the main remaining gap for a caller consuming the result.

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?

With one parameter at 100% schema coverage, the schema already documents the wallet field, so the baseline is 3. The description does add a small clarification: it frames the wallet as the subject of the query ("A wallet's loans"), whereas the schema text says "The wallet that will sign", which is ambiguous for a read-only call. That is marginal added value, not substantial semantics.

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?

It identifies the resource — a wallet's loans, Earn holdings and credits — so an agent knows this is a portfolio read rather than a loan- or vault-level call. But there is no verb, and the parenthetical "USDG, and each lend asset's apart" is garbled enough that the returned credit composition is unclear. Siblings like gage_loan and gage_earn_vaults are never referenced, so differentiation is left to inference.

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 and never contrasts itself with gage_loan (single loan) or gage_earn_vaults (Earn positions), which are the obvious alternatives for overlapping data. An agent must guess whether a portfolio call or the narrower sibling is appropriate.

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?

Annotations already declare readOnlyHint=false, non-idempotent, open-world, and non-destructive, so the safety profile of a state-changing prepare call is partly covered. The description adds meaningfully beyond that: it returns the next unsigned transaction plus a review link and 'never signs', which is exactly the context an agent needs before treating the result as actionable.

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 core action and ending on the non-signing guarantee. The first sentence is dense and run-on, packing pledge, asset, and repayment terms into one clause set, but nothing is wasted and the critical constraint is not buried.

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?

No output schema exists, yet the description states the return shape (unsigned transaction plus review link) and the non-signing guarantee, which is the key completeness item for a prepare tool. Combined with annotations covering the write/non-idempotent profile and near-complete parameter documentation, the definition is close to self-sufficient, with the undocumented token/wallet params the only real 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 71%, and the schema itself documents cap, term, principal, collateral, and lendAsset. The description adds the lendAsset default (USDG when omitted) and the pledge/repay semantics in prose, but leaves 'token' and 'wallet' entirely unexplained and adds no unit or boundary detail beyond what the schema carries, so it only partially compensates for the coverage gap.

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 and resource ('Prepare a loan') and immediately spells out the full economic shape: pledge a token, receive USDG or the lendAsset, repay a fixed amount within the term. It also separates itself from the sibling gage_borrow_quote by specifying that this uses the quote's prepare object without its action, so an agent can tell the two apart without opening either schema.

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 'Use the prepare object of gage_borrow_quote, without its action' tells the agent where the inputs come from and implicitly that a quote precedes this call, which is genuine routing guidance. There is no explicit statement of when NOT to use it (e.g., before obtaining a quote, or when the user only wants pricing), so it stops short of full when/when-not coverage.

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?

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=true, but the description adds genuinely new behavioral context: it returns an unsigned transaction plus a review link and never signs. This clarifies the prepare/execute boundary that the annotations don't express.

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 tight sentences with the action and precondition front-loaded, and the key behavioral guarantee (never signs) placed last for emphasis. No wasted words.

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 3-param mutation-prep tool with annotations but no output schema, the description covers the effect and return shape adequately. It falls short on param meaning (undocumented wallet/loanId) and does not address auth or the relationship of 'wallet' to the caller.

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 only 33%: engine is described, but loanId and wallet carry no descriptions or enums. The description adds nothing about any parameter's meaning, format, or role, so it fails to compensate for the coverage gap.

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 (Prepare cancelling) and resource (a loan) with a precise precondition: 'still waiting for funding', plus the side effect of taking collateral back. It distinguishes itself from execution-type siblings via 'returns the next unsigned transaction', though it doesn't explicitly name an alternative tool.

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 'still waiting for funding' clause implies when this applies, giving an implicit precondition. However, it names no alternative tool (e.g. the borrow-collect/sign counterpart) and states no exclusions, so routing is left partly to inference.

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?

Goes beyond the annotations by stating the return contract (next unsigned transaction plus a review link) and that the tool 'never signs', which tells the agent a signing step is still required downstream. It does not state prerequisites, gas implications, or whether the collection is atomic across the listed asset types.

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 dense sentence for the purpose followed by a short clause on the return contract. No filler, and the what-gets-collected list 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?

With no output schema, the description correctly carries the return-value burden by naming the unsigned transaction and review link. For a non-idempotent, open-world mutation it could still say more about prerequisites or partial-failure behavior.

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?

Only one parameter and schema description coverage is 100%, with the schema already explaining that 'wallet' is the signing wallet. The description adds nothing about the parameter, 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?

States a specific verb (prepare) plus the resource (a collect operation) and enumerates exactly what is swept up: USDG and lend assets from loans, collateral back, vault earnings and sGAGE rewards. It does not, however, distinguish itself from the sibling gage_prepare_reclaim, which plausibly overlaps with 'collateral back'.

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 phrase 'everything ready' implies the trigger condition (use this when positions are collectible), but there is no explicit when-to-use guidance and no alternative tool is named. The overlap with gage_prepare_reclaim is left entirely unresolved.

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?

Annotations already declare a non-destructive, non-idempotent, open-world write, and the description adds meaningful context beyond them: the tool only prepares, returns an unsigned transaction plus a review link, and never signs. It stops short of saying whether repeated calls produce distinct transactions or how long the prepared transaction stays valid.

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 tight sentence, front-loaded with the action and scope, with the key behavioral caveat ('never signs') placed last. No filler words.

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?

With no output schema, the description usefully describes the return payload (unsigned transaction + review link), which is the most important missing piece. Remaining gaps are the undocumented wallet/vault parameters and the absence of timing or idempotency detail.

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 only 50%, and the description adds real meaning for amount by tying the raw units to the vault's asset (USDG: 6 decimals), reinforcing the schema. However, the wallet and vault parameters receive no semantic guidance beyond their hex patterns, so the description does not fully compensate for the coverage gap.

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 and resource ('Prepare a deposit into a partner vault (lending)') and constrains the asset to USDG or the vault's lend asset. The deposit-vs-redeem/borrow distinction is clear from this text plus the name, though no sibling is named 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 'Returns the next unsigned transaction and a review link' clause implies this is a pre-execution build step, but it never states when to call it versus gage_prepare_earn_redeem or gage_loan, nor any prerequisites (allowances, wallet funding). Usage is inferable but not spelled out.

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?

Annotations declare non-readOnly, non-destructive, non-idempotent, openWorld, but the description adds high-value context they don't carry: it returns an unsigned transaction plus a review link and 'never signs', which is the key safety property of a prepare tool. It does not state required approvals or rate limits, so not a 5.

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 clauses, front-loaded with the purpose followed by the return/behavior note. No wasted filler; slightly dense phrasing but every part 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?

No output schema exists, so the description usefully explains the return (unsigned transaction and review link). Combined with sibling naming and annotations, an agent has enough to call it, though approval/prerequisite context 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 50% - shares and maxSlippageBps are documented in the schema, while vault/wallet are not. The description reinforces the shares-omission default ('everything it can pay when shares is omitted') but adds little beyond the schema and says nothing about vault/wallet or slippage.

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 ('Prepare withdrawing from a partner vault') and distinguishes itself from the deposit/reclaim siblings by naming the vault-withdrawal action. An agent can identify it as the earn-side redemption flow without opening the schema.

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 'Prepare' naming and 'never signs' imply this is the pre-signing step of a multi-step flow, so usage is inferable. However, there is no explicit when-to-use or when-not-to-use guidance and no sibling is named as an alternative.

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?

Annotations already flag a non-idempotent write to an open world, and the description adds genuinely new behavioral context: it returns an unsigned transaction plus a review link and 'never signs,' and it discloses the maxCostBps refusal condition. Non-reversibility is not stated, but the signing/return behavior is the key disclosure an agent needs.

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 tight sentences, no filler, with the core action and the strongest constraint (USDG only) front-loaded. Every clause carries 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 7-parameter (6 required) mutation tool with no output schema, the description covers cost bounds, the single supported lend asset, and the return shape and signing behavior. Wallet/token selection and term sourcing are left to the schema, which handles them adequately.

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 71%, above the midpoint, so the parameter burden mostly rests on the schema. The description's 'USDG only' and maxCostBps refusal language largely restates the schema's own lendAsset and maxCostBps descriptions, adding only marginal meaning over structured data.

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 (prepare) and resource (leveraged loop) and explains the mechanism: 'the loan buys more of the pledged token in one transaction.' This separates it conceptually from gage_prepare_borrow, but it never names the sibling it is distinguished from, so an agent must still infer the boundary.

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?

Gives real constraints ('USDG only', 'Refused above maxCostBps') that govern invocation, but does not say when to reach for this versus gage_leverage_quote or gage_prepare_borrow. Usage is implied by the loop description rather than stated.

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 annotations already declaring a non-read-only, non-idempotent, non-destructive profile, the description adds real value by stating it returns the next unsigned transaction and a review link and 'never signs' — telling the agent the actual effect is a prepared payload rather than an executed repayment.

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 tight sentences, front-loaded with the action and scope, followed by the return/signing behavior. 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?

No output schema exists, but the description covers the return value (unsigned transaction plus review link). It leaves gaps on parameter semantics and prerequisites, and does not clarify how 'in full' interacts with the engine/loan-asset distinction hinted at 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 only 33% (only 'engine' is described), so loanId and wallet are undocumented. The description explains the loan/collateral concept but gives no parameter-level meaning, format, or note on when engine defaults to the current core.

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 and resource: prepare full repayment of a running loan, in the payment asset, reclaiming collateral before term end. This is clearly distinguishable from siblings like gage_prepare_borrow or gage_prepare_cancel, though it never names an alternative 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 phrase 'before its term ends' and 'in full' imply the timing and scope of use, but there is no explicit when-to-use/when-not guidance and no routing to sibling prepare_* tools for related operations.

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