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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully discloses that the tool builds unsigned transactions, returns base64-encoded transactions, and requires sufficient collateral. It does not mention potential errors or whether the collateral check happens at build time, but the core behavioral contract is clear.

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 concise sentences deliver action, precondition, and output format with no filler. Every sentence earns its place, and the most important information (what is built and for whom) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a transaction-building tool with four documented parameters and no output schema, the description covers the essential extra context: it returns base64-encoded unsigned transactions for signing and requires collateral. Some operational details like failure behavior or collateral specification are absent, but the core invocation and output contract is sufficiently 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?

Schema description coverage is 100%, with all four parameters having meaningful descriptions in the schema. The tool description adds the overarching context of collateral sufficiency and unsigned output but does not add parameter-specific details beyond what the schema already provides. 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 uses a specific verb ('Build') and resource ('unsigned transactions to borrow tokens from a DorkFi lending market'), clearly stating what the tool produces. It differentiates itself from sibling transaction tools like deposit_txn, repay_txn, and withdraw_txn through the explicit 'borrow tokens' action.

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 clearly identifies borrowing as the use case and adds a critical precondition: 'Requires sufficient collateral.' It does not explicitly name alternatives or say when not to use it, but the sibling tool names and the borrow-specific language make the intended context clear.

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

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

With no annotations, the description carries the full burden. It clearly discloses a key behavioral trait: the tool builds unsigned transactions rather than submitting them, and returns base64-encoded output intended for signing via UluWalletMCP. This gives the agent an accurate model of side effects, though it could go further in stating explicitly that nothing is sent on-chain.

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

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

The description is two sentences, both functional, and the core purpose is front-loaded. There is no filler or redundant elaboration.

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 absence of an output schema, the description adequately explains what the agent receives ('base64-encoded transactions') and what to do with it ('for signing via UluWalletMCP'). While it omits some finer points such as error behavior or multiple transaction responses, it is sufficient for correct selection and invocation in most 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 documents all parameters thoroughly. The description itself adds no new parameter-level detail beyond the overall deposit intent, so it meets the baseline without needing to compensate.

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 ('Build'), a resource ('unsigned transactions to deposit (supply) tokens into a DorkFi lending market'), and the output format. This clearly distinguishes it from sibling tools like withdraw_txn or borrow_txn even without naming 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?

No guidance is given about when to use this tool versus its siblings. The agent must infer that deposit_txn is for supplying tokens, but there is no explicit mention of alternatives or conditions that would favor another tool such as withdraw_txn or borrow_txn.

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

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

With no annotations, the description carries full burden. It discloses that it builds unsigned transactions, calls fetch_price_feed(uint64) on the pool contract, and returns base64-encoded transactions for signing. This clarifies that the tool does not execute transactions itself, which is essential 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 only two sentences, front-loads the purpose, and includes the key behavioral details without any fluff. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the return value (base64-encoded transactions) and the underlying operation. It omits any mention of error handling or how to use the signed transactions, but is sufficient for a simple transaction builder with 100% schema coverage.

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 parameter already has a description in the schema. The tool description adds no additional parameter-level semantics beyond the contract call context, keeping it at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it builds unsigned transactions to fetch the latest oracle price for a DorkFi lending market, specifies the contract function called, and distinguishes itself from sibling read-only getters and other transaction builders.

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 provides clear context that this is for building transactions rather than directly querying price, and notes the output is for signing. However, it does not explicitly mention alternatives like get_market or when not to use this tool, so it lacks full 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?

No annotations are provided, so the description carries the burden. It mentions using 'algod simulate' which implies a safe, read-only operation, and specifies the returned data (collateral and borrow values). However, it does not disclose error behavior, rate limits, or other side effects.

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, front-loaded sentence that efficiently conveys the tool's purpose and method. There is no redundant information or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with no output schema, the description adequately explains what the tool returns and the underlying mechanism (ABI method via algod simulate). It covers the essential context needed for correct invocation, though it could mention return format or units.

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 fully described in the schema. The description adds context by explaining the address is for a user and the values are aggregated across pools, but does not provide new parameter-specific 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?

The description clearly states the tool retrieves aggregate collateral and borrow values for a user across all pools, using a specific verb and resource. It distinguishes itself from siblings like get_user by emphasizing the 'aggregate' and 'across all pools' scope.

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

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

