Borro

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds that this is the complete directory of launches plus the field set each entry carries, but says nothing about size, ordering, or whether results are exhaustive in practice.

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 filler; the field list is compact and informative. Slightly dense with unexplained domain terms rather than verbose.

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 list the returned fields (short, stock, P/L, burns, fees), which is helpful. However, it leaves the shape of entries, the meaning of 'short', and the scope/currency of P/L unexplained, so an agent cannot fully predict what it will get back.

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 of 4 applies. The description correctly implies a no-argument, whole-directory read.

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 as a directory of every coin launched on Pons from Borro and enumerates the data it carries (short, stock, P/L, burns, fees). It is a clear resource but the verb is implicit ('directory') and the domain jargon (Pons, Borro, short) does not let an agent distinguish it confidently from siblings like markets, prices, or trades.

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 versus the many sibling listing tools (markets, prices, market, trades). The word 'every' hints at a full enumeration, but no exclusions, prerequisites, or alternatives are named.

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?

Beyond the annotations, the description discloses that the unsigned path produces typed data with no transaction and no gas, that the signed path submits to the Borro endpoint, that the typed data expires after 10 minutes, and that only the first binding per wallet stands. These details give an agent rich behavioral context and are consistent with the 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?

The description is front-loaded with the core effect and then cleanly splits the unsigned and signed flows. Despite covering several important constraints, every sentence and clause carries actionable information with no waste.

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 two-mode signature/submission tool with no output schema, the description supplies the essential context: what the tool does, how to obtain typed data, how to submit it, the expiration window, and the one-binding-per-wallet rule. An agent has enough information to invoke either path correctly.

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 explains all four parameters, including that signature is omitted to get typed data and timestamp pairs with a submitted signature. The description reinforces the mode dependency but adds little parameter meaning beyond what the schema already 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?

The description states a specific verb and resource: crediting a bookrunner's code with a wallet's borrowing on Borro, including the fee consequence. It is clearly distinct from the many sibling trading and credit tools, though it does not explicitly name alternatives or contrast itself with them.

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 explains the two modes: omit signature to receive EIP-712 typed data, or include signature and timestamp to submit the binding. The 10-minute validity and one-code-per-wallet rule are useful usage constraints, but it does not discuss alternatives among sibling tools.

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/idempotent/non-destructive, and the description explains WHY that is consistent: the output is an unsigned transaction the caller must sign and submit. It also discloses the prerequisite ordering and the meaning of rebate_estimate as a weekly locker rebate, both beyond structured fields. It does not describe the returned transaction payload itself.

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 operation and prerequisite front-loaded; no filler. The second sentence about rebate_estimate is informative but slightly cryptic since no quote parameter or quote step is defined here.

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 prepare tool with no output schema, the description covers the prerequisite, the unsigned-and-sign workflow, and one notable return field. What is missing is the shape of the returned transaction object and any confirmation step, which the absent output schema leaves to the description.

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 all three required params are documented there, so baseline 3 applies. The description adds no syntax or constraint detail for wallet/symbol/amount, and its reference to "the quote's rebate_estimate" introduces a concept with no corresponding parameter, leaving that reference unanchored.

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 ("Unsigned transaction to borrow USDG") plus the collateral condition ("stock already lent and posted"), which separates it from sibling supply/repay tools. An agent can tell this is a prepare-only borrow against posted collateral 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?

Gives an explicit prerequisite in "supply with post: true first", which tells the agent the ordering against the sibling supply tool. It stops short of naming the alternatives for the opposite actions (repay, withdraw) or stating when not to use it, so it is clear context rather than full when/when-not 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?

Beyond the annotations, the description explains that this prepares unsigned transactions, how the payout is triggered, how the move beyond strike times cover is capped by the pool, and the premium approval workflow. The readOnlyHint=true annotation is consistent with preparing unsigned transactions rather than executing them.

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 front-loaded and compact at two sentences, with no obvious filler. However, the first sentence is very dense with semicolon-separated payoff mechanics, making it harder to parse than it needs to be.

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 complex financial preparation tool with no output schema, the description covers timing, payoff direction, cap, premium approval, and that the output is unsigned transactions. It is largely sufficient, though it does not describe the returned transaction structure or any failure/edge cases.

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 defines every parameter including side, symbol, wallet, notional, and strike_bps. The description ties side and strike to the payoff formula, but it largely repeats schema-level meaning rather than adding new per-parameter details.

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 action and resource: 'Unsigned transactions to buy Monday-gap cover on a stock.' It also scopes the timing ('while the market is shut') and the payoff direction, which distinguishes it from siblings such as buy_option or open_short.

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 the tool: while the market is shut, until an hour before reopen, and for short versus long gap exposure. It does not explicitly name alternative tools or exclusions, so it falls short of full when/when-not 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?

