Server Quality Checklist

Tool Scores

• get_health_factorA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• get_positionA
  3.6/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• get_tvlA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• get_liquidation_candidatesA
  3.7/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• deposit_txnA
  3.8/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines2/5

  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.

• get_marketsA
  3.8/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• liquidate_txnA
  3.8/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• repay_txnA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• borrow_txnA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• withdraw_txnA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.