No explicit guidance on when to use this tool versus alternatives like get_user or get_position. The phrase 'across all pools' implies a contrast but does not explicitly state exclusions or alternative recommendations.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully explains that health factor <= 1.0 means the position is liquidatable, and 'Check' implies a read operation. However, it does not describe the response format, per-pool aggregation, or any limitations.

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

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

The description is two concise sentences with the core purpose and threshold meaning front-loaded. There is no filler or redundant 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 low-complexity, 2-parameter read-only lookup, the schema plus description give an agent sufficient information to select and invoke the tool: chain, address, and the meaning of the health-factor result. Missing output structure and explicit sibling differentiation are minor for this simple 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?

Both parameters are fully documented in the input schema, so schema description coverage is 100% and the baseline is 3. The description does not add additional parameter-level detail beyond the health-factor interpretation.

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 operation (Check) and resource (user's health factor and risk level per pool), and adds the liquidation threshold as a meaningful semantic detail. It does not explicitly contrast with siblings like get_position or get_liquidation_candidates, so differentiation relies mostly on the unique 'health factor' terminology.

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 liquidation threshold implies the tool is for assessing liquidation risk, which gives some usage context. There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are mentioned, so the agent must infer the proper use case.

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

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

With no annotations provided, the description carries the burden, and it does disclose that the tool relies on 'pre-indexed health data,' implying potentially non-real-time data, and that it returns only accounts below the threshold. However, it does not state read-only behavior, ordering, pagination, or staleness caveats explicitly.

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 exactly two sentences with no filler. The core purpose is front-loaded, and the return criterion is stated succinctly in the second sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential selection criterion and data source, and the schema fills parameter details, but there is no output schema and no annotation safety information. It is adequate for a simple read-only candidate listing, yet it omits details like return shape, ordering, and whether results reflect real-time data.

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 adds little parameter-specific meaning beyond framing the threshold concept, but it does not need to compensate for missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource, 'Find accounts eligible for liquidation,' which clearly states what the tool does. It also adds the distinguishing detail 'using pre-indexed health data' and 'below the health factor threshold,' separating it from on-demand scanning tools and from liquidate_txn which performs the actual liquidation.

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 the tool should be used when the agent needs a list of accounts eligible for liquidation based on health factor. However, it does not explicitly state when to use this tool versus alternatives like get_health_factor for a single account or liquidate_txn for executing a liquidation.

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

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

No annotations are provided, so the description carries the burden. It notes the call uses 'algod simulate', suggesting a read-only simulation, but does not explicitly state there are no side effects, potential failure modes, or expected latency. This is adequate for a simple getter but not richly transparent.

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

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

The description is a single sentence that is concise and front-loaded with the core purpose. It includes technical implementation details (call via algod simulate) that add context but could be considered slightly verbose for an agent that mainly needs to know what it does.

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's 'full on-chain data' is vague and does not enumerate what fields or structure to expect. It also omits error conditions and network specifics. For a simple two-parameter getter, this is minimally sufficient but leaves 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?

The input schema provides 100% coverage with both 'chain' and 'symbol' having descriptions. The description adds no additional semantic detail beyond what the schema already states, so it meets the baseline but does not elevate it.

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 tool gets a single DorkFi lending market's full on-chain data via a specific ABI method. It explicitly uses 'single', distinguishing it from the sibling 'get_markets' tool, and specifies the resource (DorkFi lending market) and action (get).

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

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

The description implies usage for a single market, contrasting with get_markets for plural. However, it does not explicitly state when not to use it or mention alternatives beyond the implicit 'single' vs 'plural' distinction.

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

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

With no annotations, the description carries the burden of explaining behavior. It states the output includes live market data and that symbol filtering is optional, which is useful, but it does not mention whether the call is read-only, how results are ordered, pagination, or exact response shape. For a list, live data and safety profile are still under-specified.

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 brief and front-loaded with the core action and result content. The optional-filter nuance is a single sentence. Every word contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with no output schema, the description adequately enumerates the returned data: rates, deposits, borrows, prices. It does not mention that chain is required, but the schema's required field and enum cover that; the main missing piece is explicit guidance about the optional symbol filter's matching behavior.

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

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

Schema description coverage is 100%, so the schema already explains chain and symbol. The description adds that symbol filtering is optional, but it does not add meaningful semantics beyond the schema's 'Filter by token symbol' description.

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 tool lists DorkFi lending markets and specifies the live data included: rates, deposits, borrows, and prices. It differentiates itself from siblings like get_position, get_health_factor, and deposit_txn by naming its resource as markets rather than a single position or transaction.

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 the primary use case: retrieving market data, optionally filtered by symbol. However, it does not explicitly contrast with alternatives such as get_tvl or get_liquidation_candidates, so an agent must infer when this tool is preferred over others.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does not explicitly state that the operation is read-only, nor does it mention permissions, side effects, or rate limits. The verb 'Get' implies no mutation, but that is not made explicit.

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 composed of two concise sentences that front-load the operation and then summarize the return payload. Every word contributes meaning, with no repetition or 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 read-only tool with a fully documented schema, the description covers the core purpose and key return categories. However, because there is no output schema, the agent must infer the exact structure of the 'portfolio summary', and the optional symbol filter is only discoverable by inspecting the schema.

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

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

The input schema provides descriptions for all three parameters, giving 100% coverage, so the baseline is 3. The tool description adds no additional parameter-level meaning, such as how the symbol filter interacts with 'across all markets'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and a clear resource: 'a user's DorkFi lending positions across all markets'. It also distinguishes itself from siblings by mentioning per-pool health factors and a portfolio summary, making it clear this is the portfolio-level view rather than get_health_factor or get_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 implies this tool is for retrieving a user's full lending portfolio, but it gives no explicit guidance about when to choose it over alternatives like get_health_factor for single-pool health or get_markets for market-level data. There is no exclusion or alternative mentioned, leaving usage somewhat to inference.

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

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

No annotations are provided, so the description carries full responsibility. It discloses the read-only nature implicitly through 'Get' and states the return contents, but it does not address permissions, rate limits, or side effects. This is partially transparent but has gaps.

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

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

The description is two short sentences, front-loads the action and resource, and contains no filler. Every phrase adds information about scope or return contents.

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 tool with one optional enum parameter, the description's combination of scope ('across DorkFi lending pools') and return details ('per market and aggregate totals') is nearly sufficient. It lacks explicit mention of response field names or currency units, but given the low complexity and rich schema, it is mostly 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 only parameter, 'chain', is fully described in the input schema with an enum and filtering semantics, so schema coverage is 100%. The description adds no additional parameter details, warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and a clear resource ('total value locked across DorkFi lending pools'), and states the return shape ('per market and aggregate totals'). However, it does not explicitly differentiate itself from sibling tools like get_markets, which could also involve market-level metrics, 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?

There is no explicit statement of when to choose this tool over alternatives. The description implies usage via the verb 'Get' and the TVL focus, but it gives no exclusions or comparisons to sibling tools such as get_markets, leaving the agent to infer.

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

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

No annotations are provided, so the description carries the burden. It discloses the mechanism (calling pool contract's get_user ABI method via algod simulate), which implies a read-only simulation. However, it doesn't disclose what happens if the market is paused, what the return data contains, or any side effects (likely none). The phrase 'via algod simulate' gives some transparency about the simulation nature, but more context on output or errors would be helpful.

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 that is reasonably concise and includes the essential action and method. It is not overly verbose, but could be slightly improved by adding a brief note on usage without bloating.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has three simple parameters with full schema coverage, so the description doesn't need to explain return values (no output schema exists, but the description could mention what 'position data' includes). Contextually, it's complete enough for a straightforward getter, but the lack of output schema and minimal description of the return payload leaves some ambiguity about what exactly is returned and how to interpret it.

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

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

Schema coverage is 100%, with descriptions for all three parameters. The description itself doesn't add much beyond the schema, but that's acceptable because the schema already documents each parameter. The description does clarify that the tool targets a DorkFi lending market, which gives context to the symbol parameter, but this is minimal added value.

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 tool retrieves a user's on-chain position data for a DorkFi lending market, specifying the contract call and method (get_user) and the simulation via algod. It distinguishes from siblings like get_markets and get_market by focusing on a user's position, though it doesn't explicitly mention 'get_position' which might be a close alternative.

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 the tool is used when you need a specific user's position in a specific market, but it doesn't provide explicit when-to-use versus alternatives like get_position or get_health_factor. Sibling names suggest overlapping functionality, but no guidance is given on choosing among them.

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

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

With no annotations, the description carries the burden. It discloses sorting behavior and output fields but does not mention potential performance issues, pagination, or that it requires the chain parameter (though schema covers that). It's a read-only operation, but no safety details are given.

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

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

The description is two concise sentences that front-load the purpose and sorting order. Every word adds value, with no 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?

The tool is simple with one documented parameter and no output schema. The description provides the core output fields and sorting, which is sufficient for an agent to invoke it correctly. It lacks any caveats about data volume or chain-scoping, but those are minor given the simplicity.

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 description does not mention the chain parameter, but the schema fully documents it (100% coverage), so the baseline of 3 applies. The description adds no additional parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' and identifies the resource 'DorkFi users' with the exact output fields (health factors, collateral, borrows, risk levels) and sorting order. This clearly distinguishes it from sibling tools like get_user (singular) or get_health_factor.

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 provides clear context for when to use this tool: to get an overview of all users with risk metrics, sorted by health factor. However, it does not explicitly mention alternatives or exclusions, such as preferring get_user for a single user, so it lacks explicit usage guidance relative to 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?

With no annotations, the description carries the transparency burden. It discloses that the tool uses algod simulate (suggesting a read-only simulation) and returns pause status per pool. However, it does not describe error behavior or what 'paused' means. This is adequate for a simple read operation but lacks depth.

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, front-loaded sentence that states the purpose, method, and return value. It is concise with 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?

For a simple tool with one parameter and no output schema, the description covers what it does, how it does it, and what it returns. It lacks explicit usage guidance (covered in a separate dimension) but is otherwise complete for this tool's complexity.

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 schema fully covers the single parameter (chain) with an enum and description, so the description adds no additional parameter meaning. Baseline 3 applies because schema coverage is 100%.

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 tool's purpose with a specific verb ('Check') and resource ('DorkFi lending pool contracts are paused'). It also mentions the method ('calling the is_paused ABI method via algod simulate'), distinguishing it from sibling tools as the only pause-status checker.

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

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

The description implies usage (to check whether pools are paused) but does not explicitly state when to use this tool versus alternatives or provide exclusions. No alternatives are mentioned, so guidance 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?

With no annotations, the description carries the full disclosure burden and does it well: it reveals that the tool only builds unsigned transactions, that output is base64-encoded and intended for signing, and that the operation repays part of the debt in exchange for collateral at a bonus. It does not cover failure modes (e.g., healthy position or insufficient debt) or whether the result is one transaction or several.

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 and roughly 40 words, with the primary purpose front-loaded in sentence one, the economic mechanism in sentence two, and the output contract in sentence three. Every sentence earns its place; there is no repetition of schema 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 6-parameter transaction builder with no output schema and no annotations, the description covers purpose, mechanism, and return format — the essentials an agent needs to invoke it correctly. Residual gaps, such as whether multiple transactions are returned, prerequisite token availability, and behavior when a position is not actually undercollateralized, keep it from being 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?

Schema description coverage is 100%, so the baseline is 3. The description adds marginal nuance: 'part of the debt' frames the amount parameter and 'at a bonus' gives economic meaning to collateral_symbol, but the per-parameter schema descriptions already carry most of the semantic weight.

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: 'Build unsigned transactions to liquidate an undercollateralized position.' The second sentence adds the defining economic mechanic (repay debt, receive collateral at a bonus), which conceptually separates it from sibling tx builders like repay_txn, deposit_txn, borrow_txn, and withdraw_txn. It stops short of naming a sibling explicitly, so it misses the top score.

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 context is implied: the tool is for liquidators acting on an undercollateralized position, and the bonus mechanism hints at why it differs from repay_txn. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of pairing with get_liquidation_candidates to discover targets, and no prerequisite conditions (e.g., holding the debt 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?

With no annotations provided, the description carries full responsibility. It discloses the step-by-step process (queries borrow amount, wraps tokens if needed, calls repay_all), the output format (base64-encoded transactions for signing), and that it does not execute transactions itself. This is thorough for a transaction builder.

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 concise sentences: the first states purpose, the second outlines process and output. No filler words, front-loaded with the most important information, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers the tool's operation: purpose, internal steps, and return format. Given the simple schema (3 required params) and no output schema, this is complete. It also differentiates from the partial repay sibling by highlighting 'entire borrow 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 coverage is 100%, so the baseline is 3. The description adds a small behavioral detail (wrapping tokens if needed) but does not expand on parameter formats or constraints beyond what the schema already provides. The schema descriptions for chain, sender, and symbol are sufficient.

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 tool builds unsigned transactions to repay a user's entire borrow balance for a DorkFi lending market. The verb 'repay' plus scope 'entire borrow balance' distinguishes it from sibling tools like repay_txn and repay_on_behalf_txn.

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

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

The description implies usage when the goal is to repay the full outstanding balance, emphasizing 'entire borrow balance' and 'calls repay_all'. It does not explicitly compare to alternatives, but the context is clear enough to guide selection without exclusions.

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

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

With no annotations, the description must disclose key behaviors itself. It does so by stating that transactions are unsigned and that the output is base64-encoded for signing, which is critical for an agent to understand the tool's non-executing nature. It also clarifies the sender/borrower roles, though it does not cover every possible edge case.

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 exceptionally concise, consisting of three sentences that front-load the main purpose and immediately follow with role clarification and output format. There is no redundant or unnecessary wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides sufficient context for an agent to understand the tool's purpose, how it works, and what it returns. It lacks an output schema but compensates by explicitly stating the base64-encoded output for signing. It could mention prerequisites or error conditions, but those are not essential for basic understanding.

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 schema provides 100% parameter coverage, so the description adds little semantic value. It only reinforces the sender/borrower relationship already defined in the schema, and does not provide additional details like amount formatting or edge cases. A score of 3 is the baseline for high schema coverage.

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 that the tool builds unsigned transactions to repay another user's borrowed tokens to a DorkFi lending market. The verb 'repay' and resource 'another user's borrowed tokens' are specific, and the description distinguishes from sibling repay tools by emphasizing 'on behalf of the borrower'.

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 provides clear context by specifying that the sender pays on behalf of the borrower, making it obvious when to use this tool. However, it does not explicitly name alternatives like repay_txn or state when not to use, so it falls short of the top score.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool only builds unsigned transactions and does not sign or broadcast them, and it specifies the return format. This is important behavioral context for a transaction-building tool. It could add more, such as notes on chain-specific behavior, but the key behavior is transparent.

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

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

Two sentences with no filler. The core action and output format are front-loaded, and every word adds value. This is a model of conciseness.

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 four required parameters and no output schema, the description adequately covers what the tool returns and what it does. It does not explain nuances like whether multiple transactions may be returned or whether chain affects the output, but these are not essential for correct invocation.

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 adds no additional parameter meaning beyond what the schema already provides, but the schema descriptions are self-sufficient for all four 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 states the verb ('Build unsigned transactions') and the specific resource ('to repay borrowed tokens to a DorkFi lending market'). It also names the output format ('base64-encoded transactions for signing'), which distinguishes it from other transaction builders like deposit_txn, borrow_txn, and withdraw_txn.

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 context is implied by the purpose: an agent would use this when a repayment transaction is needed. However, there is no explicit guidance on when not to use it or which sibling tool to prefer in edge cases, such as liquidate_txn.

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?

Without annotations, the description carries the burden of behavioral disclosure. It transparently states that the tool builds unsigned transactions and returns base64-encoded transactions for signing, and it discloses the underlying contract call (sync_market(uint64)). It does not detail permissions or potential errors, but the safety of building an unsigned transaction is clear.

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

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

The description is two sentences with no redundancy: the first sentence defines the purpose, the second sentence gives the contract call and return format. It is front-loaded and 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 transaction-building tool with no output schema, the description sufficiently covers the purpose, implementation, and return format. It lacks an explicit usage alternative comparison, but the core information needed to invoke the tool correctly is present. The sender and chain parameters are in the schema, and the return type is described.

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

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

The input schema covers all three parameters with descriptions (100% coverage), and the description does not add additional semantic detail beyond what the schema provides. The mention of 'interest accrual, index updates' in the description gives context to the symbol parameter, but the schema's description already covers the idea of the market. Thus, the description adds minimal value for parameter understanding.

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 tool's purpose with a specific verb ('Build') and resource ('unsigned transactions to sync a DorkFi lending market's state'), and specifies the on-chain call (sync_market(uint64)) and return format. This distinguishes it from the sibling sync_user_market_for_price_change_txn by focusing on market-level state rather than user-level.

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 provides clear context on the tool's function—syncing market state (interest accrual, index updates)—and mentions the contract call. However, it does not explicitly state when to use this versus alternatives, such as sync_user_market_for_price_change_txn, or provide exclusion criteria.

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

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

With no annotations, the description carries the full burden. It discloses that the transactions are unsigned and returned base64-encoded for signing, which is a key safety trait. It also explains the effect (updates collateral and borrow values). It doesn't cover prerequisites or failure modes, but the core behavior is transparent.

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

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

Two sentences, front-loaded with the core purpose and then the output format. Every word earns its place, with no redundancy or 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?

The description explains what the tool does and its output format, which is adequate for a transaction builder with a rich schema. It could mention that multiple transactions may be returned or prerequisites like needing a recent price feed, but overall it's sufficiently 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 input schema has 100% parameter description coverage, so the description doesn't need to repeat parameter details. The description implicitly references 'user' and 'symbol' but adds no extra semantic 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 clearly identifies the action (builds unsigned transactions), the target (user's market position), and the trigger context (after oracle price change). It distinguishes from the sibling 'sync_market_txn' by focusing on the user's position rather than the market itself.

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 provides a clear trigger context ('after an oracle price change') and states the purpose, which is sufficient for most use cases. However, it does not explicitly mention when not to use it or name alternatives like 'sync_market_txn' or 'liquidate_txn', 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?

With no annotations provided, the description carries the burden. It discloses that the tool 'Build unsigned transactions' (not directly executing) and that it 'Returns base64-encoded transactions for signing', indicating the output format and non-mutating nature. The 'Owner/admin only' constraint is also disclosed. This provides meaningful behavioral context beyond a simple action statement.

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

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

The description is two sentences long, front-loaded with the primary action ('Build unsigned transactions to withdraw accumulated reserves'), followed by essential constraints. Every word earns its place, with no redundant 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?

Given the tool's simplicity, the description covers the key aspects: the action, the target resource, access restrictions, output format, and non-execution behavior. The absence of an output schema is compensated by the explicit mention of base64-encoded transactions. Minor gaps like potential failure conditions or prerequisites are not critical for this transaction-builder context.

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 with descriptions. The description does not add extra parameter semantics, which is acceptable per the baseline. While it omits details like the relationship between 'amount' and 'accumulated reserves', the schema already explains the parameters adequately.

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 to withdraw accumulated reserves from a DorkFi lending market.' It clearly distinguishes from sibling tools like 'withdraw_txn' by using 'reserves' and 'Owner/admin only', making the scope 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 provides clear context with 'Owner/admin only' and 'accumulated reserves', which implies this tool is for administrative reserve withdrawals rather than regular user withdrawals. However, it does not explicitly name alternative tools or state when not to use it, so it falls just short of full guidance.

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

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

With no annotations, the description carries the behavioral burden and does well by disclosing that the tool only builds unsigned transactions and returns base64-encoded output 'for signing.' This tells the agent the tool does not submit or execute the transaction. It does not cover prerequisites or failure modes, but the unsigned-transaction framing is a meaningful behavioral disclosure.

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

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

A single, front-loaded sentence that packs in the action, resource, output format, and purpose. No filler, no repetition, and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple: four flat required parameters, no output schema, and no annotations. The description plus schema cover what the agent needs to call it correctly, including the base64-encoded unsigned-transaction return. It doesn't explain the full signing/submission flow, but 'for signing' is adequate for an agent to understand the next step.

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

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

Schema description coverage is 100%, so the input schema already documents all four parameters (chain, symbol, amount, sender). The description adds no parameter-level detail beyond what the schema provides, 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 uses a specific verb ('Build') plus a clear resource ('unsigned transactions to withdraw supplied tokens from a DorkFi lending market') and the return format. It distinguishes this tool from sibling txn builders like deposit_txn, borrow_txn, and repay_txn by naming the withdraw action 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 description provides clear context: it is for withdrawing supplied tokens from a DorkFi market, which signals when to use it over the deposit/borrow/repay/liquidate siblings. It does not name alternatives or explicit exclusions, but the intended usage is unambiguous.

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