Adds substantial detail beyond the readOnly/idempotent annotations: the output is unsigned and must be signed by the wallet, the premium is approved exactly, and the fill either takes the whole ask or leaves at least 0.001 of a share. It also enumerates what is returned (cost, Borro's share, break-even, payoff at expiry), resolving the apparent tension between readOnlyHint=true and a state-changing swap.

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 dense sentence, front-loaded with the verb and the primary routing decision (best ask vs. order_id), followed by the mechanics and return values. It is long but nearly every clause carries information; only the 'checked on chain' phrasing is slightly compressed 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 an 8-parameter, no-output-schema preparation tool it covers the essentials: what gets built, how the fill is bounded, and what the caller receives (cost, break-even, expiry payoff). It stops short of stating prerequisites (discovering a series via `options`, token approval state) or what happens if max_premium is exceeded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds semantic weight: order_id means buying a specific ask instead of the best one, and max_premium is framed as the ceiling the fill 'may take'. The partial-fill floor of 0.001 share also clarifies how `shares` behaves in practice.

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 concrete verb and resource ('Unsigned transactions to buy options') plus the exact source of the fill ('best ask of a series (or a given ask with order_id)'). The build-then-fillAsk mechanism makes it unambiguously distinct from write_option, post_bid, and claim_option even though siblings are not named.

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 order_id clause implies a choice between buying from the best ask and a specific ask, which is useful context. However, there is no explicit statement of when to use this versus siblings like write_option or post_bid, and no prerequisites such as needing the series first from `options` or holding the quote token.

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 state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the transaction is unsigned and must be signed by the wallet, and Route execution avoids a Borro contract and Borro fee.

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 a single sentence and front-loads the core action, but it is syntactically tangled with nested clauses. The trailing phrase 'for the flows that need them' is vague and does not earn 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 transaction-preparation tool with no output schema, the description communicates the key idea that it returns an unsigned transaction and explains the routing fallback. It does not describe the response shape or clarify what the vague final clause means, leaving some gaps.

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 all four parameters. The description does not add format or constraint details beyond what the schema provides, so the 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?

The description identifies a specific action and resource: an unsigned transaction swapping the wallet's ETH for USDG or a stock. It also distinguishes between Uniswap and Route execution paths, but the phrasing is tangled and does not clearly differentiate this tool from sibling buy/prepare 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 gives a condition for choosing Route over Uniswap ('when Route guarantees more'), which is useful. However, it provides no guidance on when to use this tool versus related siblings such as buy_cover, buy_option, or other preparation tools, leaving selection largely implied by the name.

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 readOnlyHint=true and destructiveHint=false, and the description explains why: the tool returns an unsigned transaction the wallet must sign rather than mutating state itself. It also discloses the economic effect (collateral or USDG returns to the maker) and the maker-only restriction, which annotations cannot express. Minor gap: no mention of failure modes such as expired or already-filled orders.

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 compact sentence with the core action front-loaded and the economic detail and permission rule packed into trailing clauses. Nothing is wasted and the ordering follows what an agent needs first.

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 two-parameter tool with no output schema, the description covers purpose, who may call it, timing, and the effect on funds. It does not describe the returned unsigned transaction's shape, but the 'unsigned transaction' framing plus the title ('Prepare: ...') makes the return contract inferable.

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 both parameters are already documented in the schema; baseline 3 applies. The description adds only an implied constraint that the wallet must be the maker, which is useful but thin compared to what the schema already 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?

States a specific verb+resource pair upfront: 'Unsigned transaction cancelling an ask or a bid.' An agent immediately knows this retracts a resting order rather than creating one, which separates it from siblings like post_bid or write_option.

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 concrete authorization and timing conditions: 'Only the maker may, until the series expires; then anyone may.' This tells the agent when the call will succeed or fail. It does not name alternative tools or handling for already-filled orders, so it stops short of full routing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond them: this returns an unsigned transaction for the wallet to sign (a prepare step, not an on-chain submission), and the funds originate from a settled or voided cover sitting in the pool's owed. That is the key behavioral fact 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?

It is a single sentence with the important fact ('Unsigned transaction') front-loaded, but the structure is awkward: a missing relative pronoun and a parenthetical make it harder to parse than necessary. It is not bloated, but it is not clean either.

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 prepare tool with no output schema, the description covers what it builds and why funds are owed, which is close to sufficient. It does not clarify what the caller must do after signing or whether claiming clears the owed balance, leaving a meaningful gap in the workflow.

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 single wallet parameter is fully documented there as the address the transactions are built for. The description adds no additional parameter semantics such as address format checks or signing requirements beyond what the schema already states, so 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 name, title, and phrase 'Unsigned transaction taking USDG' make the intent identifiable: prepare a claim for USDG owed from a settled or voided cover. But the description sentence is grammatically tangled ('USDG a settled or voided cover could not send') and never cleanly states the verb 'claim', forcing the agent to parse it. Sibling differentiation from settle_cover/withdraw_cover is only implicit.

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 implied by 'it waits in the pool's owed' and 'position shows owed_usdg', which tells the agent to call this when the position reports owed USDG. There is no explicit when-to-use/when-not-to-use statement or comparison with settle_cover or withdraw_cover, so the guidance remains inferential.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), and 'Unsigned transaction ... built for it to sign' is consistent with that: the tool prepares, not executes. The description adds genuinely useful context beyond the annotations: the default consumes all the wallet's tokens of the series unless shares is given, and the payout composition differs for calls vs puts, including an as_shares fallback rationale. It still omits failure behavior if the series is unsettled or the wallet holds nothing.

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 dense sentences that front-load the core operation and immediately follow with the payout breakdown, so the most important facts come first. It is jargon-heavy ('Borro vault shares', 'Steakhouse vault') but that specificity earns its space for this domain.

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 transaction-builder with four parameters, no output schema, and full schema coverage, this is nearly complete: it says what is burned, what is received, what the defaults are, and that the result is unsigned. Missing is any note on what happens when the series is not settled or the wallet holds none of the series.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description goes slightly beyond it by stating the shares default ('All the wallet holds unless shares is given') and by explaining the as_shares fallback condition rather than just restating what it does. wallet and series_id still rely on the schema for their meaning.

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 action and resource (claim a settled option series) and explains the payout mechanics: a call yields Borro vault shares, a put yields USDG or Steakhouse vault shares. It is clear enough to distinguish from siblings like settle_series or buy_option, but it never explicitly contrasts itself with those alternatives.

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 implied rather than stated: the series must be 'settled' and the wallet must hold tokens. The only explicit conditional guidance is parameter-level ('with as_shares, for when the vault is short of free USDG'). There is no statement of when to prefer this over settle_series or claim_cover, and no prerequisites or ordering advice.

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 readOnlyHint=true and destructiveHint=false; the description is consistent with that by saying it returns an unsigned transaction that the wallet signs. It adds real context beyond the annotations by explaining the settlement flow: stock sold, debt repaid, remainder returned in USDG.

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 that identifies the artifact (unsigned transaction), the action, and the outcome. No repeated or filler content.

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 preparation tool with full schema coverage and no output schema, the description covers what is produced and what happens mechanically. It stops short of stating prerequisites (an existing long position) or that the result must be signed and submitted afterward.

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 all three parameters are already documented, including percent's 1-100 range and default. The description's 'all or part' only echoes what the schema already says, so 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 and resource: prepares an unsigned transaction that closes a leveraged long on a stock. Naming 'leveraged long' implicitly distinguishes it from close_short and close_pair, but no sibling is called out 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 'closing all or part of the wallet's leveraged long' implies the precondition of an existing open long, but there is no explicit when-to-use guidance or routing to alternatives such as close_short or repay. Usage is inferable 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?

It discloses meaningful behavior beyond the annotations: the returned transactions are unsigned and built for the wallet to sign, a basket leg or an independent short on the same stock stays open and is surfaced in stays_open, and a partially closed short is handled with an explanatory note. This does not contradict readOnlyHint=true, since the tool only prepares transactions rather than executing a close. Missing only whether signing/approval steps or gas considerations follow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the opening clause, but the sentence is long and heavily parenthetical, forcing the reader through nested asides ('a basket leg or a short of its own on the same stock stays open, listed in stays_open') to recover the two effects. The content earns its place, but the packaging could be split into shorter statements.

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 names the key return fields (stays_open, the note) and explains the partial-close edge case, which is what an agent needs before invoking. Remaining gap: no mention of the failure mode when no open pair of these stocks exists.

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 parameter mechanics are already documented; the description nonetheless adds role semantics the schema lacks, making clear that 'long' is the side whose lent stock is recalled and 'short' is the side being closed. It does not, however, say what happens if the two tickers are not in an open pair together.

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 and resource: build unsigned transactions that close the wallet's newest open pair of two named stocks, and it clarifies which legs of the position are affected. It distinguishes itself from a simple position close by scoping to a pair ('newest open pair of these two stocks'), though it never names close_long/close_short/open_pair as the alternatives.

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 implied by the pair-scoped framing and by the 'newest open pair' rule, which tells the agent which pair is targeted when several exist. However, there is no explicit statement of when to choose this over close_long, close_short, or open_pair, and no stated prerequisites (e.g., that the wallet must hold an open pair of these two tickers).

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?

Adds substantial context beyond the annotations: the output is unsigned transactions the wallet must sign, a USDG top-up approval is required when the position is under water, and the result includes closes_parts enumerating what is closed. This reconciles readOnlyHint with what otherwise sounds like a buy-back/return sequence, so the agent understands no state changes until signing.

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?

Front-loaded with the core action in the first clause, then the scope clarification. Two sentences with no filler, though the second is dense with domain jargon ("pair or basket legs", "closes_parts") that takes a careful 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?

With only two required params, high schema coverage, and no output schema, the description covers what the tool returns (unsigned txs, closes_parts) and the one prerequisite that could surprise an agent (USDG top-up approval). Nothing critical is missing, though it doesn't mention signing/gas flow beyond "for it to sign".

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 both parameters are documented inline (ticker format, wallet address for signing). The description adds no further parameter syntax or format detail, 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 and resource: produce unsigned transactions that close the wallet's entire short on a stock. It explicitly scopes to the whole short ("closes all of it") and names how that differs from close_pair, so an agent can separate it from siblings without opening schemas.

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?

Clearly routes between this tool and close_pair ("close_pair closes only a pair's own part"), and explains the shared-short-per-stock model that makes the choice non-obvious. It does not cover other adjacent alternatives such as buy_cover or repay, 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?

Goes well beyond the annotations: it discloses authorization requirements (wallet must be the line's agent or owner and on the allowlist under credit_guardrails bills:true), that eligibility is checked and simulated, that at most one unsigned borrow of the shortfall is prepared, that max_usdg causes refusal, and exactly what is returned (EIP-3009 authorization, typed_data, and ordered next steps). readOnlyHint=true is consistent, since the tool only prepares an unsigned payload and returns instructions rather than mutating state.

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?

Correctly front-loads the verb and resource, but the body is a single dense block of clause-stacked jargon that is hard to parse on first read. Roughly every sentence carries information, so it is not padded, but readability suffers for its length.

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 complex, multi-step tool with no output schema, the description covers the important ground: input interpretation, preconditions and allowlist checks, failure mode (refusal), and the shape of the return plus the required follow-up sequence. Minor gaps remain, such as what the refusal or error payload looks like and how the borrow object is consumed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3; the description adds real meaning on top by explaining that payment_required accepts either the raw PAYMENT-REQUIRED header or the JSON body, what happens when max_usdg is exceeded, and that wallet and account are the payer and the credit line respectively. It stops short of describing token units or format details 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?

States a specific verb and resource: pay a merchant's x402 bill in USDG on Robinhood Chain using an agent credit line, and the title marks it as a prepare (not execute) step. It also positions itself against credit_bill_header, which it explicitly says to call afterwards. The heavy protocol jargon (x402, USDG, eip155:4663) makes it dense but not ambiguous.

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 clear entry conditions: you must have a 402 with a payment_required header or JSON body, and the bill must have an exact-scheme USDG option on eip155:4663 or it is 'refused in words'. It lays out the follow-up workflow (send the borrow, sign, call credit_bill_header, resend within valid_until), which clarifies when this tool is the right step. It does not name a mutually-exclusive alternative such as credit_pay, so no explicit 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?

The description adds substantial behavioral detail beyond the annotations: it reads no chain, sends nothing, validates the authorization against the bill's payTo and exact amount, checks the bill has not run out, and recovers a 65-byte signature to the payer. These details are consistent with the read-only, idempotent, non-destructive 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?

The description is compact and front-loads the prerequisite, then explains the result and validation behavior, and finishes with the exact next action. Every sentence earns its place with no redundant restatement of schema or annotations.

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 three required parameters and no output schema, the description provides everything needed: prerequisites, output format and header names, validation behavior, and the next request step. No critical information 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%, so the parameters are already well documented. The description adds useful semantic context by explaining that the authorization is checked against the bill's payTo and exact amount, and that the signature is recovered to its payer, though it does not further elaborate on the string/object flexibility of the parameters.

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 tool's output: the x402 payment header the merchant reads, with both header name variants (PAYMENT-SIGNATURE and X-PAYMENT) and base64 JSON format. It also distinguishes this from credit_bill by framing it as the subsequent step after credit_bill and the wallet's signature.

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 states the explicit precondition ('After credit_bill and the wallet's signature') and the exact follow-up action ('Send the same request again with header.name set to header.value'), leaving no ambiguity about when and how to use the tool.

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 readOnlyHint, idempotentHint, and destructiveHint=false, the description adds substantial behavioral context: permissions (anyone may create the station, agent or owner may borrow, allowlist requirement), conditional release on stale price feed, and that everything is simulated from the wallet. It could still be clearer about failure modes, but the added transparency is strong.

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 a dense, run-on paragraph with multiple clauses and semicolons that could be more clearly structured. It front-loads the purpose but is unnecessarily verbose and difficult 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?

Given the tool's complexity (multi-step conditional logic, no output schema), the description covers the required branches and permissions well enough for an agent to understand the process. It implies the return is unsigned transactions ('simulated from the wallet'), though a brief note on output format would improve completeness.

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 all three parameters. The description adds only marginal clarification: it reinforces that amount is optional and what happens without it, but does not introduce new syntactic or semantic details beyond the schema's own descriptions.

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 and resource: preparing unsigned transactions that turn a line's credit into ETH in the agent's wallet. It distinguishes itself from siblings like credit_borrow or credit_repay by focusing on gas-station creation and pumping. The dense phrasing makes it slightly harder to parse, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it through conditional branches (no amount vs. amount, stale price feed triggering release), but it never explicitly says when to choose this tool over alternatives like credit_borrow or borrow. The usage context is present but requires 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?

The description goes well beyond the annotations by disclosing that transactions are unsigned and built for the owner to sign, that settings start from current values, that checks mirror the line's own checks, that before/after are shown, and that accepting ownership temporarily clears the keeper. It also explains the old-agent allowlist changes and the gas-station daily-limit constraint.

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 opening sentence is front-loaded and purposeful, and most content is relevant to the many parameters. However, the definition is a very dense paragraph with long parenthetical enumerations, making it harder to scan than it should be for a 17-parameter tool.

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?

Given no output schema, the description is largely complete about transaction-building behavior, ownership acceptance, safety constraints, and expected account validation. The main gap is that it does not explicitly state the return shape, such as how transaction objects and the before/after view are returned.

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?

Although the schema has 100% description coverage, the description adds substantial semantic constraints not present in the schema: agent cannot be the owner's own wallet, keeper options, target/trigger LTV limits, sell_bps=0 when no pool, allow/deny behavior, bills implications, and accept ownership mechanics. These details materially improve correct parameter use.

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 title and opening sentence make clear that this prepares an unsigned configure() transaction for an agent credit line, starting from its current settings. It is specific about verb and resource, though it does not explicitly distinguish itself from sibling tools like credit_line, credit_gas, or credit_repay.

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 explains what can be configured but does not state when to use this tool instead of alternatives such as credit_line, credit_gas, credit_bill, or credit_open. Usage is only implied by the list of configurable fields, with no explicit when-to-use or when-not-to-use 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?

Annotations already cover read-only/idempotent/closed-world safety, but the description adds substantive behavior: five lines per owner call, newest first, page 2 for the next five, and 'live false until Borro's keeper publishes its count.' It also flags estimates and conditional gasOnTheHouse eligibility.

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 a single long run-on sentence with nested parentheses that enumerates dozens of return fields. While the field detail may be necessary without an output schema, the structure is hard to parse and not front-loaded beyond the opening clause.

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?

Because there is no output schema, the extensive field list is warranted and covers modes, pagination, holder benefits, conditional fields, and freshness. Some terms (health word, LTV target) remain undefined, but the agent has enough to invoke and interpret 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 the baseline is 3; the description reinforces the owner/page pagination ('five a call, newest first; page 2 for the next five') and account mode but adds little syntax 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 opening clause names the resource and the two access modes (account = one line, owner = list), so the agent knows it reads a credit line. It does not name a verb or explicitly contrast with sibling tools like credit_bill or credit_guardrails, which keeps it below a 5.

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 sentence says when to choose this over credit_bill, credit_guardrails, holder_benefits, or the other credit_* tools; the account/owner split is implied by the schema rather than framed as usage 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?

Annotations already declare this as a safe, read-only, idempotent operation. The description adds useful content-level context by naming edge cases like a proposed or in-force write-off, a pool with no data, and whether the price has started, but it does not clearly describe the response structure or how the different data groups are organized.

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 a dense, run-on enumeration mixing mechanism explanation, market fields, price-feed details, gas-station rules, and pre-market notes. The core purpose is buried rather than front-loaded, and the colon-separated lists make it hard to scan.

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 parameters and no output schema, the description carries the full burden of explaining what comes back. It does enumerate many returned data points and edge cases, but the presentation is opaque and does not clearly separate markets, prices, pool state, contracts, and gas stations into a coherent return model.

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?

This tool takes no parameters, so there are no parameter semantics to document. The baseline for zero parameters is 4, and nothing in the description needs to compensate for a schema 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 names a specific domain resource (markets for agent credit lines) and hints at returned fields, but never states a clear action like 'list' or 'returns'. The opening sentence explains the broader Agent Credit Lines mechanism before getting to the markets payload, leaving the tool's exact purpose somewhat ambiguous.

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 explicit guidance on when to use this tool versus siblings such as markets, credit_line, credit_guardrails, or credit_gas. The phrase 'Before the market is on chain' implies a temporal use case, but no conditions, alternatives, or exclusions are 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?

Goes well past the annotations: it discloses that output is unsigned transactions requiring an exact credit approval to the factory first, that refusals are computed locally by simulating from the wallet, and enumerates the specific rejection conditions (daily limit, ceiling, target, write-off, 90% used, depth gate, price timing). It also tells the agent to verify each transaction's `to:` against the factory, isAccount, or credit address.

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?

Every clause carries information, but it is delivered as one dense paragraph of comma-chained constraints with no line breaks or sub-headings between the open-line and existing-account modes. Substantively lean, structurally hard to scan, especially with 17 parameters.

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 17-parameter, two-mode, no-output-schema tool this covers modes, defaults, refusal conditions and downstream call targets. The remaining gap is the return shape itself — how many transactions come back and in what order beyond the factory approval — which the description only implies.

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%, yet the description still adds cross-parameter semantics the schema omits: daily_limit defaulting to the ceiling, or $100 capped at $5,000 when a gas station is present; trigger_ltv deriving from the target plus 7 points within 0.27–0.3 for CREDIT; sell_bps/slip_bps market-dependent defaults; and the owner-vs-agent interaction between `to`, `agent` and `allow`.

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?

Opens with 'Unsigned transactions' — the key distinction for a prepare-only tool — then states both modes concretely: opening a line owned by the signing wallet for an agent, or posting/borrowing on an existing account. An agent can tell this apart from borrow, credit_line and credit_guardrails without opening a 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?

Explicitly separates the two invocation modes ('Without account' vs 'With account'), names the prerequisite lookup (credit_markets for the symbol) and the linked flows (credit_bill, credit_gas, holder_benefits). No sibling tool is named as an alternative for inspecting an existing line, so it falls short of a 5.

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 mark this read-only and idempotent, and the description is consistent with that by framing it as an 'unsigned' transaction that is 'simulated from the wallet'. It adds real behavioral detail beyond the annotations: the allowlist, write-off, daily-limit, ceiling, LTV, 90% and depth gate checks that will gate the call. It stops short of saying what the prepared output looks like.

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 core action is front-loaded, but the text is a single dense run of unexplained protocol jargon ('write-off', 'the ceiling', 'the market's 90% and depth gate') that slows comprehension. Roughly the right length, but not structured for scanning.

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?

There is no output schema, so the agent relies on the description for the return value; it only hints at 'unsigned' transactions and 'transactions are built for it to sign' in the schema, without stating whether a submit/broadcast step follows. For a mutating-intent prepare tool with four required params, some call-sequence detail 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 each parameter already carries a description, so the schema does the heavy lifting. The description restates the payee constraint ('allowlist, or its owner') and the fact that the tx is built for the wallet to sign, but adds no format or edge-case detail 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 first clause states a concrete action and resource: an unsigned borrow drawn from a credit line and sent directly to a payee. This is clearly distinct from credit_repay, credit_bill, or plain borrow, though the agent has to parse dense jargon ('line', 'USDG goes from Morpho') to get there.

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 implied by the mechanics (use this to pay a payee from a line rather than repaying or opening one), and one prerequisite is stated: the `to` must be a factory-confirmed account (isAccount). There is no explicit when-to-use vs when-not or named alternative such as credit_repay or credit_bill.

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/idempotent/non-destructive, and the description reinforces that this only builds unsigned transactions ('Check each transaction's to:'). It adds genuinely extra behavior: exact USDG approval first, an interest buffer of a hundredth of a percent on 'all', repay taking only what is owed, owner-only gates, and sellAndRepay mechanics with its default minimums.

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 core purpose is front-loaded and nearly every clause carries operational detail rather than padding. Structure suffers from being one dense run-on paragraph with nested parentheticals, making the three modes harder to scan than a short mode-by-mode breakdown would be.

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 an eight-parameter, three-mode tool with no output schema, the description covers preconditions, permissions, defaults and failure-adjacent cases like write-offs. The only gap is that the returned structure (a list of unsigned transactions and their fields) is only implied by 'Unsigned transactions,' not spelled out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the prose adds meaning the schema lacks: what 'all' resolves to (debt plus an interest buffer), that the repay transfers only the owed amount, that unwind needs no USDG and sells into the line's own pool at a minimum of the whole debt, and that sell/min_usdg/then_close override those defaults.

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 leads with a specific verb and resource — it prepares unsigned transactions that repay a credit line's USDG debt — and names the three operational modes (plain repay, close, unwind). It never explicitly contrasts itself with close siblings like `repay` or `credit_pay`, so an agent must infer the distinction from the 'line's USDG debt' framing.

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 gives real selection criteria: 'anyone may' repay, close/unwind are 'the owner only', unwind requires 'a line whose market has a pool', and all modes work 'before CREDIT's price starts and during a write-off too.' It stops short of naming a sibling tool to use instead when these conditions fail.

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?

The description reconciles the readOnlyHint=true annotation by making explicit that these are unsigned transactions the wallet must sign, which prevents an agent from assuming it moves funds. It also discloses the approval-then-deposit sequencing and where yield accrues, though it does not say how many transactions are returned or whether the approval is included.

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, front-loaded with the core 'unsigned transactions to put USDG into the pool' framing. The trailing 'A big gap pays covers out of the pool' is atmospheric rather than operational and slightly dilutes the front-loading.

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 only two well-documented parameters and no output schema, the agent needs to know what it gets back and what to do next; the description covers both implicitly via 'Unsigned transactions' and the approve-then-deposit instruction. The exact shape of the returned transactions is left unstated.

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 both parameters are already documented, and the baseline is 3. The phrase 'Approve exactly the amount' adds a constraint (no infinite approval) tied to the amount parameter, but the wallet parameter gets no extra treatment 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?

States a specific verb and resource ('Unsigned transactions to put USDG into the gap cover pool') and explains the pool's role, so it is clearly not buy_cover or withdraw_cover. It never names a sibling tool to contrast with, so it stops short of full 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?

'Approve exactly the amount, then deposit' gives a usable call sequence, which is real guidance for invoking it. However, there is no statement of when to prefer this over buy_cover or withdraw_cover, or any precondition such as holding USDG or an existing position.

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/idempotent/non-destructive, and the description usefully reconciles that with the fact that it produces unsigned approval-plus-deposit transactions that are simulated from the wallet and never broadcast. It adds the two-step approval-then-deposit behavior and slippage acceptance, but says nothing about what happens when simulation fails or whether the caller must hold balance/allowance beforehand.

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 dense sentences with no filler, and the verb/resource is front-loaded. Readability suffers from stacked parentheticals such as '(the feed's price for the first deposit, which sets the farm's price)', which take effort to parse but do carry 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?

With five fully described parameters and no output schema, the description covers input combination logic, ratio derivation, approval ordering, and simulation. The main remaining gap is the shape of the return value — an agent is told it gets unsigned transactions but not how they are packaged or how failures surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: that usdg and stock are interchangeable via the farm ratio, that slip_bps governs how far the accepted share amount may drift under the quote, and that the first deposit's ratio comes from the feed price. It does not clarify units or defaults beyond what the schema already documents.

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 opening clause names a specific verb and resource — building unsigned transactions that put USDG and a stock into a farm — which cleanly separates it from farm_withdraw and farms. The 'unsigned transactions' framing also signals it is a prepare step rather than an executor, though the phrase 'its farm' leans on the symbol parameter to identify which farm, rather than saying so outright.

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 real usage rules: supply usdg, stock, or both, and the unspecified side is derived from the farm's ratio, with the first deposit priced off the feed. It does not state when to prefer this over siblings (e.g. farm_withdraw) or any preconditions such as needing an existing position, so context is clear but alternatives are not named.

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/idempotent/non-destructive, so safety is covered; the description goes further by disclosing the computation behind 'Your APR' (fees at last week's pace, lending fees and interest, $BORRO Drip at today's rate, lent part weighted 1.5x) and the wallet-scoping behavior. That is real context an agent could not get from annotations or schema.

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 resource is front-loaded in the first clause, but the remainder is a single dense ~100-word sentence that stacks every returned field into one run-on list. The content earns its place, yet the structure makes it hard to scan.

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?

There is no output schema, so the description carries the burden of explaining return values and does so thoroughly — size, swap vs lent split, swap/squeeze fees, lending fees and interest, day/week volume, farmer fees, and APR. It is complete for an agent to decide whether the response answers its question.

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 both parameters are documented there (symbol by ticker, optional wallet). The description reinforces this with 'like NVDA' and the note that 'farms lists the stocks that have one,' but adds little semantic depth beyond the schema descriptions, so the high-coverage baseline 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 opens by identifying the resource precisely (Uniswap v4 USDG/stock pools run by Borro's hook) and then enumerates exactly what data each farm record carries. It is clearly a read/listing tool for farm state, distinguishable from action siblings like farm_deposit or farm_withdraw, though the imperative verb ('list/get') is only implied by the noun-phrase framing.

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 explicit statement of when to use this tool versus siblings such as markets, market, or farm_deposit/farm_withdraw. The only conditional hint is 'With a wallet, its part of each farm,' which indicates a usage variant but not when this tool should be chosen over alternatives.

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?

The description adds real context beyond the annotations: it returns an unsigned transaction for the wallet to sign rather than executing the withdrawal, and it explains that lent-out funds come back as vault shares that must be redeemed on Supply later. It also discloses availability guarantees ("never paused, no price feed needed"). The annotations already cover the safety profile (readOnly, idempotent, non-destructive), so this is strong supplementary disclosure rather than the full burden.

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 core purpose is front-loaded, but the middle sentence is a dense parenthetical about vault shares and the phrase "Run from the wallet first" is ambiguous. The content mostly earns its place, yet the phrasing could be tightened without losing meaning.

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 transaction-preparation tool with no output schema, the description covers what is returned (an unsigned transaction), what happens to borrowed funds, and availability constraints. The only real omission is what the agent should do with the unsigned transaction afterward, which is left implicit.

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 descriptions for symbol, wallet, percent, and slip_bps already carry the parameter meaning. The description adds only a loose restatement of percent ("part or all") and no syntax or format detail beyond the schema, which is the expected baseline when the schema does 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 states a specific verb and resource: an unsigned transaction that removes part or all of a wallet's money from a farm. That clearly separates it from farm_deposit and the plain withdraw sibling, although it never names those siblings explicitly and the caller must infer the distinction from the title.

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?

"Run from the wallet first to show what comes back now" hints at a preview-first workflow, but the guidance is cryptic and never says when to pick farm_withdraw over withdraw or supply. Usage is implied rather than stated, leaving the agent to guess at the sequencing and the alternatives.

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 safety is covered. The description adds genuine behavior beyond that: results are ordered worst-first, limit_used is defined with 1 meaning immediately liquidatable, status thresholds (warn 0.85, danger 0.95) are spelled out. It does not cover pagination, empty-wallet behavior, or auth, which keeps it below 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?

One dense sentence, but it is front-loaded with the audience and the core output ordering before enumerating fields. The field enumeration is justified because no output schema exists. The trailing 'Also at /health/<wallet>.json' is minor clutter but still conveys an alternate access path.

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 returns, and it does so thoroughly: ordering, limit_used, health as its reciprocal, liquidation price, distance in percent, status bands, and market clock. It leaves open what happens for a wallet with no shorts or USDG loans, which is the main remaining 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?

With a single parameter at 100% schema description coverage, the schema already tells the agent the wallet address is required. The description adds no format hints or edge-case handling (e.g., checksummed vs lowercase addresses) beyond what the schema provides, 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 names a specific resource and scope: every short and USDG loan of one wallet, sorted worst-first, plus liquidation pricing. It is clearly a read-only health/liquidation report rather than a position or market query. It doesn't explicitly differentiate itself from sibling tools like 'position' or 'prices', which is the only thing keeping it from a 5.

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 opener 'For bots that watch for liquidation' gives a use case, which implies when to reach for it. However, there is no explicit when-not guidance and no named alternative (e.g., 'use position for a full position breakdown'). Usage is inferred 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?

Annotations already cover read-only, idempotent and non-destructive behavior, but the description adds substantial behavioral context: liveness ('false until Borro's keeper publishes its count'), Monday interest rebates, forfeiture if $BORRO is sent away, gas top-up conditions and wallet-type constraints, exclusions for direct supply, and estimate caveats. It is dense and poorly structured, but unusually rich in disclosed 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?

The description is a dense run-on with many parentheticals and a marketing lead, so the core purpose and usage conditions are buried. It contains a lot of information, but it is not front-loaded or efficiently structured.

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 must convey return content, and it enumerates live/counts/share/via/heldBorro/borroForFull/weekSoFarUsdg/interestBackBps/gasOnTheHouse plus per-line and per-market data, rules and paid weeks. It is nearly complete for an agent deciding whether and how to call it, though types and response formatting are absent.

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% for both parameters, so the schema already does the heavy lifting. The description mentions the wallet's $BORRO and borrow_usdg for a planned borrow, but adds little syntax or format meaning beyond what the schema already states.

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 eventually makes clear that this returns a wallet's $BORRO holder benefits on Agent Credit Lines, including with a planned borrow, and that it only reads. But it opens with a marketing slogan and does not state a crisp verb+resource or explicitly differentiate itself from sibling tools like credit_line or credit_gas.

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 explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Usage is only implied by phrases such as 'With borrow_usdg: the same for a planned borrow on top' and 'It reads; it builds no transaction.'

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, idempotent, non-destructive, closed-world, so safety needs no restating. The description does add real value beyond them by disclosing the return contents (rates, sizes, limits, open fee, contracts) — significant since no output schema exists. It stops short of noting whether a missing symbol errors or returns empty, which matters for a ticker-keyed lookup.

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 sentence with no padding, which is appropriately sized for a one-parameter read. But 'from the shelf' is decorative wording that costs clarity rather than earning its place, and the useful content is buried mid-sentence rather than 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 one-param read with full annotation coverage and full schema coverage, the description is close to sufficient — it tells the agent what comes back. Gaps remain on lookup-miss behavior and on how this differs from `markets`/`credit_markets`, which the agent must infer from sibling names alone.

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 `symbol` parameter is well documented, including the ticker format and a pointer to `markets`. The tool description itself adds nothing about the parameter, so the baseline 3 applies — the schema is doing all 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 conveys that this returns a single stock's market data and enumerates the payload (rates, sizes, limits, open fee, contracts), which is genuinely informative. However, there is no verb and the framing 'full line from the shelf' is metaphorical jargon an agent must decode. It also does not name the sibling `markets` as the list-all alternative the way the schema's parameter text 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?

Nothing in the description states when to use this versus `markets`, `prices`, or `credit_markets`. The singular 'One stock' hints at single-symbol lookup, but the routing hint ('markets lists every one') lives in the schema, not the description, so the agent gets no explicit usage rule from the text being scored.

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, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value by enumerating what the payload contains (price, lent, borrowed, free to short, lender APR, shorter APR, USDG borrowing rate, BORRO Drip dollars/day and deposit rate), but phrases it vaguely ('one number each') and says nothing about ordering, completeness, or how the Drip estimate is computed.

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 sentence with no filler pleasantries, and every clause carries content. But it is a long run-on with nested parentheticals ('one number each, $BORRO included once it has been paid'), which makes it harder to parse than a short front-loaded summary followed by bullets would be.

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 needs to carry return-value semantics, and it does enumerate the main fields. It is still incomplete for a market-overview tool: no mention of scope (all stocks vs. filtered), sort order, units/decimals, or what 'free to short' and the Drip estimate actually mean operationally.

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 clarify. Baseline for a parameterless tool is 4.

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 does convey the resource: an overview of every stock market on Borro plus the USDG vault, with lending/borrowing metrics. However, it never uses a clear verb (list/aggregate/get) and does nothing to distinguish itself from close siblings like 'market', 'prices', 'credit_markets', or 'farms', leaving an agent to guess whether this is a list of one market or an aggregate of all.

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 use this tool versus 'market' (singular), 'prices', or 'credit_markets'. Usage is only implied by the enumeration of included data, so the agent must infer routing from names alone.

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 read-only/idempotent/non-destructive, and the description is consistent: the output is unsigned transactions for the wallet to sign, not a state change. It adds context the annotations cannot convey — prerequisite approvals, the lending-fee mechanic, and leverage ceilings — though it omits what happens on failure or whether quotes/prices are fetched at build time.

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?

Front-loaded with purpose in the first clause, followed by mechanism, then prerequisites and limits; no filler sentences. The first sentence is long and jargon-dense, which slows scanning slightly, but each 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?

With no output schema, the description correctly identifies the return as unsigned transactions and covers prerequisites and leverage limits. For a read-only transaction builder that is nearly complete; only failure modes and the source of the approval requirement ('if needed') are left implicit.

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 each of wallet/symbol/margin/leverage is already documented, which sets the baseline at 3. The description does add one useful constraint beyond the schema — the per-symbol maximum leverage — but says nothing extra about margin semantics or symbol validity beyond what the schema states.

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: it returns unsigned transactions that open a leveraged long on a stock, and explains the concrete mechanism (USDG margin + flash-borrowed debt, stock lent and posted). That mechanism implicitly separates it from open_short/open_pair/close_long, 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?

Gives real sequencing guidance: approve the margin and authorize LeverRouter on Morpho if needed, then open. It also bounds applicability with per-symbol leverage caps (1.80x on SPY/QQQ/NVDA, 1.35x elsewhere). It never states when to choose this over open_pair or open_short, so it stops short of explicit alternatives.

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

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

Annotations flag this as read-only, idempotent, and non-destructive, and the description is consistent with that by explicitly saying it returns unsigned transactions rather than executing. It adds genuinely useful non-annotation detail: pricing happens now, simulation is sequential from the wallet, an approval step precedes execution, and the long leg earns lending fees while held.

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 that front-loads the deliverable (unsigned transactions) and the pair mechanics, with the timing/simulation note appended. The parenthetical about lending fees is informative rather than filler, though the sentence is long enough to require careful parsing.

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 6-parameter, no-output-schema preparation tool, the description covers what is produced (unsigned transactions), the ordering (approvals first, simulated in sequence), and when pricing occurs. What is missing is modest: no mention that deposit is optional or what it defaults to, and no hint of failure modes such as insufficient balance.

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 all six parameters are already documented in the schema with format examples. The description explains the roles of the long and short legs but adds no format or constraint detail for wallet, amounts, or the optional deposit beyond what the schema states.

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 deliverable (unsigned transactions) for a specific operation (a pair trade with a long leg and a short leg), which cleanly separates it from open_long, open_short, and close_pair. The two-leg mechanics are spelled out rather than implied.

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?

'approvals first' and 'simulated from the wallet in order' convey sequencing, which is real usage context. However, it never says when to prefer this over calling open_long and open_short separately, or how it relates to close_pair, so the agent must infer the boundary.

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/idempotent/non-destructive, and the description adds genuine context beyond them: it emits unsigned transactions for the wallet to sign, prices at execution time with 0.5% slippage tolerance, runs as a simulation, and routes rebate_estimate into the weekly locker. It stops short of stating failure modes (insufficient collateral, unapproved asset) or what the response looks like structurally.

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, front-loaded with what the tool produces, then the execution sequence, then pricing/slippage, then the rebate semantics. No filler; each clause adds either mechanics or economics.

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 covers the return contract at a useful level: unsigned transactions plus a quote carrying rebate_estimate and a 0.5% slippage bound. Missing is the concrete shape of the returned payload (e.g. a transaction list vs. a single tx) and any error/collateral preconditions.

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 all four parameters including the optional deposit are already documented in the schema. The description adds only marginal meaning, tying 'deposit' to 'the money held' beyond the sale and 'wallet' to 'built for it to sign' — consistent with the baseline 3 when the schema does the heavy lifting.

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 ('Unsigned transactions to short a stock from the wallet') and names the concrete protocol call it emits (BorroShort.open), including the borrow-sell-hold mechanics. An agent can distinguish this from open_long, borrow, and close_short without opening any 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?

Usage is implied by the name and by the phrase 'approve the deposit if needed', which signals a prerequisite step when allowance is insufficient. However, no alternative is named (e.g. when to prefer open_pair, borrow, or close_short) and there are no explicit when-not-to-use conditions.

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 establish read-only, idempotent, non-destructive behavior, so the extra value here is real: expiry settlement at Friday 8pm New York, quote currencies (dollars a share for prices, USDG a share for premiums), and the caveat that fair value is a Black-Scholes guide from measured volatility. It stops short of noting behavior for a stock with no listed options or stale/paused desk handling beyond the live/paused flag.

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?

Length is defensible because there is no output schema and the return payload must be described. However, it is delivered as one long semicolon-chained run-on, which makes the per-strike fields, the stock-level fields, and the desk status hard to separate at a glance.

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 present, the description carries the full burden of explaining returns and does so thoroughly — series id, fair value, delta, best bid/ask, implied IV, open interest-like share counts, plus stock price/volatility and desk status and fee. Only edge-case behavior (nonexistent symbol, no options listed, empty chain) is unaddressed.

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 single symbol parameter is fully documented in the schema, including the pointer to markets for the ticker list. The description adds nothing about the symbol, 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 names the specific resource — one stock's options chain for this Friday and next — with expiry timing, so an agent knows it is a chain read rather than an order action (buy_option, write_option, settle_series). It lacks an explicit verb and never names a sibling, so differentiation is inferable 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?

There is no when-to-use guidance, no mention of alternatives such as prices or market, and no statement of prerequisites or exclusions. The agent must infer that this is the pre-trade lookup for buy_option/write_option chains.

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 value by enumerating the data categories returned, but it does not address auth needs, rate limits, or response structure beyond listing fields.

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 a single sprawling run-on sentence with dense parenthetical nesting. It front-loads the purpose, but the structure makes it hard to scan and parse efficiently.

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 content and does so comprehensively, covering stock lent, shorts, loans, pairs, gap covers, options, bear coins, claims, rebates, and balances. It lacks formal structure, but the content is substantially complete for a read-only position aggregator.

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 single wallet parameter is fully documented in the schema, including that transactions are built for it to sign. The description itself adds no parameter semantics beyond what the schema already provides, 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 clearly states the resource: an aggregate snapshot of everything a wallet has on Borro, followed by an enumeration of position categories. It is specific enough to identify the tool as a wallet-position reader, though it does not explicitly differentiate itself from siblings such as health or markets.

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 offers no guidance on when to use this tool versus alternatives, nor does it state exclusions or prerequisites. An agent can infer it retrieves wallet positions, but the definition does not route the agent among siblings.

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 well beyond the annotations: it discloses the USDG lock-up, the exact-approval-then-postBid sequence, that the premium is paid to the filling writer minus Borro's cut, that option tokens land in this wallet, and that the order is cancellable while open. The 'locked now' phrasing sits slightly at odds with readOnlyHint=true, but the leading 'Unsigned transactions' clause makes clear the tool only prepares calldata rather than moving funds.

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, front-loaded with the deliverable ('Unsigned transactions to post a bid...') and then the funds flow. The colon-and-semicolon run-on is information-heavy but every clause carries distinct content, with 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 seven-parameter preparation tool with no output schema, the description covers the important unknowns: that the result is unsigned transactions for the given wallet to sign, what gets escrowed, and how to back out. It stops short of saying what shape the returned payload takes or whether the wallet must already hold USDG/approval.

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 all seven parameters (including the expiry default and the decimal-string conventions) are already documented. The description's only addition is that the premium is per share and the aggregate is locked upfront, which is useful for sizing but does not deepen any individual parameter's meaning, 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 concrete verb and resource: builds unsigned transactions to post a bid for an option series at a per-share premium, with the counterparty (the writer) and payout flow spelled out. It does not, however, distinguish itself from close siblings like buy_option or write_option, which occupy adjacent ground in the options workflow.

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: you use this when you want to name your own premium rather than take an existing quote. The one explicit routing hint is the reverse direction ('cancel_order takes it back while it is open'), which tells the agent how to undo, not how to choose between bidding and buying outright.

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 covering read-only/idempotent safety, the description adds the context that actually matters: refresh cadence (every 30 seconds), the upstream source (https://borro.markets/prices.json), the market-open vs weekend-shutdown pricing difference, and the caveat that quoted execution prices are before Borro's fee. Those are exactly the behavioral traits an agent needs to reason about data freshness and price comparability.

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?

Content is front-loaded — the main payload (what each entry contains) opens the description, followed by two short clarifying sentences on cadence and source. The first sentence is a long run-on with nested parentheses that takes effort to parse, which keeps it from a top score, but no clause is 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?

There is no output schema, so the description carries the burden of explaining return values — and it does, naming each field's meaning including the sign convention for gapPct. Combined with the freshness and fee caveats, an agent has everything needed to call it and interpret 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The description does not need to compensate for any schema gap here.

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 the exact resource (per-stock-token price data) and enumerates the three values returned: the stock's own Chainlink/estimate price, on-chain executable buy/sell prices at $1,000 and $10,000 sizes, and gapPct. That level of specificity lets an agent distinguish this from `markets`, `market`, or `weekend` without opening any 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?

It gives actionable interpretation ('Positive: the token trades over the stock (short it on Borro); negative: under it (buy and lend it)'), which effectively tells the agent what decision this data feeds. It stops short of naming alternatives to use instead (e.g. `weekend` for pure weekend estimates, `markets` for market metadata), so no explicit when-not 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the agent knows the safety profile and that the call changes no state. The description adds that the output is an unsigned transaction the wallet must sign (a real operational detail), but 'less what its written options pay' is ambiguous about what the caller actually receives and says nothing about prerequisites such as the series being settled.

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 run-on sentence whose core claim is interrupted by an ambiguous trailing clause ('once: stock vault shares for a call, Steakhouse USDG vault shares for a put'). Short, but the clause order buries the operative meaning instead of front-loading it.

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?

There is no output schema and this is a transaction-preparation tool, yet the description does not state the preconditions (series must be settled, caller must be the writer), what the returned transaction contains beyond a vague collateral reference, or what to do with it after signing. For a two-parameter, no-output-schema tool the description should close these gaps and does not.

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 wallet and series_id are already fully documented, including the hint that the wallet must sign. The description adds no per-parameter meaning beyond what the schema says; 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 does identify the action (build an unsigned transaction returning a writer's collateral after a settled series) and the resource, and the payout composition distinguishes it from siblings like write_option or settle_series. But the wording 'giving a writer back the lock of a settled series less what its written options pay, once' is convoluted jargon that forces the agent to decode the purpose rather than read it.

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 explicit when-to-use or when-not-to-use guidance and no named alternatives. The agent must infer from 'settled series' that this is a post-settlement step, and nothing tells it how this differs from settle_series, withdraw, or position, all of which appear in the sibling list.

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 readOnly/idempotent/non-destructive, which would be puzzling for a 'repay' tool; the description resolves this by stating it returns unsigned transactions rather than executing a repayment. Missing are failure conditions (e.g., amount exceeding debt) and whether signing/submission is the caller's responsibility beyond what the wallet param implies.

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, front-loaded with the key fact that these are unsigned transactions, followed by the scope qualifier. No filler or 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?

No output schema exists, and the description does not say what the unsigned transaction payload looks like, how it should be signed/submitted, or how amount and all interact when both are supplied. For a prepare-and-return tool this leaves meaningful gaps, though annotations and a fully described schema carry much of the load.

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 all four parameters are already documented, giving a baseline of 3. The description's parenthetical restates the all/partial distinction already present in the 'all' and 'amount' schema descriptions, adding little beyond what is 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?

States a specific verb (repay), resource (USDG borrowed against a stock), and scope (part or all via all: true). It does not differentiate from the similar sibling credit_repay or clarify how it relates to borrow/release_collateral, so an agent must infer which repay 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 implied: use it when you want to return borrowed USDG against a stock, choosing the all: true variant to close the debt entirely. There is no explicit when-not guidance, no prerequisites (existing borrow position, token approval), and no naming of the alternative repay flow (credit_repay).

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, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful content disclosure (rules, limits, failure modes, contract addresses), but says nothing about return format or granularity, which matters because there is no output schema.

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 filler. The phrasing 'every contract address with what it does, to verify on chain' is slightly list-like but still efficient.

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 no-parameter, read-only reference tool with annotations covering safety, the description sufficiently enumerates what is returned. Without an output schema, a hint about the shape of the returned rules/addresses would be nice but is not essential.

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 the baseline is 4. The description correctly gives no parameter guidance, and none is needed.

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 clear resource: Borro's house rules, limits, failure modes, and contract addresses. It implicitly distinguishes itself from the action-oriented siblings (borrow, repay, markets) as a static reference tool. However, it lacks a crisp verb like 'return' or 'look up', which keeps it just below top marks.

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 'to verify on chain' implies the tool is used for checking protocol rules and addresses, but it never states when to call it versus siblings or when not to. No prerequisites or alternatives are named. Usage is only implied.

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?

The description adds substantial behavioral context beyond annotations: it is an unsigned transaction, anyone may send it, the payout always goes to the buyer, and the transaction voids the cover instead if the first print is late, deviates by more than 50%, or never arrives within seven days. These edge-case outcomes and the premium-return behavior are valuable disclosures for a preparation tool.

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 front-loaded with the core action and avoids filler, though the first sentence is dense with nested clauses. It is appropriately sized for the complexity of the operation.

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 complex financial preparation tool with no output schema, the description explains that the output is an unsigned transaction and describes the payout and invalidation conditions. It remains slightly incomplete on how the prepared transaction should be handled after generation.

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 documented in the schema. The description reinforces that the wallet can be any address and that the payout goes to the cover's buyer, but adds little parameter-level semantics 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 states a specific verb ('settling a cover') and resource, and specifies the exact feed mechanism ('first round at or after its reopen'). It is clear what the tool prepares, but it does not explicitly differentiate itself from siblings such as claim_cover or settle_series.

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 explains the mechanics of the resulting transaction but never says when to use this tool versus alternatives like claim_cover, settle_series, or withdraw_cover. 'Anyone may send it' describes transaction permissions, not when an agent should select this preparation tool.

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 cover read-only, idempotent, and non-destructive, but the description goes well beyond them by stating this is an unsigned transaction the caller must send, the exact proof logic that determines the settlement price, the two-day no-print edge case, the 14-day void(id) fallback, and the output (settlement price and per-share payoff). That is substantive behavioral context an agent could not get from structured fields.

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 purpose is front-loaded, but the body is two sprawling run-on sentences with nested parentheticals that are hard to parse on a first read. Most content earns its place, but the packaging slows comprehension of what should be a short settlement rule set.

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 compensates by stating what the call produces (settlement price and what it pays a share) and what the alternative build is (void(id)). Combined with full schema coverage and annotations, an agent has enough to call it correctly; only the absence of sibling routing keeps it from a 5.

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 every parameter already carries its own documentation, including the acceptable series_id vs. symbol/expiry/strike/type alternative. The description adds conceptual framing (expiry time, rounds) but no additional syntax or format guidance, 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 opening names a specific resource (a series) and its settlement condition (after Friday 8pm New York expiry, last round at or before it) and explicitly frames the output as an unsigned transaction. The purpose is unmistakable, but it never contrasts itself with near-siblings such as settle_cover or claim_option, so an agent must still infer which settlement 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?

The description spells out the triggering conditions in detail: expiry passed, proof holds (next round printed after expiry or it is the feed's latest), the no-print-in-two-days branch, and the 14-day void(id) fallback. It also notes 'Anyone may send either,' clarifying permissions. What is missing is any explicit routing against alternative tools, so it stops short of a 5.

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 non-destructive, so the description's key contribution is that it returns *unsigned* transactions the wallet must sign, which is critical behavioral context not in the annotations or schema. It also explains the economic effect (earns lending fees/interest) and the side effect of post:true (collateral enabling borrowing). It does not mention ordering of returned transactions or approval 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?

Two sentences, no filler, with the asset choice stated first and the post flag second. Every clause carries information an agent needs.

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 4-param prepare/build tool with no output schema, the description covers the asset duality, the post shortcut, and the unsigned-transaction nature. Remaining gaps (approval flows, whether the txs must be submitted in order, fee accrual details) are secondary but would matter for a full workflow.

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 baseline is 3; the description exceeds that by explaining *why* post exists ('lent and posted in one step so USDG can be borrowed against it') and by framing 'asset' as either USDG or a stock symbol with different downstream behavior. Amount formatting and wallet signing are left to 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?

States a concrete payload ('unsigned transactions') and two distinct modes: lending a stock to shorters for fees, or supplying USDG to the Borro USDG vault for interest. This is specific and distinct from borrow/repay siblings, though it never names an adjacent tool to sharpen 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?

Implied usage is clear enough (earn fees/interest, or enable borrowing via post:true), and the post case is conditioned explicitly. However there is no when-not guidance, no statement of required prerequisites (e.g. token approval, sufficient balance), and no comparison to the obvious alternative 'borrow' beyond a passing mention.

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=false, so the safety profile is covered. The description adds useful scope and ordering context ('Borro-wide', 'newest first'), but does not disclose the time window, result limit, or pagination 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 short sentence with no filler. The scope and ordering are front-loaded and every word contributes to the definition.

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-only, zero-parameter list tool, the description is adequate but leaves key operational details undefined: what 'recent' means in time, how many trades are returned, and whether results are paginated. With no output schema, those gaps remain unaddressed.

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 compensate for. Baseline 4 applies for a parameterless tool.

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 resource (recent shorts opened and closed) with explicit scope ('Borro-wide') and ordering ('newest first'), which distinguishes it from account-scoped siblings like position. It lacks an explicit verb and does not name a sibling alternative, but the resource is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no mention of alternatives such as position or the open_short/close_short mutation tools, and no exclusions. Only the implied 'recent' framing hints at usage.

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 establish read-only, idempotent, non-destructive, and non-open-world behavior. The description adds meaningful domain behavior beyond those annotations: price feeds pause at the last print during market closure, the weekend price is not read on chain, and a market clock is included. It still lacks error behavior when the market is open and freshness/update details.

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-loads the market-closed condition, with each sentence contributing needed output scope. However, the long clause-heavy 'For each stock...' list is dense and would be easier to scan as structured bullets.

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 complex weekend/off-chain data tool with no output schema, the description covers the main returned datasets and the important off-chain caveat. It still omits the exact response shape and what happens outside the weekend window, so it is not fully complete.

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 single optional symbol parameter is fully documented in the schema with 100% coverage. The description's phrase 'For each stock' hints that omitting the symbol may return all stocks, but it does not explicitly define the optional parameter behavior beyond what the schema already states.

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 data resource: weekend paused prices, Borro's weekend price and 95% band, Monday gaps, gap cover quotes, market clock, and pool details. It does not use a direct verb such as 'returns' and does not name sibling alternatives like prices or market, so it falls short of a 5.

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 opening clause implies this is for use while the stock market is shut (Friday 8pm to Sunday 8pm New York, and holidays), but there is no explicit when-to-use/when-not-to-use guidance or named alternative. The line 'Nothing on chain reads the weekend price' is a caveat, not a routing rule.

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 cover the safety profile (readOnly, non-destructive, idempotent), and the description adds meaningful context beyond them: the output is an *unsigned* transaction the wallet must still sign, and lent stock only comes back 'once it is returned', which is a real availability caveat. It stops short of describing the transaction payload, fees, or any prerequisite approvals.

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 the all: true switch, with no filler. The trailing sentence about stock returning 'once it is returned' is slightly cryptic in phrasing but earns its place as a timing caveat.

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 say what the caller receives (an unsigned tx object to sign) and what happens if neither amount nor all is supplied, since only wallet and asset are required. The prepare-then-sign flow is hinted at but not fully spelled out, leaving a meaningful gap for a transaction-building 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 coverage is 100%, so the baseline is 3, but the description genuinely adds semantics: it clarifies the either/or between taking 'part' (amount) and 'all with all: true', a mutual-exclusivity the schema does not express. It leaves the exact amount format to the schema, which 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 and resource: builds an 'unsigned transaction to take back lent stock or USDG', which is a concrete action an agent can match to intent. It implicitly distinguishes itself from siblings like borrow, supply, and withdraw_cover by scoping to returning lent assets, but it never names an alternative to contrast against.

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 implied by 'take back lent stock or USDG' and the either/or of a partial amount versus all: true, so an agent can infer when it applies. However, there is no explicit when-to-use/when-not guidance relative to siblings such as release_collateral, withdraw_cover, or farm_withdraw, which are close enough in name to cause confusion.

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/idempotent/non-destructive, consistent with a transaction-builder that signs outside the tool. The description adds real context the annotations lack: the capital-lock window tied to live covers and weekly settlement, and that the result is unsigned and must be signed by the wallet.

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?

Compactly front-loads the core purpose in the first clause, then packs timing constraint and signing note into two short sentences. The final clause about running from the wallet is the least clear and is slightly cryptic, but nothing is wasted.

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 the necessary work of saying the return is an unsigned transaction for the wallet to sign. The lock/settlement timing covers the main behavioral risk; only the mutual exclusivity of amount vs all and the pre-check step remain slightly underspecified.

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 explains amount, all, and wallet in detail. The phrase 'an amount or all: true' adds a small hint that the two are alternatives rather than cumulative, but nothing beyond that.

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?

Names a specific verb+resource ('take USDG out of the gap cover pool') and clarifies that this returns an unsigned transaction, which matters against siblings like withdraw and claim_cover. It never explicitly contrasts itself with those siblings, so an agent must 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?

Provides a real usage condition – capital is locked while covers are live, from first buy of a closure until Monday's settlement, so withdraw during the week. However, it gives no guidance on when to prefer this over claim_cover, settle_cover, or plain withdraw, and 'Run from the wallet first to show what comes back' is vague enough to be ambiguous about what should be run.

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 only declare readOnly/idempotent/non-destructive, so the description adds real substance: collateral is locked at write time for an ask and fills only when a buyer takes it, an ask's premium is reduced by Borro's share, one share of stock vault collateral is locked per call share, and the flow does an exact approval then simulates from the wallet. It stops short of covering failure modes or the signing sequence after simulation.

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?

Front-loaded: the first clause says it produces unsigned transactions and the two routing modes come before the collateral mechanics. It is dense and parenthesis-heavy, but every clause carries a distinct fact (lock source, collateral vault, approval/simulation) rather than 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 9-parameter, no-output-schema prepare tool it covers a lot: what gets locked, from where, the ask-vs-bid branch, and the approval/simulation step. Remaining gap is that it never says what is returned (unsigned transaction objects to sign) nor which parameters pair with which mode (premium vs order_id exclusivity).

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 already documented (including the `from` default per option type and order_id replacing premium). The description restates the same choices at a higher level but adds no syntax or constraint detail beyond the schema, so the baseline 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 names a specific verb and object: it returns unsigned transactions (prepared, not executed) for writing calls or puts, and it spells out the two ways to do it — post an ask at a premium or, with order_id, sell into an existing bid. That 'prepare' framing separates it from execution-oriented siblings like buy_option or settle_series without ambiguity.

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 gives clear decision context: omit order_id and supply a premium to post an ask; pass order_id to hit that bid immediately at its premium. It also states the defaults for the `from` source per option type. What it lacks is explicit exclusion language or prerequisites (e.g. required balance/position before writing).

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