lends-mcp-server

Official

by LendsProtocol

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Tools are grouped by category (math/get/quote/prepare/assert) and mostly map to distinct resources and actions. Some overlap exists between the generic approve tool and the five purpose-specific approval tools, but descriptions are clear enough to disambiguate.
Naming Consistency5/5
All tools share the lends_ prefix and follow a consistent lends_<category>_<action/noun> snake_case pattern. Even long names remain predictable and readable.
Tool Count2/5
At 37 tools, the surface is well above the 25-tool threshold and feels heavy, especially with six approval variants and eight math helpers. The protocol scope is broad, but consolidation would make the set more manageable.
Completeness3/5
Core user lifecycle operations for collateral, borrowing, PSM swaps, staking, and unstaking are well covered. However, there is no prepare or execute liquidation transaction despite the presence of get_liquidation_plan, leaving a notable gap in the liquidation workflow.
Average 3.6/5 across 37 of 37 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description's 'Construct ... transaction' implies an offline build operation and adds the sleUSD unstake-request scope, but it discloses no further behavioral traits such as side effects, chain interaction, or return format. Given the strong annotation coverage, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler, and it front-loads the action and resource. It is concise but very sparse, which prevents a 5 because it omits important contextual detail while remaining short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and the description does not state what the tool returns, such as a transaction payload, or how this request fits into the unstake lifecycle with prepare_complete_unstake and cancel_expired_unstake. The required 'shares' parameter is also undefined, leaving meaningful gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the required 'shares' parameter. It never mentions shares, amounts, units, or how the value maps to the unstake request. The parameter is only documented by its name and numeric pattern, leaving its meaning to the agent's inference.
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, 'Construct', and names the exact resource: an 'sleUSD unstake-request transaction.' The phrase 'unstake-request' helps distinguish this from sibling tools like prepare_complete_unstake and cancel_expired_unstake, though it does not explicitly name 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?
There is no guidance about when to use this tool versus alternatives. It does not explain that this creates a pending unstake request before completing or canceling it, nor does it contrast with prepare_stake, prepare_complete_unstake, or related tools. Usage must be inferred entirely from the name and the terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's main contribution is specifying the input ('positive oracle answer') and target precision. It adds useful semantic context but does not describe the actual scaling/rounding behavior or output form; with annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant phrases. It is appropriately terse, though the terseness sacrifices critical parameter-level detail that could have been added without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only math function with 2 parameters and strong safety annotations, the description is close but incomplete: the meaning of 'decimals' remains ambiguous, and with no output schema the return format is also unspecified. These gaps are enough to cause an agent to call the tool with the wrong parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must define both parameters. It explains 'answer' as a positive oracle answer but gives no explanation of the 'decimals' parameter, which is essential for understanding how to use the tool. An agent cannot determine whether 'decimals' is the input's current scale, the target scale, or something else.
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 names a specific action ('Normalize'), a specific input class ('positive oracle answer'), and a target format ('8 decimals'), which distinguishes it from the health/liquidation/collateral math siblings. It does not explicitly use the word 'price' from the tool name or contrast itself with lends_math_convert_decimals_exact, so it falls just short of fully differentiating itself.
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 instead of the many sibling math tools, particularly lends_math_convert_decimals_exact which likely performs a related decimal conversion. The description implies it is for normalizing oracle answers but does not state prerequisites, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The word 'construct' implies building an approval payload rather than executing an on-chain transaction, which is useful, but the description does not explicitly state that no transaction is submitted or describe side effects beyond what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler and front-loads the core purpose. It is concise, though slightly too terse to be fully informative on its own.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0% schema coverage and no output schema, the description is too thin. It lacks information about return value, parameter meaning, and when this collateral approval builder should be chosen over the numerous sibling prepare tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining the parameters, but it only references 'collateral' indirectly and says nothing about 'amount'. The patterns in the schema show collateral is an address and amount is a numeric string, but units, token decimals, and the relationship between the parameters are left unexplained.
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 states a specific action ('Construct collateral approval') and scopes it to the LENDS protocol. It is distinguishable from sibling prepare_approve_* tools by the 'collateral' qualifier, though it does not explicitly explain what the approval is for or how it differs from the other approval builders.
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 the many sibling prepare_approve variants, such as approve_leusd_for_repay or approve_usdg_for_psm. The agent must infer from the tool name alone, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds the useful detail that the transaction is permissionless and that the tool constructs a transaction rather than executing one. However, it does not disclose what executing the fee-accrual transaction would actually change or whether any prerequisites exist. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler words. It earns its place by immediately naming the action and the 'permissionless' qualifier. It is concise, though the brevity contributes to the lack of parameter and usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two required parameters, no schema descriptions, and no output schema, the description leaves critical gaps. It does not define the roles of borrower and collateral, mention the return value, or explain what the constructed transaction is used for. Annotations cover safety but not the operational details needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate by explaining the two parameters. It never mentions borrower or collateral, leaving their exact meaning unclear. An agent would not know whether 'collateral' refers to a collateral asset address, a vault identifier, or something else.
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?
States a clear verb and target: 'Construct a permissionless vault fee-accrual transaction.' The permissionless qualifier and fee-accrual target distinguish it from other prepare tools like lends_prepare_borrow or lends_prepare_withdraw. The resource is specific enough for an agent to recognize what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not explain that fee accrual is a maintenance action or when a vault is eligible for it. An agent must infer usage entirely from the tool name and one-sentence description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the useful context that the output contains derived values, not just raw stored collateral. Otherwise it doesn't disclose edge cases, error behavior, or output structure.
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?
One sentence, no filler, and the key purpose is front-loaded. Every word contributes to identifying the operation and result.
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?
For a read-only getter with no output schema, the high-level output semantics are named, but the optional timestamp and the meaning of 'capacity' are left unexplained. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only echoes 'borrower' and 'collateral' at a high level. It doesn't explain the distinction between owner and collateral parameters, nor the optional timestamp's meaning, so it fails to compensate for the empty schema descriptions.
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 ('Read') and names a distinct resource ('a borrower's collateral position') plus the derived outputs (debt, health, capacity). It is clear on its own, though it doesn't explicitly contrast with sibling math tools like lends_math_health_factor or lends_math_liquidation_price.
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 when-to-use guidance or alternatives are given. The description says only what the tool reads; with many math and getter siblings, an agent receives no help choosing this over lends_get_markets or lends_math_health_factor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description does not contradict them and the safety profile is clear. The description adds the core computational intent but does not disclose output format, rounding behavior, or unit conventions. Given the annotations cover side effects, the description provides modest additional transparency.
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 a single, front-loaded sentence with no filler or repetition. It states the action and the object efficiently, which is appropriate for a small math utility.
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 tool is a simple pure function with only two parameters, and the annotations cover side effects, so the completeness bar is moderate. However, with no output schema and no parameter descriptions, an agent is left to infer input semantics and the meaning of the returned value. It is adequate for recognizing the tool's purpose but not fully sufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only alludes to 'leUSD' and 'borrow LTV' without explaining the two parameters directly. It does not clarify that borrowLtvBps is expected in basis points, what 'raw' means, or how the string-integer inputs should be interpreted. The parameter names carry most of the semantic weight here.
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 ('Calculate') and names the resource ('maximum raw leUSD debt') along with the governing input ('borrow LTV'). It is clearly a math helper rather than a state-reading or transaction-preparation tool, and is distinguishable from siblings like lends_math_health_factor by name. However, it does not explicitly contrast itself with other math tools, and the qualifier 'raw' is domain jargon.
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 provided on when to use this tool versus alternatives such as lends_math_collateral_value or lends_prepare_borrow. There are no conditions, prerequisites, or exclusions stated, so an agent must infer usage from the tool name alone. This leaves the selection logic entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict them. However, the description adds no behavioral context beyond those hints, such as whether it returns unsigned transaction data, requires prior token approval, or has any rounding/precision behavior.
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 a single, front-loaded sentence with almost no wasted words. It names the verb, the resource, and the direction clearly, which is appropriately concise for such a focused tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For safe invocation, the description is missing important context: it does not state the return value, whether this builds an unsigned transaction, whether approvals are prerequisites, or when to prefer the swap-in, quote, or approve siblings. The simple schema lowers the bar, but the description still leaves too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never explains leusdAmount. It weakly implies the amount is the leUSD leg of the swap, but it does not specify units, decimals, precision constraints, or how this amount relates to quoting or approval requirements.
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?
States a specific verb and resource: 'Construct an exact leUSD-to-USDG PSM transaction.' The direction leUSD-to-USDG clearly distinguishes it from prepare_psm_swap_in and the quote variants, so an agent can tell what operation this tool performs without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 instead of quote_psm_swap_out, prepare_psm_swap_in, or the approval preparation tools. The intended usage is only implied by the tool name and sibling list; there are no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool constructs a transaction rather than submitting it, and that the request must be claimable. However, it does not describe behavior when the request is not claimable or what the transaction output contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. It is front-loaded with the key action and resource, though adding a bit more context would improve it without sacrificing conciseness.
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?
For a one-parameter prepare tool, the description is minimally adequate, but it does not explain where requestId comes from, what to do with the constructed transaction, or the significance of 'claimable.' Sibling tool names provide some context, but the description alone leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions requestId or how to obtain it. The only meaning comes from the parameter name and the numeric string pattern in the schema, leaving the agent to infer the request ID's source.
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 and resource: 'Construct a transaction to complete a claimable unstake request.' This clearly distinguishes the tool from its request/cancel siblings, though it does not explicitly name them.
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 word 'claimable' implies the tool should be used when an unstake request is ready to be completed, but there is no explicit guidance on when to use this versus request_unstake or cancel_expired_unstake. Usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the read-only safety profile is covered. The description adds that the calculation is constrained by borrow-LTV safety and yields a raw amount, which is useful. However, it does not disclose output units, rounding/flooring behavior, or how price and decimals interact, leaving return behavior ambiguous without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the calculation verb and object while including the key safety constraint. Every word contributes to the intended behavior, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter function with 0% schema description coverage and no output schema, one sentence is not sufficient. The definition omits return format, parameter unit conventions, and edge-case behavior such as zero debt or insufficient collateral. Annotations cover read-only safety, but computational semantics remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names none of the five required parameters. Terms like priceE8, debtLeusd, and borrowLtvBps are left unexplained, so units, scaling, and the meaning of 'raw' are unclear. The description adds no parameter meaning beyond what the parameter names already imply.
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 object: 'Calculate maximum raw collateral withdrawal while retaining borrow-LTV safety.' It clearly identifies the tool's resource and constraint, and it is distinct from sibling tools like lends_math_max_borrow and lends_math_collateral_value. The 'borrow-LTV safety' qualifier makes the intent unmistakable.
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 phrase 'while retaining borrow-LTV safety' implies the tool is for computing a collateral-withdrawal amount under an LTV constraint. However, the description does not explicitly say when to prefer this over related math tools or list any when-not-to-use scenarios. Usage context is implied rather than fully stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to re-establish safety. It adds valuable behavioral context beyond annotations by noting the transaction is 'exact' and that amount 0 revokes approval. This is useful ERC-20-specific behavior not captured in the schema or annotations.
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 a single well-structured sentence that leads with the core action and then adds the critical amount-0 caveat. Every word earns its place, with no filler or repetition of the title.
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?
For a straightforward three-parameter tool with safety annotations, the description covers the core behavior and the amount edge case. It is incomplete, however, because it never explains how this generic tool relates to the multiple specialized approve siblings, which is essential for correct tool selection in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden of explaining token, spender, and amount. It only explains the amount-0 revocation behavior and does not clarify the meaning or relationship of token and spender beyond their self-evident names. This is only partial compensation for the missing schema descriptions.
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 tool constructs an ERC-20 approval transaction, with a specific verb ('construct') and resource ('ERC-20 approval transaction'). It also adds the key semantic that amount 0 revokes approval. However, it does not distinguish this generic approve tool from the many specialized sibling tools like lends_prepare_approve_collateral or lends_prepare_approve_leusd_for_repay.
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?
There is no guidance about when to use this generic approval transaction builder versus the specialized approve siblings. The description does not mention that specialized variants exist or that this tool should be used only for arbitrary token/spender pairs. An agent is left to infer usage from the bare parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful context that this tool constructs a transaction rather than executing one, but it does not disclose return format, whether an approval step is needed, or any other behavioral details.
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 a single, efficient sentence with no filler. The core action and resource are front-loaded, and it earns its place by conveying the tool's purpose clearly without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the constructed transaction looks like or what data is returned; it does not. It also omits parameter semantics and any mention of prerequisites, leaving an agent under-informed for a tool with many similar prepare siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It does not explain that 'collateral' is the collateral asset address or that 'amount' is the leUSD amount to borrow, nor does it clarify units or formatting beyond the bare schema patterns.
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 a specific action ('Construct') and resource ('a leUSD borrowing transaction against collateral'). It distinguishes itself from sibling tools like lends_prepare_deposit or lends_prepare_repay by naming the borrowing 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 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 alternatives such as lends_prepare_deposit or lends_prepare_withdraw. The description implies its use case through the word 'borrowing', but it does not state preconditions, exclusions, or when a sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some behavioral context by framing the operation as constructing a transaction with a minimum output, implying it does not execute the stake. It does not explain the return format or whether prior approvals are required.
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 a single clear sentence with no filler. The key action and the main constraint are both front-loaded and every word earns its place.
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 operation is simple with two scalar parameters and no output schema, but the description omits important context such as the return type, unit conventions, and the relationship to quote_stake or approve tools. An agent could call it correctly but would be guessing about the meaning of the returned transaction object.
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 schema provides 0% description coverage, so the description must compensate. It does help by mapping 'amount' to leUSD and 'minSharesOut' to the minimum sleUSD share output. However, it does not explain units, precision, or how these string values should be interpreted.
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 the specific verb 'Construct' and identifies a concrete resource: a leUSD stake transaction. It adds the key constraint of an 'explicit minimum sleUSD share output', which helps define the tool's role. However, it does not explicitly distinguish this from the similar-looking lends_quote_stake or the approval-prepare siblings.
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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that lends_quote_stake should be used for quote estimation or that approval tools are needed beforehand. Usage context is only implied by the word 'Construct'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The word 'Construct' adds the useful implication that this builds a transaction rather than broadcasting a withdrawal, but the description does not disclose further behavior such as approval requirements or returned payload format.
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 with no redundant words. It names the exact action and resource while remaining highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and annotations cover safety, the description omits essential parameter semantics and does not state what the transaction object looks like or whether an approval step is required first. With no output schema and no parameter details, this is not enough for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what 'collateral' and 'amount' represent, what units amount uses, or how they relate to the withdrawal. The parameter names and regex patterns provide only weak inference, so the description fails to compensate for the missing parameter 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 'Construct' with a clearly scoped resource, 'a collateral withdrawal transaction', which distinguishes it from sibling tools like prepare_deposit, prepare_borrow, and prepare_repay. Its purpose is immediately identifiable without needing to inspect schemas.
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?
The description gives no guidance on when to choose this tool over related prepare tools, nor does it mention prerequisites such as prior collateral approval or checking withdrawable collateral. The agent must infer usage entirely from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds which data is read, but it does not disclose behavior for invalid tokens, non-ERC-20 tokens, or an empty spenders list. This is acceptable given annotations, but not a strong additional 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?
The description is a single, front-loaded sentence with no filler. It states the action and enumerates the returned data efficiently; every word contributes.
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 robust safety annotations and only three simple parameters, the description names all major output categories despite there being no output schema. It is mostly complete, though it leaves the meaning of an empty spenders list and exact return structure implicit.
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?
With schema description coverage at 0%, the description is the main semantic source. It maps 'owner balance' to owner and 'selected allowances' to spenders, providing meaning beyond raw schema types. However, it does not explain spenders defaults, max length, or how an empty spenders list behaves, leaving some invocation details to inference.
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 clear verb ('Read') and a specific resource: ERC-20 metadata, owner balance, total supply, and selected allowances. It differentiates from sibling getters by enumerating token-level data, though it does not name a sibling or explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives among the many get_* and quote_* siblings. The read nature is implied, but there are no selection conditions, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat safety. It adds useful context about the output scale ("raw 6-decimal leUSD"), but says nothing about error behavior, rounding, or calculation assumptions.
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 compact sentence front-loads the verb and key qualifiers, with no redundant words. It is appropriately sized for a simple pure-calculation tool.
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?
For a low-complexity math utility, the one-liner plus annotations cover the safety and output-scale basics. However, with no output schema and no parameter explanations, the exact formula and meaning of priceE8/collateralDecimals remain implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain collateralRaw, collateralDecimals, or priceE8. The phrase "raw 6-decimal" hints at output units, but the agent must infer each parameter's role from its name rather than from documented semantics.
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, "Calculate", and a precise resource, "raw 6-decimal leUSD collateral value." The qualifiers "raw" and "6-decimal" distinguish this from sibling math tools like withdrawable_collateral or health_factor without requiring the agent to open schemas.
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 many math siblings. It does not name alternatives, prerequisites, or exclusions, leaving the agent to infer selection from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat safety guarantees. It adds that this is an exact USDG-to-leUSD prepared transaction, but it does not explain what the constructed transaction contains, whether it is broadcast, or how it should be chained with quote or approve steps.
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 a single, front-loaded sentence with no filler. Every word earns its place, and the direction and exactness are stated immediately.
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?
For a one-parameter tool with safety-oriented annotations, this is minimally viable, but there are clear gaps: no usage conditions, no return/output description, and no indication of how this prepare step relates to quote and approve siblings. The absence of an output schema leaves the agent with less structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter usdgAssets has 0% schema description coverage, and the tool description never explicitly states that this parameter is the exact amount of USDG to swap in or what units are expected. The parameter name and the word 'exact' give only a weak hint, so the description does not fully compensate for the 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 states a specific verb ('Construct') and a specific resource ('an exact USDG-to-leUSD PSM transaction'). The USDG-to-leUSD wording clearly distinguishes it from prepare_psm_swap_out, and 'transaction' distinguishes it from quote_psm_swap_in.
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?
The description gives no guidance about when to use this tool versus alternatives such as quote_psm_swap_in, prepare_psm_swap_out, or the related approve tools. The agent must infer selection criteria entirely from the tool's name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds 'current availability' (time-sensitive result) and 'exact' (precise quote), but it does not disclose failure modes, rounding behavior, or what happens when availability is insufficient. No contradiction with annotations.
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 10-word sentence that front-loads the verb and direction with no filler. Every word contributes to the meaning.
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?
For a one-parameter read-only quote tool, the core behavior is covered, but the missing parameter semantics and unspecified return shape (no output schema) leave an agent with only partial information. It is adequate but has clear gaps in unit and amount interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter usdgAssets is not mentioned in the description despite 0% schema description coverage. The property name and pattern imply a non-negative integer amount of USDG, but units and whether it is the input amount to convert are left unstated, forcing the agent to guess.
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?
States a specific verb ('Quote'), a resource (PSM conversion), and the exact direction (USDG-to-leUSD), which lets an agent distinguish it from the sibling lends_quote_psm_swap_out. 'Current availability' adds scope beyond the generic title, making the purpose unmistakable.
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 sentence explains when to call this tool versus lends_quote_psm_swap_out or lends_prepare_psm_swap_in. There is no mention of prerequisites, ordering relative to prepare tools, or exclusions, so an agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description agrees — calculating is read-only and idempotent, so no contradiction. The description adds genuine value by disclosing the 8-decimal precision and, importantly, the null return when debt or collateral is absent, an edge case an agent must handle.
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?
One sentence with two clauses, front-loaded verb, and zero filler. The computation, the precision, and the null edge case each earn their place, making this appropriately sized and efficient.
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?
For a 4-parameter math tool with no output schema, this is lean: it discloses the key edge case but omits the formula, input units, and output type beyond '8-decimal'. The sibling scale_price_to_e8 hints at an e8 price convention that is never explained, so an agent may still lack the context needed to interpret inputs and results confidently.
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?
With 0% schema description coverage, the description must compensate, and it partially does: it names two key inputs ('debt or collateral') and hints at precision via '8-decimal'. However, it does not clarify liquidationThresholdBps semantics, raw-versus-normalized units, or how collateralDecimals participates in the calculation, leaving the largely self-explanatory parameter names to carry the rest.
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 states a specific computation — 'Calculate the 8-decimal liquidation price' — with a clear verb and resource, plus a distinguishing behavioral trait (null return). It reads distinctly from siblings like lends_math_health_factor or lends_math_max_borrow, though it never names or contrasts them explicitly.
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 when-to-use guidance, no exclusions, and no named alternatives among the 40+ siblings. The null-return clause implicitly warns that the tool needs debt or collateral to produce a result, but there is no scenario guidance distinguishing this from health_factor, collateral_value, or max_borrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses an important edge-case behavior: it returns null when debt is zero. This is useful behavioral context that is not visible in the schema or annotations.
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 a single, compact sentence that front-loads the core purpose and adds a key edge-case note. Every word 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?
For a straightforward 3-parameter math function with no output schema, the description is mostly complete: it states the output scale and the null behavior. However, it does not clarify parameter semantics, so an agent without DeFi domain knowledge may still be uncertain about inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning, units, or relationship of valueLeusd, debtLeusd, or liquidationThresholdBps. The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond them.
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 tool's function: calculating health factor in basis points. It is specific about the resource and unit, though it does not explicitly differentiate itself from the sibling lends_math_* tools.
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 usage: use this tool when you need a health factor calculation. However, it provides no explicit guidance about when to prefer it over alternatives or any exclusions, leaving the agent to infer from the function name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description's 'Construct' aligns with a preparatory, non-mutating action. The description does not add meaningful behavioral detail beyond that, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. The core action and purpose are front-loaded, making it easy to scan.
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?
Given the simple one-parameter schema and strong safety annotations, this is nearly sufficient. The main gap is the absence of amount semantics and any indication of what the constructed approval output looks like, which matters since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the single 'amount' parameter, and the tool description does not explain its units, precision, or whether it is in base leUSD units. The parameter name is self-evident, but the description fails to compensate for the missing schema guidance.
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 names a specific verb and resource: 'Construct leUSD approval.' It narrows the purpose to 'protocol repayment,' which distinguishes it from sibling approval tools such as lends_prepare_approve_leusd_for_psm and lends_prepare_approve_leusd_for_staking.
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 phrase 'for protocol repayment' implies the intended context, giving some usage guidance. However, it does not explicitly state when to choose this tool over the other leUSD approval variants, nor does it mention exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds some value by indicating that the tool constructs a transaction rather than executing or submitting one, but it does not disclose additional behavioral details such as return format or prerequisites.
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 a single, front-loaded sentence with no filler. Every word earns its place, and it is appropriately sized for a simple two-parameter tool whose schema already defines the allowed values.
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?
Given the low complexity (two parameters, no output schema, no nested objects), the description is minimally adequate: it states that the tool constructs a transaction and the schema defines the parameter shapes. However, it omits return-value expectations and leaves parameter semantics implicit, so an agent must infer some invocation details from the names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not: "collateral" and "amount" are left to their names and schema patterns, with no clarification of units, token decimals, or how the amount relates to the collateral asset.
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: "Construct a collateral deposit transaction." It clearly distinguishes this from the many sibling tools (e.g., prepare_withdraw, prepare_borrow) by naming the deposit operation, and there is no ambiguity about what the tool produces.
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 intended use is implied: use this when you need to construct a collateral deposit transaction. However, there is no explicit guidance about when not to use it or which sibling prepare_* tool to choose instead, leaving the agent to infer the selection from names and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that this only constructs a transaction rather than executing one, and clarifies that the amount is a maximum cap. It does not describe the returned transaction object or any required approval step, but the annotation coverage lowers the burden.
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, tightly worded sentence with an active verb and no filler. The important qualifier 'maximum raw amount' is included, making it both concise and information-dense.
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?
For a simple two-parameter tool with safe annotations, the description conveys the core action adequately. Still, an agent is left to infer what collateral refers to semantically, whether prior approval is needed, and what the constructed transaction contains. The lack of an output schema makes the missing return-shape detail more noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain both required parameters. It only adds meaning to maxAmount ('maximum raw amount'), giving units and cap semantics, but it never explains what collateral represents beyond the address pattern in the schema. This under-compensates for the complete lack of schema-level parameter descriptions.
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 ('Construct'), names the exact resource ('leUSD repayment transaction'), and includes a distinguishing detail ('maximum raw amount'). This clearly separates it from sibling prepare tools such as borrow, deposit, withdraw, and stake.
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 is implied: an agent should use this when a leUSD repayment transaction needs to be constructed. However, the description does not mention prerequisites such as an existing debt or approved leUSD allowance, nor does it contrast this with related tools like lends_prepare_approve_leusd_for_repay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description only needs to add non-obvious behavior. It does so by disclosing the floor-rounding mode and contract-equivalent matching, which tells the agent the calculation is a pure simulation with a specific rounding rule.
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 a single front-loaded sentence with no filler. Every phrase ('projected', 'simple vault fees', 'contract-equivalent floor rounding') carries a distinct piece of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and four required math inputs, the description is too thin: it does not explain the return value, the formula, the meaning of the two timestamps, or the units of stabilityFeeAprBps. The annotations cover safety but not the calculation contract an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not define any of the four parameters. The names (debt, stabilityFeeAprBps, lastAccrualTs, timestamp) and pattern are somewhat self-explanatory, but the description adds no explicit meaning, units, formula role, or ordering semantics, leaving a material gap for a calculation tool.
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 ('Calculate') and names a distinct resource ('projected simple vault fees'), plus a defining behavioral detail ('contract-equivalent floor rounding'). This separates it clearly from sibling math tools like health factor or liquidation price by its fee-specific purpose.
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 word 'projected' implies this is for estimating pending/accrued vault fees rather than performing an actual on-chain accrual, giving a rough usage context. However, it never names alternatives (e.g., lends_prepare_accrue_fee) or states explicit when-to-use/when-not-to-use conditions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's main safety message overlaps with them. The description adds the useful framing of 'projected coverage' but does not reveal additional behavioral details like return shape or edge cases.
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 a single tight sentence with no filler. It front-loads the action and resource, then adds the key safety qualifier without redundancy.
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?
With no output schema, the description only vaguely indicates what the tool returns via 'eligibility and projected coverage.' Parameter semantics are also left unexplained, so while the tool is simple and annotations cover safety, an agent would still need to infer input meaning and return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description gives no parameter-level guidance. The names 'owner' and 'collateral' are somewhat self-explanatory, but the description does not clarify whether collateral is an asset address, amount, or something else, leaving an important gap.
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 opens with the specific verb 'Read' and names the exact resource: liquidation eligibility and projected coverage. It also explicitly clarifies that the tool does not execute liquidation, which distinguishes it from execution-oriented siblings.
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 phrase 'without executing liquidation' clearly communicates when this tool is appropriate: as a read-only preflight for liquidation decisions. It does not explicitly name an alternative tool or exclusion, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose the read-only, idempotent, non-destructive nature of the call. The description adds useful context about what is returned, but it does not describe ordering, freshness, external oracle behavior, or whether the list is filtered by protocol state. With annotations carrying the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words. The verb and resource come first, and the output scope is expressed in an economical prepositional phrase.
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 zero-parameter list tool, the description is almost complete: it states the resource and the fields an agent can expect. The absence of an output schema means a bit more detail about the returned shape would help, but this is a minor gap for a simple no-argument read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no parameter documentation burden. The description's reference to 'configured collateral markets' clarifies scope but is not required for parameter semantics; baseline 4 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 names a specific action ('List') and resource ('configured collateral markets'), and specifies the included content ('risk parameters and oracle state'). This clearly differentiates it from sibling tools like lends_get_market, which targets a single market.
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?
The description gives no guidance on when to choose this tool over alternatives such as lends_get_market or lends_get_protocol_state. It does not state explicit use cases or exclusions, so an agent must rely on tool naming alone to pick among the read-only market/protocol tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the description's main job is to add request-specific context. It adds 'one' and 'unsigned request ID' but does not describe return value, not-found behavior, or how the ID relates to other tools. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the action and resource, no filler. Every word contributes meaning.
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 single-parameter read tool with strong safety annotations, 'Read one ... by unsigned request ID' conveys the essential call shape and purpose. It is less complete than it could be because there is no output schema and no description of the returned request data, but the low complexity keeps the gap small.
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?
With 0% schema description coverage, the description must explain the parameter, and it does identify the requestId semantically as an 'unsigned request ID,' matching the non-negative integer pattern. However, it does not clarify where the ID comes from or distinguish 'unsigned' from 'signed' request contexts, leaving some ambiguity.
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 specifies a concrete action ('Read one ... request') and a precise resource ('sleUSD unstake request'), with the qualifier 'unsigned request ID.' It is more specific than the tool name alone and clearly separates this read operation from the prepare_* and math siblings.
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 verb 'Read' implies the tool is for inspecting a single unstake request, but the description does not state when to prefer it over alternatives such as prepare_complete_unstake or prepare_cancel_expired_unstake. No explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that this is a construction ('Construct') rather than an execution, which aligns with readOnlyHint and idempotentHint. It does not add further behavioral detail such as what the constructed value is or what authorization it grants, so it stops at adequate.
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 six-word sentence that front-loads the purpose and contains no filler. Every word earns its place.
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?
For a one-parameter prepare tool with read-only annotations, this is nearly adequate, but it omits the relationship to lends_prepare_stake (whether this must be called first) and does not state what the constructed approval looks like or how amount is denominated. These are not fatal given the simple input, but they are real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the amount parameter or its units; an agent cannot determine whether amount is human-readable leUSD or raw base units, only that it must be a non-negative integer. The token label in the tool name implies leUSD, but that is inference, not 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 pairs a specific verb ('Construct') with a concrete resource ('leUSD approval') and scopes it to 'sleUSD staking,' which distinguishes it from sibling approval tools such as lends_prepare_approve_leusd_for_repay and lends_prepare_approve_leusd_for_psm.
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 situates the tool in the staking flow rather than repay or PSM flows, so an agent can infer when it applies. It does not explicitly name alternatives or state a when-not condition, but the purpose phrase is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds that this constructs rather than executes an approval, but it does not disclose output shape or other behavioral details. No contradiction with annotations.
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 with no filler. It states the action and the purpose immediately and packs the necessary differentiating context into very few words.
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?
For a one-parameter prepare tool with strong safety annotations, the core action is clear and concise. However, the required 'amount' parameter is unexplained in both the schema and the description, and no return value is described, leaving a small but real gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the 'amount' parameter. The meaning is only weakly inferable from 'USDG approval', leaving units, decimal handling, and whether this is an exact or max allowance undocumented.
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 ('Construct'), identifies the asset ('USDG'), and gives the purpose ('for a PSM swap into leUSD'). It clearly distinguishes this from sibling tools like lends_prepare_approve_leusd_for_psm by naming both the token and the swap direction.
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 phrase 'for a PSM swap into leUSD' gives clear context on when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, so the agent must infer the exclusion of the leUSD approval siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds that the output depends on current pool state, signaling the quote is time-sensitive and may not be a guaranteed final rate. No contradiction with annotations.
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 12-word sentence with the key action and resource front-loaded. No filler, no redundant restatement of the tool name, and every word contributes meaning.
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?
For a one-parameter read-only quote with no output schema, it states what is returned ('sleUSD shares') and the input semantics. It stops short of describing the output shape or precision, which would matter more because no output schema exists.
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 0%, so the description must carry parameter semantics. It identifies amount as a 'raw leUSD amount', which clarifies the input is a base-unit quantity rather than a display amount, though it does not specify decimal precision or rounding behavior.
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?
States a specific verb ('Preview'), a specific resource ('sleUSD shares'), and the conversion basis ('raw leUSD amount using current pool state'). This clearly distinguishes it from mutation siblings like lends_prepare_stake and state reads like lends_get_staking_state.
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 word 'Preview' and reference to 'current pool state' imply it is the quote/read path before staking, but the description never names an alternative or says when not to use it. It does not explicitly route to lends_prepare_stake for execution, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, and non-destructive signals. The description adds operation-specific behavior: returning null when downscaling is inexact, which is non-obvious and important. It does not detail exact return value format or edge cases, but substantial behavioral context is provided.
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 a single, front-loaded sentence with no filler. It conveys the action, the resource, and the key behavioral condition without redundancy.
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 math utility with strong annotations, the description covers the core units and result behavior. The absence of an output schema is partially mitigated by stating the null condition, though the exact success return type and usage guidance remain implied rather than explicit.
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 0%, so the description must help interpret parameters. 'Raw units between decimal scales' contextualizes amount as raw units and from/toDecimals as scales, but it does not document each parameter individually. Self-explanatory parameter names and schema constraints compensate for much of this gap.
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?
States a specific operation: converting raw units between decimal scales, with an exactness condition. The phrase 'returning null if downscaling is inexact' clearly distinguishes it from non-exact or approximate conversion tools.
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 is implied rather than explicit: an agent can infer to use this when exact decimal-scale conversion is needed. However, no alternatives are named and no when-not-to-use guidance is given, leaving comparison with sibling tools like lends_math_scale_price_to_e8 to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
'Construct' conveys that this prepares data rather than executing an on-chain change, and the annotations (readOnlyHint, idempotentHint, destructiveHint=false) reinforce the safe, non-mutating nature. It adds the specific asset and workflow context, though it does not describe the returned transaction shape or approval mechanics.
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?
One short sentence, front-loaded with the key verb and resource, with no filler or redundant restatement of the title.
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?
With one simple parameter and safety-carrying annotations, the description is mostly sufficient for selection, and it identifies the asset, spender context, and direction. However, it lacks amount scale and any description of the return value/output shape, and there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'amount' parameter, and the description never mentions amount, its units/decimals, or whether it is the raw leUSD allowance amount. The name and context imply amount is the leUSD amount to approve, but the agent must guess the scale.
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 names a specific verb ('Construct'), a specific resource ('leUSD approval'), and an exact context ('PSM swap out to USDG'). This clearly differentiates it from siblings like lends_prepare_approve_usdg_for_psm and lends_prepare_approve_leusd_for_repay.
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 gives clear context for when the tool is relevant: preparing leUSD approval as part of a PSM swap out to USDG. It does not explicitly name alternatives or state when not to use it, which is the only reason it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the quote is 'exact' and reflects 'current availability', which is useful, but it does not go beyond that into return shape or potential edge cases.
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?
One short, front-loaded sentence with no filler. It packs the verb, resource, direction, and key output quality ('exact', 'current availability') into minimal words.
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, one-parameter quote tool, the description is largely sufficient, especially with annotations covering safety and idempotency. There is no output schema, and the description gives a high-level sense of the return ('exact conversion and current availability') but not a precise return structure.
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?
With 0% schema description coverage, the description should explain the leusdAmount parameter, but it only implies it through 'leUSD-to-USDG PSM conversion'. The name and pattern are self-explanatory to a degree, but units, precision, and how the amount feeds the quote are not addressed.
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 ('Quote') and a specific resource ('leUSD-to-USDG PSM conversion'), and it names the direction explicitly, which distinguishes it from lends_quote_psm_swap_in and the prepare_psm_swap_* tools. It also states what the caller gets back: an exact conversion and current availability.
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 directionality 'leUSD-to-USDG' makes it clear this is the swap-out quote rather than the swap-in quote, providing clear context for selection. It does not explicitly name alternatives or state exclusions, but the purpose is specific enough to route an agent correctly among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile with readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value beyond those annotations by promising a block-consistent snapshot and noting the state is public, which clarifies consistency behavior and access expectations. No contradiction with annotations.
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 a single, tightly written sentence with no filler. The read verb is front-loaded, and each qualifier ('block-consistent', 'public', 'protocol and PSM state') contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with rich annotations covering safety and external-world behavior, the description is complete enough to invoke correctly. The absence of an output schema is not a significant gap because the description and title sufficiently indicate what is being read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description carries no parameter-documentation burden. The baseline of 4 applies, and the description's mention of 'block-consistent snapshot' also clarifies the nature of the result the agent should expect from a no-argument call.
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 ('Read') plus a clear resource ('public LENDS protocol and PSM state') and a distinctive qualifier ('block-consistent snapshot'). This clearly distinguishes it from narrower sibling getters such as lends_get_markets, lends_get_position, and lends_get_staking_state.
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?
The description provides no guidance on when to use this aggregate state getter versus the many specific getters in the sibling list. There are no explicit use-case conditions, exclusions, or alternatives mentioned, so an agent must infer the intended context from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the key behavioral fact that this is a transaction preparation step, not an execution step, and clarifies the purpose as recovering shares. This complements the annotations without contradicting them.
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 a single focused sentence with no filler. The intent is front-loaded ('Construct a transaction') and the purpose is immediately clear. Every word 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?
For a one-parameter prepare tool with rich annotations and no output schema, the description covers the core domain, the transaction-constructing behavior, and the scenario (expired unstake). It does not define 'expired' or describe the returned transaction's shape, but the sibling context and schema make the tool usable without that detail.
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?
With 0% schema description coverage, the description should compensate for the undocumented requestId. It indirectly indicates that requestId refers to the expired unstake request, but it does not explicitly describe the parameter or its semantics. The single parameter is simple and inferable, but the description does not fully compensate for the 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 clearly states the action ('Construct a transaction') and the specific purpose ('recover shares from an expired unstake request'). The word 'expired' distinguishes it from siblings like prepare_complete_unstake, so an agent can tell which operation this is without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it should be used for an expired unstake request where shares need to be recovered. It does not explicitly name alternatives or say when not to use it, but the 'expired' condition is a strong enough signal for typical selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the token-address lookup scoping but does not disclose additional behavioral details such as behavior for unknown markets or return contents; this is consistent with the annotations, not contradictory.
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 concise sentence contains the verb, resource, and identifying key with zero fluff. Every word earns its place and the core information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter), the read-only/idempotent annotations, and the clear 'read one market by token address' statement, nothing needed to invoke the tool correctly is missing. The absence of an output schema is acceptable because the purpose of a getter sufficiently implies the return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly identifies the 'collateral' parameter as a token address, which adds semantic meaning beyond the raw regex pattern and property name. It does not exhaustively explain market semantics, but for a single-parameter read tool this is sufficient.
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 ('Read'), a singular resource ('one collateral market'), and the lookup key ('by token address'). This clearly distinguishes it from the plural sibling lends_get_markets, so an agent can tell them apart without inspecting schemas.
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 makes the selection context clear: use this tool when you need a single collateral market identified by a token address. It does not explicitly name lends_get_markets as the alternative for reading all markets, so it falls short of a full when/when-not statement, but the singular scope provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful context by specifying exactly what condition is verified—the chain served by LENDS_RPC_URL—going beyond the generic safety hints without contradicting them.
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 conveys the complete action and object with zero wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with rich annotations, the description is complete enough for an agent to select and invoke it correctly. It names the environment variable and the exact assertion being made; no output schema exists, but 'Verify' adequately signals a pass/fail or assertion-style result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds useful context by referencing the LENDS_RPC_URL environment variable, even though no function parameters exist.
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 the specific verb 'Verify' and names the exact resource—'LENDS_RPC_URL serves the configured deployment chain.' This clearly distinguishes it from the many get/prepare/math/quote siblings, which all perform different operations.
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 makes clear when to use this tool: when checking that the RPC endpoint matches the expected deployment chain. It does not explicitly state when not to use it or name alternatives, but given the zero-parameter signature and unique assert role among siblings, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds value by specifying exactly what is read: pool, capacity, cooldown, claim, and vesting state. No contradiction with annotations.
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 sentence with no filler, front-loading the verb and the resource. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only getter, the description is complete: it names the domain (staking), the asset (sleUSD), and the specific state components returned. No output schema is present, but the listed state categories are sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so parameter semantics are vacuous. The baseline of 4 applies; the description correctly focuses on the output state rather than inputs.
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 the specific verb 'Read' and names the exact resource: 'public sleUSD pool, capacity, cooldown, claim, and vesting state.' This clearly distinguishes it from sibling getters like lends_get_protocol_state or lends_get_unstake_request.
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?
'Read public...' gives clear context that this is a read-only getter for staking-related state, with no exclusions mentioned. It does not explicitly name alternatives, but the tool name and resource scope make the intended use obvious among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

lends-mcp-server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![lends-mcp-server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/LendsProtocol/lends-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/LendsProtocol/lends-mcp-server)

Score Badge

Copy to your README.md:

[![lends-mcp-server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/LendsProtocol/lends-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/LendsProtocol/lends-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LendsProtocol/lends-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server