mcp-server-justlend

Official

by justlend

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.1.2
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap among approve tools (five different approve functions) and get tools (e.g., get_moolah_market vs get_moolah_markets). Descriptions help differentiate, but the large number of tools increases potential confusion.
Naming Consistency5/5
Tool names follow a consistent snake_case pattern with verb_noun structure (e.g., approve_underlying, get_account_summary, supply, borrow). Minor variations like cast_vote and stake_trx_to_strx are still in the same style, making the convention predictable.
Tool Count2/5
With 96 tools, the server is over-scoped. While the domain is broad (lending, staking, governance, energy rental), this many tools make the surface cluttered and harder to navigate. A more focused set (e.g., 20-30) would improve coherence.
Completeness4/5
The tool set covers V1 lending, V2 Moolah, staking, governance, and energy rental comprehensively, with CRUD operations for most features. Minor gaps exist (e.g., no proposal creation tool), but core workflows are supported.
Average 4.2/5 across 96 of 96 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 39 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds that it returns historical events but does not disclose pagination behavior, response format, or whether filters are cumulative. The description adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is well-structured and immediately conveys the core purpose.
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 tool with six optional parameters and no output schema, the description is minimal. It does not explain pagination via page/pageSize, nor does it mention that the tool is read-only (though annotations cover that). The description could be more complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have descriptions. The tool description does not add additional meaning, e.g., it does not clarify that the 'type' parameter corresponds to the two types mentioned in the description. Baseline score of 3 is appropriate.
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 retrieves historical liquidation events on Moolah, specifying both bot-executed and public liquidations. However, it does not differentiate from sibling tool 'get_liquidation_records', which may refer to a different protocol or context.
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 'get_moolah_pending_liquidations' or 'get_liquidation_records'. The description lacks any when-to-use or when-not-to-use instructions.
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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond these annotations, but does not contradict them.
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 sentence that is clear and efficient. It could be slightly more structured (e.g., mention return value) but remains concise.
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?
No output schema is provided, and the description does not specify the return type or format. For a simple query tool, this is a moderate gap; the description implies a numeric value but could be more 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 coverage is 100% with parameter descriptions. The description does not add additional meaning beyond what is in the schema (e.g., defaults or constraints).
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 explicitly states the tool retrieves the number of locked votes for a user and a proposal, using a specific verb and resource. It clearly distinguishes from sibling tools like cast_vote and withdraw_votes_from_proposal.
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 on when to use this tool versus alternatives (e.g., get_vote_info, get_vote_records). The description does not specify prerequisites or context for invocation.
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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not reiterate safety. It adds value by specifying return types (position history and transaction records) but omits details like pagination or performance characteristics.
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 sentence that is front-loaded with the action and result. It is concise, but it could be slightly more efficient by removing redundant phrasing (e.g., 'position history' and 'transaction records' are clear).
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 three optional parameters and no output schema, the description adequately explains what the tool returns but does not detail the structure of the response. Given the lack of output schema, more information on the return format would improve completeness, but the description meets minimal expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three optional parameters. The description does not add any additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 retrieves a user's JustLend V2 position history and recent transaction records, using a specific verb ('Get') and resource ('history'). However, it does not explicitly differentiate from siblings like 'get_moolah_records' or 'get_moolah_user_position', which may overlap.
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 it is for historical data but provides no explicit guidance on when to use this tool versus alternatives. There are many similar 'get_*' tools, and the description lacks usage context, exclusions, or prerequisites.
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, openWorldHint, idempotentHint, and destructiveHint. The description adds value by listing returned data fields, but no further behavioral traits (e.g., performance, rate limiting) are disclosed.
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?
Single sentence, front-loaded with purpose, lists examples efficiently. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 optional param, no output schema, rich annotations), the description is fairly complete, naming key outputs. Could mention network parameter effect or output format for full completeness.
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?
Input schema has 100% coverage with one parameter (network) described. The description does not enhance parameter meaning beyond the schema's 'Network. Default: mainnet'.
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 it retrieves dashboard data for JustLend energy rental market, listing specific metrics. It distinguishes from siblings like get_energy_rental_params and get_energy_rental_rate by the 'dashboard' scope, but does not explicitly contrast 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the 'dashboard' scope versus more specific sibling tools, but no explicit when-to-use or when-not-to-use guidance is provided.
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 declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds specific behavioral details: it shows staked amount, claimable rewards, rounds, and withdrawal status, which clarifies what data the tool returns. No contradictions 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 concise sentence that efficiently communicates purpose and output. It is front-loaded with the main action and resource. A slight improvement could be listing outputs more explicitly, but it is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional params, no output schema), the description adequately covers what it does and what it returns. However, it does not elaborate on conditions for withdrawal eligibility (e.g., whether unbonding period has passed) or reinforce read-only nature, but it is sufficient for a simple check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both address and network parameters documented. The description does not add per-parameter details beyond the schema, but it indirectly provides context by explaining the tool's purpose. Baseline 3 is appropriate as the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the specific resource 'TRX available to withdraw after sTRX unstaking unbonding period'. It also lists key data shown: staked amount, claimable rewards, pending/completed unstake rounds, withdrawal status. This distinguishes it from sibling tools like get_strx_balance or get_strx_account, which are more general.
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 does not provide explicit guidance on when to use this tool versus alternatives. It implies the context of checking after unbonding period but fails to mention exclusions or alternative tools (e.g., get_strx_records) that might be more appropriate for other queries.
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 indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds cost information not in annotations, but does not disclose edge cases like no rewards, network-specific behavior, or transaction confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second adds cost detail. No redundant information, front-loaded, and efficient. Every sentence 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 description covers the main action and cost but lacks details on return value, transaction behavior, or error handling. For a simple write operation with no output schema, it is minimally adequate but could provide more context.
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?
There is one optional parameter (network) with 100% schema coverage. The description does not add any additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Claim'), resource ('accrued JustLend mining rewards'), and scope ('for the configured wallet'). It distinguishes from siblings like 'claim_strx_rewards' and 'claim_moolah_mining_period' by specifying the reward type and protocol.
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 mentions the typical cost but does not provide explicit guidance on when to use this tool versus alternatives. It implies usage when claiming JustLend rewards, but lacks 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=true and destructiveHint=false, establishing it as a safe read. The description adds the behavioral detail that the effective rate is the max of both rates. However, it does not disclose the default network (mainnet) or that trxAmount=0 gives base rate, which are present in the schema but not the description.
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?
Two sentences with no wasted words. The first sentence states purpose, the second describes output. Concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return values (rental rate, stable rate, effective rate). It covers the primary input and basic output. Missing a mention of the network parameter, but it has a default. Adequate for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description merely restates 'for a given TRX amount' without adding new semantics or format details. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('energy rental rate'), and the input ('given TRX amount'). It also lists the returned values (rental rate, stable rate, effective rate), which distinguishes it from sibling tools like get_energy_rental_params or get_energy_rental_records.
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 for querying rates, but provides no explicit guidance on when to use this tool versus alternatives such as get_energy_rental_dashboard or get_energy_rental_params. No when-not or alternative tool mentions.
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. The description adds that the tool returns proposals sorted by newest first, but does not mention any additional behavioral traits beyond what annotations provide. No contradiction.
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 three concise sentences, front-loaded with the main purpose, and contains no redundant or irrelevant information. Every sentence adds value.
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?
While the description outlines the kind of data returned (status, vote counts, details), it lacks specifics such as field names, structure, or pagination behavior. Given no output schema exists, more detail would improve completeness. Annotations cover safety aspects.
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?
Input schema coverage is 100% with descriptions for both parameters (limit and network). The tool description does not add any additional meaning beyond the schema's parameter descriptions, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'list of JustLend DAO governance proposals', and specifies what is returned (status, vote counts, details) and ordering (newest first). It distinguishes from sibling tools with different purposes.
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 does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. However, the purpose is straightforward and there are no close sibling tools competing for the same task, so the usage is implicitly clear.
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 indicate destructiveHint=true and readOnlyHint=false. The description adds the pre-check behavior, but does not elaborate on other side effects or state changes beyond what 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two front-loaded sentences, no unnecessary words, and clearly communicates the purpose and a key behavioral aspect.
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 tool with one optional parameter and no output schema, the description covers the purpose and pre-check behavior. Schema covers the parameter, so it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'network' parameter. The description does not add any additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Claim all available sTRX staking rewards' using a specific verb and resource. It distinguishes from sibling tools like 'claim_rewards' by specifying sTRX 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 description mentions a pre-check for claimable rewards, implying safe usage, but does not explicitly state when to use this tool versus alternatives like 'get_claimable_rewards' or when not to use it.
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 openWorldHint=true, so description's main value is listing return fields. However, it does not disclose error handling (e.g., if pair does not exist) or additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with 22 words, front-loaded with action, no redundant information. Every word is necessary.
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 tool with 3 parameters and no output schema, the description lists three key return fields (security deposit, rent balance, active rental). This is sufficient for agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. Description adds no extra meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and clearly identifies resource: on-chain energy rental info for a specific renter-receiver pair. It distinguishes from siblings like get_energy_rental_dashboard (overall view) and get_energy_rental_records (list all).
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 for a specific pair but does not explicitly state when to use this tool versus alternatives like get_energy_rental_dashboard. No exclusions or alternative tool names are 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds minor behavioral context (address defaults to configured wallet), but does not disclose error handling or additional constraints. With strong annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes all essential details without waste. Every part 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?
Given no output schema, the description lists the key return fields (APY, TVL, allocation, share balance). It is mostly complete for a single-vault detail tool, though it could mention additional fields like vault address or underlying asset. Annotations provide safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all three parameters. The description reinforces vaultSymbol values and the address's purpose, but adds minimal new information beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed info for a single Moolah vault, specifies the fields (APY, TVL, allocation, share balance), and lists allowed vaultSymbol values. It distinguishes this from sibling tools like get_moolah_vaults (plural) and get_moolah_vault_history.
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 for retrieving vault details, but does not explicitly state when to use this tool versus alternatives (e.g., get_moolah_vaults for all vaults). It mentions the optional address for share balance, but no exclusion or context for when not to use.
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, etc., so the description adds context about vault type (ERC4626) and yield mechanism but does not contradict annotations. Additional behavioral details (e.g., response shape, rate limits) are absent but not critical given 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?
Two sentences, front-loaded with core functionality and data fields. No redundant text or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple list operation with optional parameters and no output schema, the description is largely complete. It explains the vault type and yield purpose. Minor omissions: no mention of pagination or response structure, but acceptable for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters (network, depositToken). The tool description adds no extra detail beyond what the schema provides, such as default values or filter behavior. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all JustLend V2 (Moolah) vaults with specific data fields (APY, TVL, underlying token). It also distinguishes from sibling tools like 'get_moolah_vault' by indicating 'list all' and providing context about ERC4626 vaults.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., 'get_moolah_vault', 'get_moolah_vault_history'). The description implies it's for a broad overview, but no exclusions or when-not-to-use advice.
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 indicate readOnlyHint=true and no destructive effects. The description adds no new behavioral context beyond what annotations provide, e.g., no mention of default address behavior or network fallback.
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 concise sentence with no extraneous words, efficiently conveying the tool's purpose.
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 good annotations, the description is adequate but could mention return value format. Overall, it sufficiently covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add meaningful information beyond the schema. The phrase 'for an address' aligns with the address parameter but offers no additional detail.
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 ('Get'), the resource ('sTRX token balance'), and the scope ('for an address'), distinguishing it from sibling tools like get_trx_balance and get_token_balance.
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?
No guidance on when to use this tool versus alternatives (e.g., get_trx_balance, get_wallet_balances). The usage context is implied but not explicit, lacking exclusions or recommendations.
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, destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral traits beyond stating what data is returned, which is already known from 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?
Two sentences concisely convey the tool's purpose and use case. No redundant information; front-loaded with what it does and ends with usage advice.
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?
Lists four specific return values (JST balance, available votes, total deposited, cast votes) which covers the main outputs. No output schema exists, but the description provides sufficient detail for a read-only info tool. Could mention pagination or rate limits, but not essential.
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 covers both parameters with descriptions (address: TRON address default configured wallet; network: Network default mainnet). Description does not add extra parameter information beyond the schema, so baseline score is appropriate.
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 retrieves voting power info including JST balance, available votes, deposited votes, and cast votes. It positions itself as the key tool to check before voting, distinguishing it from siblings like get_user_vote_status but not explicitly naming alternatives.
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?
Explicitly says 'This is the key tool to check before voting' providing clear when-to-use advice. Does not mention when not to use or provide alternatives, but 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (mutation) and readOnlyHint=false. The description adds one behavioral trait ('No approval needed'), which is helpful but does not cover other aspects like side effects, success conditions, or error handling. It adds value beyond annotations, but not extensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no wasted words. The key tip about 'max' is included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema; the description covers the core functionality and a key usage tip. It relies on the schema for parameter details (vaultSymbol, network) and annotations for safety profile, which is acceptable. A brief note on side effects (e.g., vault balance update) would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage), so the description adds no new parameter-specific semantics beyond reinforcing the 'max' usage. The baseline is 3, and no additional value is provided.
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 that the tool withdraws underlying assets from a Moolah vault, specifying the action (withdraw), resource (Moolah vault), and the asset type (underlying assets). It also highlights the special value 'max' for full withdrawal, which distinguishes it from sibling tools like moolah_vault_deposit.
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 mentions 'No approval needed,' which is a useful precondition, but it does not explicitly guide when to use this tool over alternatives like withdraw_all or moolah_vault_redeem. Given the many sibling tools, clearer usage differentiation would improve the score.
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 declare non-read-only and non-destructive behavior. The description adds valuable behavioral context: it checks balance sufficiency (including gas) before sending and provides typical cost (~0 energy + ~270 bandwidth). This goes beyond annotations and helps the agent understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The purpose is front-loaded, and each sentence adds distinct value: purpose, safety check, and cost estimate. Perfectly concise.
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 transfer tool with no output schema, the description covers purpose, safety check, and cost. It lacks detail on error handling (e.g., insufficient balance response) or return value format, but the annotations and schema fill most gaps. Slightly incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add additional meaning for parameters beyond the schema's patterns and descriptions. No extra guidance on parameter values or formats.
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 'Transfer TRX to another TRON address', specifying the verb (transfer), resource (TRX), and action scope. The sibling tool 'transfer_trc20' handles TRC20 tokens, so this description implicitly distinguishes by focusing on TRX.
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 explicit guidance on when to use this tool versus alternatives. It mentions balance checking and cost but does not state when to use transfer_trc20 or other transfer methods, nor does it describe exclusions or prerequisites.
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, openWorldHint=true, and destructiveHint=false, clearly indicating safe, non-destructive behavior. The description adds that the tool works on both mainnet and nile, and implies paginated behavior. This adds some context beyond annotations but does not discuss rate limits, result ordering, or empty result behavior, so a score of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence clearly states the core purpose and event types. The second sentence provides a critical sibling distinction. No unnecessary words, front-loaded with essential information.
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 lack of an output schema, the description does not describe the return format or fields of the transaction records. The parameter list is fully covered by the schema, but the agent receives no information about what data is returned per record. This gap reduces completeness. A score of 3 is appropriate for a simple list tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions in the JSON schema. The description mentions 'paginated' which aligns with pageNo and pageSize, but adds no new semantic detail beyond what the schema already provides. Baseline 3 is correct as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving a user's paginated V2 Moolah transaction history for specific event types. It explicitly distinguishes from the sibling tool get_moolah_history by contrasting its full record list vs. position curves with a preview, which helps the agent select the correct tool.
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 direct usage guidance by comparing to get_moolah_history, stating when to use this tool (full paginated records) and when to use the alternative (position curves + preview). It also mentions compatibility with mainnet and nile. However, it does not address other potentially related tools like get_lending_records or get_liquidation_records, slightly limiting completeness.
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, destructiveHint=false, so the agent knows this is a safe read operation. Description adds no behavioral context beyond listing output fields; it doesn't disclose rate limits, auth needs, or other traits. 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?
Single sentence with clear verb and list of included fields. No fluff or redundant 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?
Despite no output schema, the description fully enumerates the key fields returned (staked amount, income, claimable rewards, withdrawn amount, rental energy amount). For a read-only tool with good annotations, this is sufficient for an AI agent to understand what it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters (address, network) have descriptions covering pattern, default, and optionality. The description adds no extra parameter meaning beyond listing output fields, so it meets baseline but does not exceed.
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?
Description clearly states it retrieves sTRX staking account info and enumerates specific fields (staked amount, income, claimable rewards, withdrawn amount, rental energy amount). This distinguishes it from siblings like get_strx_balance (balance only) and get_strx_dashboard (likely dashboard summary).
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies use for detailed staking account info, but with many related sibling tools, some differentiation would help agents choose correctly.
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 false. The description adds context about pagination, mainnet constraint, and the structure of returned records (actionType range, fields), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. The first sentence immediately conveys the core purpose, and the second provides essential details about pagination and response fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return fields (actionType, actionName, token, amount, USD value, txId) and mentions pagination. However, it omits details on pagination behavior (e.g., default page size, max pages) and error conditions, but overall sufficient for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add new parameter semantics beyond what the schema already provides; it only lists record fields in the response, not parameter details.
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 it retrieves a user's V1 JustLend transaction history, enumerates specific action types (supply, withdraw, borrow, repay, collateral enable/disable), and distinguishes itself from sibling tools like get_moolah_records by specifying the protocol and version.
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?
While it indicates the tool is Mainnet-only, it does not provide explicit guidance on when to use this tool versus alternatives such as get_moolah_records or get_liquidation_records. The description lacks when-not and alternative recommendations.
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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds scope details ('top' vaults/markets, optional user position) but does not provide significant additional behavioral context beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no unnecessary words. Every sentence adds critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does a good job listing the key fields returned (APY, TVL, borrow/supply rates, position details). However, it does not clarify what 'top' means (e.g., by TVL or APY), leaving a minor gap for the agent.
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 coverage is 100% with each parameter described. The description adds value by explaining that the user address triggers inclusion of an aggregated V2 position with specific fields (total supply, borrow, health factor), which is not fully captured in the schema 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 clearly states the tool provides a protocol overview of JustLend V2, including top vaults (APY, TVL) and top markets (borrow/supply rates), and optionally the user's aggregated position. It distinguishes itself from siblings like get_moolah_vaults and get_moolah_markets by offering a composite dashboard.
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 use for a quick overview but does not explicitly state when to use this tool versus calling individual endpoints. It lacks guidance on when not to use it or alternatives, leaving the agent to infer usage from context.
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 safe, read-only behavior. The description adds valuable context about the returned metrics (APY, LLTV, etc.) and the isolated nature of markets, going beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose and key data, second explains isolation. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the data returned and the unique isolation feature. It omits explicit mention of defaults (e.g., network defaults to mainnet, page size defaults to 20) but the schema descriptions cover those. For a simple list tool with good annotations, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each parameter already has a description. The tool description does not add additional parameter-level details beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'JustLend V2 (Moolah) markets', and the specific data fields (borrow/supply APY, LLTV, utilization, liquidity). It also notes the distinctive isolation property, helping differentiate from siblings like get_moolah_market.
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 for listing markets with optional filters (network, pageSize, depositToken, collateralToken) but does not explicitly state when to use this tool versus alternatives or provide exclusionary guidance.
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, destructiveHint=false, confirming safe read. The description adds the behavioral insight that a risk ratio close to 1.0 indicates near liquidation, which goes beyond annotations. However, it does not disclose other traits like default parameter behavior or response 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?
The description is a single sentence followed by a short actionable note. It is front-loaded with the purpose, no redundant words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 3 parameters fully documented in the schema and clear annotations, the description completes the context by listing output fields and risk interpretation. It could mention default values for address and network, but those are present in the schema, so overall it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (address, network, marketId). The description does not add parameter-specific details beyond what the schema provides, resulting in a baseline score of 3.
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 the verb 'Get', the resource 'user's position in a specific Moolah market', and lists the fields (collateral, borrow amount, lltv, risk ratio). It distinguishes from sibling tools like 'get_moolah_market' by focusing on a single user's position and risk status.
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 explains when to use the tool: to check a position's risk ratio and consider repaying or adding collateral if near liquidation. It implicitly tells when not to use (e.g., for market-wide data), but lacks explicit exclusion 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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description's burden is reduced. The description adds the return fields (currentSupplyUsd, supplyBaseApy, supplyMiningApy, historyRecords) but does not disclose behavioral traits like pagination, time range, or rate limits. It adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words. It efficiently states the purpose, lists return fields, and provides input sourcing guidance. It is front-loaded and every sentence serves a distinct purpose.
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?
The tool has no output schema and returns a structured historyRecords array, yet the description does not explain the array's contents (e.g., fields, time format). The optional network parameter is mentioned in the schema but not in the description. While safety is annotated, return structure details are incomplete for a data retrieval 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 covers both parameters with descriptions (100% coverage). The description adds further meaning by specifying that vaultAddress should come from get_moolah_vaults or chains.ts, which is valuable context beyond the schema. This extra guidance justifies a score above baseline.
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 explicitly states the tool returns a 'time series of a V2 Moolah vault's APY, TVL, and supply mining data,' listing specific fields. It clearly distinguishes from sibling tools like get_moolah_history (likely for markets) and get_moolah_vault (single snapshot) by specifying 'time series' and the exact return data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on where to obtain the vaultAddress (from get_moolah_vaults or chains.ts), which is a key input. However, it does not explicitly state when not to use this tool versus alternatives, such as get_moolah_vault_mining_apy for only APY data. The guidance is helpful but lacks exclusion criteria.
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 readOnly, idempotent, and non-destructive. The description adds value by explaining the return format (fraction encoding) and the meaning of the `enabled` flag for the UI hint. This enriches the understanding without contradicting 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 two sentences, front-loaded with the purpose, and every part adds value. No unnecessary 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 tool with one required param and no output schema, the description covers return values and the enabled flag. It lacks mention of network default behavior or update frequency, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter context beyond the schema, such as explaining the `network` default or providing examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets V2 mining APY for a single Moolah vault, and specifies the return values (USDD/TRX split and total). It distinguishes from sibling tools like `get_moolah_vault` by targeting a specific metric.
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 for retrieving mining APY of a single vault, but does not explicitly mention when to use this vs. alternatives like `get_moolah_vault` or `get_mining_rewards`. No when-not-to-use guidance is provided.
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 non-destructive. The description adds transparency about pagination and network restriction, going beyond the structured 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, well-structured sentence that front-loads the core action and lists record types. It is efficient, though adding line breaks could improve readability.
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 lack of output schema, the description provides partial context by mentioning opType and opName, but it does not fully describe the paginated response structure or complete list of return fields, leaving room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description mentions pagination but does not add new parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a user's sTRX staking history, enumerating specific record types (stake, unstake, withdraw, transfers) and distinguishing itself from sibling tools like get_strx_balance or get_strx_account by focusing on historical records.
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?
Explicitly notes the tool is Mainnet-only, providing a clear usage constraint. However, it does not explicitly contrast with alternative tools for similar tasks, though the sibling context makes the distinction reasonably clear.
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. The description adds specific behavioral details: it shows voted proposals, vote amounts, and withdrawable votes. This provides context beyond the annotations, such as the scope of data returned. However, it does not mention any limitations or potential issues with the default network parameter.
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 concise and front-loaded: a single sentence stating the main purpose, followed by a brief list of what is shown. No unnecessary words or repetition. It efficiently communicates the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description adequately explains what the tool returns (proposals, vote amounts, withdrawable votes). The context signals show no nested objects, so the output is likely simple. The description is complete for a read-only query tool with two optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (address and network), including default behaviors. The tool description does not add any new information about the parameters beyond what the schema already provides. Therefore, a score of 3 is appropriate, as the description does not enhance understanding of parameter 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 clearly identifies the tool's purpose: get a user's voting status across all governance proposals. It specifies exactly what information is returned (which proposals voted on, vote amounts for/against/abstain, withdrawable votes). This distinguishes it from siblings like 'get_vote_info' or 'get_vote_records' which may have different scopes.
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?
No explicit guidance is given on when to use this tool versus alternatives like 'get_vote_records' or 'get_locked_votes'. The description implies it's a comprehensive overview, but does not state when not to use or scenarios where other tools are better suited.
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, idempotentHint, and non-destructive. Description adds key behavioral detail: vaults with zero mining APY are excluded, and it returns APY splits. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, usage, exclusion. Front-loaded with main action. No redundant 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?
No output schema, and description only vaguely states 'APY split' without detailing return format. For a data-retrieval tool, more explicit return structure would improve completeness.
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 covers 100% of one parameter with clear description. Description adds no additional meaning beyond schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it maps every Moolah vault with active mining to USDD/TRX APY split. It distinguishes from siblings by specifying usage for dashboard fire-icon prefetch and explicitly mentions exclusion of zero APY vaults.
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?
States it is used by dashboard for prefetching fire-icon eligibility in one round-trip, providing clear context. Does not explicitly mention when not to use or alternatives, but 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 provide readOnlyHint=true and destructiveHint=false, indicating safe read operation. The description adds value by listing returned fields (estimatedRefundTrx, remaining rent, etc.), providing behavioral context beyond annotations. However, it does not disclose prerequisites or side effects, but these are not needed for a read-only tool.
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 front-loads the purpose and lists key output fields. Every word contributes value; no wasted text.
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 simplicity (3 parameters, no output schema, read-only), the description sufficiently explains what the tool returns. It covers all necessary information for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to detail parameters. It adds no new meaning beyond the schema, which already describes the three parameters. The baseline of 3 is appropriate given high coverage.
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 'Get estimated refund info for returning/canceling an energy rental,' identifying the resource (energy rental) and the specific information provided. It distinguishes from siblings like 'return_energy_rental' (which performs the return) and other 'get_*' 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 when considering returning or canceling a rental but does not explicitly specify when not to use or mention alternatives among siblings. It lacks explicit context on exclusion or comparison with similar 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?
Description adds behavior beyond annotations: mentions 'shares math for exact settlement' and token-specific prerequisites. Annotations already indicate destructiveHint=true, but description provides helpful context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences covering purpose, special value, and token-specific details. No wasted words, front-loaded with the primary action.
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?
Adequately complete for the tool's complexity: covers basic operation, special values, and token-specific steps. Lacks details on return value or transaction confirmation, but acceptable given typical patterns.
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 covers all parameters (100% coverage). Description adds value by explaining 'max' usage and prerequisite workflow for TRC20 tokens, augmenting the schema's type/pattern constraints.
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?
Description clearly states 'Repay a Moolah market loan' with specific verb and resource. It distinguishes from similar tools like 'moolah_borrow' and 'supply', but does not explicitly differentiate from the generic 'repay' sibling, which slightly reduces clarity.
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?
Provides clear instructions: use 'max' for full repayment, and prerequisites for TRC20 vs TRX loans. Does not mention when not to use or alternatives, but the context is sufficient for correct usage.
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 annotations (destructiveHint: true), description adds important details: 'you burn your own WTRX', contract method 'withdraw(uint256)', and 1:1 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?
Two sentences, front-loaded with core action (unwrapping, rate). Second sentence covers key details (no approval, pre-checks, reversal). No wasted 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?
Adequate for a simple unwrap with clear pre-conditions, but lacks mention of return value (receipt?) or post-unwrap state. Since no output schema, description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (amount, network). Description adds no new parameter semantics beyond what schema provides, meeting baseline but not exceeding.
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?
Clearly states it unwraps WTRX to native TRX at a 1:1 rate via the WTRX contract. The verb 'unwrap' is specific to the resource 'WTRX' and contrasts with 'wrap_trx' listed among 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?
Provides explicit context: no approval needed, pre-checks (sufficient WTRX balance, TRX for gas), and relationship to wrap_trx. It clearly guides when to use this tool, though it could mention when alternatives are preferable.
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 destructiveHint=true and readOnlyHint=false, so the tool modifies state. The description adds behavioral context by detailing the routing logic (multi-merkle vs USDDNEW vs main distributor), which goes beyond annotations. It also specifies mainnet-only, a key constraint. The description does not mention gas costs or failure modes, but with annotations present, this is sufficient.
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 three sentences, each serving a purpose: action, parameter options, and routing logic. It is front-loaded with the core purpose and contains no fluff. Every sentence earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema), the description covers the main use case, parameter approaches, routing, and network restriction. It does not mention prerequisites (e.g., eligibility) or output details, but annotations cover the destructive nature. Overall, it provides sufficient context for an agent to use the tool correctly.
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 coverage is 100%, so each parameter already has a description. The tool description adds value by explaining the preferred usage of key and the routing logic that depends on amount, selector, and distributor. This helps the agent understand parameter interactions beyond the schema, earning a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool claims a single V1 mining airdrop round via multiClaim() on the appropriate merkle distributor. The verb 'claim' paired with the specific resource 'V1 mining airdrop round' and mechanism 'multiClaim()' makes the purpose unambiguous. It also distinguishes from the sibling 'claim_moolah_mining_period' by explicitly mentioning V1 and routing logic.
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 provides guidance on using the key from get_claimable_rewards (preferred) or directly supplying merkleIndex/index/amount/proof, and specifies mainnet-only. However, it does not compare this tool to other claim tools like claim_moolah_mining_period or explain when not to use it, so the guidance is partial.
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 indicate idempotentHint=true and readOnlyHint=false, so the tool is a safe-to-repeat mutation. The description adds valuable behavioral context: the effect on borrowing capacity and the typical cost (~80,000 energy + ~300 bandwidth). It does not cover potential errors or prerequisites beyond 'supplied assets', but overall adds transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, front-loaded with the primary action. Every sentence adds value: purpose, prerequisite, effect, and cost. No unnecessary words or 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?
Given no output schema, the description explains the key behavioral outcome (supply counts toward borrowing capacity) and cost. It could mention that supplying must occur before entering, but that is implied by 'Required before borrowing against supplied assets.' It is sufficiently complete for a tool with two simple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no new information about the parameters beyond what the schema already provides (e.g., 'market' is a jToken symbol). The example in the schema ('jUSDT', 'jTRX') is sufficient, so the description does not improve parameter 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 clearly states the action: 'Enable a jToken market as collateral.' It specifies the verb 'enable' and the resource 'jToken market', and distinguishes from sibling tools like exit_market and borrow by noting it is required before borrowing.
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 explicitly states when to use: 'Required before borrowing against supplied assets.' It also explains the effect: 'Once entered, your supply in this market counts towards your borrowing capacity.' However, it does not explicitly state when not to use or mention alternatives like exit_market.
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 destructiveHint=true and readOnlyHint=false. The description adds value by detailing pre-checks and cost (~50,000 energy + ~280 bandwidth). 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 concise (one sentence plus bullet list) and front-loaded with the core action. Every sentence provides necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's two parameters and no output schema, the description covers pre-conditions and cost sufficiently. It could mention reversibility or outcome, but is adequate for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-described in the schema. The description does not add new semantic details beyond the schema, meeting the baseline of 3.
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 (disable as collateral) and resource (jToken market). It distinguishes from the sibling 'enter_market' (the opposite operation). The pre-checks further clarify the purpose.
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 pre-checks provide explicit conditions when the tool can be used (no borrows, sufficient remaining collateral). However, it does not explicitly state when not to use or mention alternatives like 'withdraw' or 'enter_market'. The conditions are clear but not exhaustive.
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 (readOnlyHint, idempotentHint, etc.) already indicate safe read. Description adds specific list of returned fields, providing behavioral context beyond annotations. No contradictions.
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?
Single sentence listing parameters. Slightly verbose but no unnecessary words. Front-loaded with purpose.
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?
Tool is simple (1 optional param, no output schema). Description fully covers what it returns. No gaps.
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 covers 100% with one optional parameter. Description adds default value 'mainnet' not in schema, clarifying optionality and default 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?
Clear verb 'Get' and resource 'on-chain energy rental parameters'. Lists specific parameters returned. Distinguishes from siblings like get_energy_rental_rate by focusing on overall parameters vs. rate.
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?
No explicit when-to-use or alternatives. Context suggests it's for retrieving static parameters, but no guidance on when to use this versus other energy rental getter tools (e.g., get_energy_rental_dashboard).
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 mark it as read-only, idempotent, and non-destructive. The description adds that it is paginated and mainnet-only, which are behavioral constraints beyond what annotations provide. No contradictions 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 two sentences, front-loaded with the core purpose. Every part is informative: what it does, coverage (both directions), distinction from sibling, pagination, and mainnet constraint. No unnecessary 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?
Given no output schema, the description explains the return type (liquidation history), covers key constraints (paginated, mainnet-only), and distinguishes from a sibling. It is fairly complete for a read-only tool, though it does not detail the exact fields in the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds context that the records include both directions of liquidation, but this is more about the output than parameter semantics. It does not add significant detail about parameter usage beyond the schema.
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 it retrieves V1 JustLend liquidation history for a user, covering both liquidations initiated by the user and liquidations where the user was the target. It explicitly distinguishes from the sibling tool get_moolah_liquidation_records, which covers V2 Moolah liquidations.
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 guidance on when to use this tool by differentiating it from get_moolah_liquidation_records and noting it is mainnet-only. However, it does not specify when not to use it or mention other alternatives beyond the sibling.
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 read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context by defining riskLevel > 1.0 as liquidatable and suggesting minRiskLevel=0.9 for near-threshold positions, which aids agent understanding of output semantics.
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 consists of two concise sentences without extraneous information. The purpose is front-loaded, and each sentence contributes essential meaning, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 optional parameters, no output schema, and annotations cover safety, the description adequately explains the core concept and usage. It lacks explicit mention of return format or pagination behavior, but this is not critical for a read-only list 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?
Schema coverage is 100% with parameter descriptions. The description adds meaning beyond schema by explaining the riskLevel concept and how minRiskLevel relates to liquidation threshold, providing an example value. Other parameters like page and network are already documented in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Moolah positions eligible or approaching liquidation, using specific verb 'list' and resource 'positions'. It distinguishes from siblings like liquidation records or quotes by focusing on pending positions, and explains the riskLevel threshold.
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 to find liquidatable or near-liquidatable positions and provides an example (minRiskLevel=0.9). However, it does not explicitly state when not to use this tool or compare it with alternatives like get_moolah_liquidation_records or moolah_liquidate.
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, so the description does not need to emphasize safety. It adds context about the filtering capability but no further behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose; no wasted words. The description efficiently conveys the core functionality and filtering options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters (all optional, all described in schema), the description adequately covers the main purpose and the key filter. Pagination and network defaults are implied by schema, so no major gaps for a read-only 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?
Schema coverage is 100%, but the description adds meaningful clarification for the 'type' parameter by explaining the roles 'renter' and 'receiver', which is not fully explicit in the schema enum 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 clearly states the verb 'Get', the resource 'user's energy rental orders', and the source 'JustLend'. It also explains the filtering by role, distinguishing it from sibling tools like get_energy_rental_dashboard.
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 implies when to use this tool (to get a user's rental orders filtered by role) but does not explicitly contrast it with alternatives like get_energy_rental_records or get_energy_rental_params.
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 read-only, idempotent, non-destructive. Description adds value by detailing the record structure (opType, opName, amount, proposalId) and operational context (mainnet-only). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first enumerates record types, second provides field details and an alternative tool. No redundant information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description provides essential return structure (fields per record). Mentions mainnet-only. Could explain pagination behavior, but parameters address that. Overall sufficiently complete for a read-only query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. Description does not add parameter-specific info but indirectly clarifies output structure. Sufficient given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves governance voting history, listing specific transaction types (deposits, votes, withdrawals, conversions) and distinguishes it from the real-time status tool. It specifies the verb 'Get' and the resource 'voting history', making purpose unambiguous.
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?
Explicitly advises using 'get_user_vote_status' for real-time current voting power, providing an alternative for a related but distinct use case. Also notes 'Mainnet-only' constraint. Could mention more siblings but current guidance is clear and helpful.
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 indicate destructiveHint=true, so the description adds value by explaining token-specific behaviors (approval needed for TRC20, direct for TRX). However, it does not disclose return values, side effects, or error conditions, leaving gaps in behavioral 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?
Two concise sentences with no fluff. The first sentence states the core action and purpose; the second adds critical conditional guidance. Front-loaded with the verb and resource.
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?
Covers main use case and token-specific prerequisites adequately for a write tool with good annotations. However, it lacks mention of transaction output, gas implications, or what happens if collateral is already supplied, so not fully complete.
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 coverage is 100%, so the description adds context beyond schema: provides an example for amount ('10000' for 10000 TRX) and notes that marketId comes from get_moolah_markets. This aids understanding but does not elaborate on format or constraints beyond schema.
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?
Description clearly states the verb 'Supply collateral' and resource 'Moolah market', with the specific purpose of enabling borrowing. It distinguishes from sibling tools like approve_moolah_proxy and moolah_withdraw_collateral by mentioning prerequisites for different token types.
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?
Provides clear when-to-use context (to enable borrowing) and conditional guidance: for TRC20, call approve_moolah_proxy first; for TRX, no prior approval. This helps the agent understand prerequisites but does not explicitly state when not to use or mention alternative 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?
Description adds behavioral details beyond annotations: staking via JustLend, rewards (vote APY + energy rental income), pre-checks. 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?
Two focused sentences plus a pre-check note, front-loaded with main action. No wasted 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?
Covers main action, prerequisites, and rewards. No output schema, but return value is implied (sTRX tokens). Could mention that it returns transaction hash or similar, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description only adds generic context about balance checks. Does not elaborate on network default or value format beyond schema.
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?
Clear verb 'Stake', resource 'TRX', outcome 'receive sTRX tokens'. Distinguishes from siblings like 'unstake_strx'. Mentions rewards.
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?
Provides explicit pre-checks (sufficient TRX balance for amount + gas) and states the action's purpose. Lacks when-not-to-use but context is clear given 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?
The description adds value beyond annotations by disclosing the unbonding period. Annotations already indicate the tool is destructive, and the description provides additional behavioral context about the timing of withdrawal.
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 concise with two sentences, front-loading the primary purpose first. Every sentence provides necessary information 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 unstake tool, the description covers the key points: action, output, timing constraint, and prerequisite. It is complete enough for an agent to understand and use the tool correctly, though it could mention effects on staking rewards.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already provides detailed descriptions for both parameters (amount format, network). The description does not add any new information about parameters beyond what is in the schema.
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: 'Unstake sTRX to receive TRX back.' It uses a specific verb and resource, and distinguishes itself from sibling tools like 'stake_trx_to_strx' which performs the opposite operation.
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 explicit context: it notes the unbonding period and mentions a pre-check for sufficient balance. However, it does not mention alternatives like using 'check_strx_withdrawal_eligibility' to verify eligibility first.
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 show readOnlyHint=true, so the description's behavioral context about auto-detection and incremental cost calculation adds value beyond annotations. It discloses that for renewals it subtracts existing security deposit, which is a key behavioral detail.
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 about 100 words, front-loaded with the core purpose, and well-structured with separate sections for new and renewals. It could be slightly more concise but no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists return values (important since there's no output schema), explains auto-detection for renewals, and gives parameter context. It could specify units or output format, but overall it's sufficient for an agent to use correctly.
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 coverage is 100% but the description adds meaning by clarifying the different minimums for new (300,000) vs renewal (50,000) and the conditional requirement of durationHours. This goes beyond the schema's generic 'minimum 50,000' and 'required for new' context.
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 it calculates the cost to rent energy for a given duration, and distinguishes between new rentals and renewals. It lists the specific return values, and the contrast with siblings like 'get_energy_rental_rate' (rate only) and 'rent_energy' (executes) is implicit.
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 explicitly tells when to use each parameter combination (new vs renewal) and mentions auto-detection of existing rentals. It does not explicitly list when not to use this tool, but the context of siblings and the detailed parameter guidance make it clear.
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 destructiveHint=true and readOnlyHint=false. The description adds value by explaining the support parameter's boolean semantics and the ability to stack votes on a previously voted proposal, which goes beyond the 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 three sentences with no filler. Each sentence serves a purpose: prerequisite, parameter explanation, and notable capability. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites and parameter behavior but omits details about the return format, error scenarios (e.g., insufficient votes, invalid proposal), and any side effects. For a mutation tool with destructiveHint=true and no output schema, this leaves uncertainty for the agent.
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 coverage is 100% and descriptions already exist. The description adds nuance by clarifying that the 'support' true/false corresponds to FOR/AGAINST (redundant but helpful) and that 'votes' can be used to add to an existing vote on the same proposal, which is not in the schema.
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 ('Cast a vote') and resource ('governance proposal'), and distinguishes from sibling tools like deposit_jst_for_votes or withdraw_votes by focusing on the actual voting action, including semantics for support and the ability to add votes.
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 prerequisite ('must have available votes, deposit JST first if needed') and notes that repeated use is allowed for adding more votes. However, it does not explicitly contrast with alternatives like checking vote status or withdrawing votes.
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 read-only, idempotent, non-destructive behavior. The description adds value by detailing the return structure (map keyed by round with merkleIndex, amount, token info) and the intended follow-up action, which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded with the main action and result. Each sentence adds essential information: what it does, what it returns, and how to use it. No filler or redundancy.
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?
Despite no output schema, the description explains the return format sufficiently. It also mentions mainnet-only and the follow-up tool. For a read-only query tool with annotations, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (address and network) with descriptions. The description reinforces network must be mainnet but adds no new parameter meaning. Schema description coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans all JustLend V1 merkle airdrop distributors for unclaimed rewards, and distinguishes itself from sibling tools like claim_v1_mining_period and other 'get_' tools by specifying the action and the follow-up tool. The verb 'scan' and resource 'JustLend V1 merkle airdrop distributors' are specific.
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 explains this tool is used before claim_v1_mining_period to obtain claimable rewards data. It also notes mainnet-only, providing clear context. It does not explicitly state when not to use it, but 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 indicate destructive=true, readOnly=false. The description adds beyond this by detailing the sequential transaction behavior when both amounts are provided and the LLTV constraint. 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 concise, with four sentences front-loaded with purpose. No wasted words, though slightly more structure (e.g., bullet list) could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (4 params, no output schema, destructive), the description covers the essential: modes, constraints, and revert behavior. Missing return value info, but acceptable.
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 coverage is 100%, baseline 3. The description adds significant meaning by explaining how collateralAmount and borrowAmount interact (one, the other, or both), and the LLTV condition. This goes beyond the schema's 'omit to skip' 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 clearly states it's a flexible borrow entry point for Moolah, explicitly describing three usage modes (collateral only, borrow only, both). This differentiates it from siblings like 'borrow' and 'moolah_supply_collateral'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance by explaining the three parameter combinations and their effects. It implicitly differentiates from siblings, but does not explicitly state when not to use or name alternatives.
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 destructiveHint=true, so the description adds the useful context 'No approval needed.' It does not contradict annotations. However, it could elaborate on the effect on vault state or the outcome of redemption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero wasted words. The first states the core purpose, the second provides a key usage hint. Fully earns its length.
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?
While the description is clear, it lacks details about the underlying assets or the post-redemption process (e.g., where assets go). Given no output schema, more completeness would be beneficial for a DeFi 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?
Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining the 'max' option for 'shares' and implying default for 'network'. This enhances the schema information.
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 ('Redeem'), the resource ('vault shares'), and the result ('receive underlying assets'). It distinguishes from sibling tools like moolah_vault_deposit and moolah_vault_withdraw by focusing on the redemption of shares.
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?
Provides a specific usage tip ('Use shares='max' to redeem all shares') and states that no approval is needed. However, it does not explicitly compare with alternatives or mention when not to use this tool.
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 indicate destructiveHint=true and readOnlyHint=false, and the description confirms it is a write operation. It adds context about the 1:1 rate and reversibility via unwrap_trx, and mentions pre-checks. 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 three concise sentences, front-loading the core purpose, followed by relevant context and pre-conditions. No unnecessary 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?
The description covers purpose, usage, and pre-checks, but does not describe the output/return value (e.g., transaction hash). Given no output schema, this is a gap for an agent needing to confirm execution.
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 coverage is 100% and description adds value by explaining the amount is a human-readable decimal string and noting the default network. The 1:1 rate and contract interaction context further illuminate the amount parameter.
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 'Wrap native TRX into WTRX' at a 1:1 rate via the deposit() function. It specifies the action, resource, and mechanism, and distinguishes from the sibling unwrap_trx tool.
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 explains that WTRX is needed for DeFi protocols that cannot hold native TRX, giving example use cases. It mentions reversibility and a pre-check for sufficient balance, but does not explicitly list scenarios where this tool should not be used.
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 value by disclosing that results are 'historical typical values' and that on-chain simulation is not wired, which are important limitations not present in 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 compact and front-loaded with the main purpose. It efficiently conveys key information without unnecessary words, though it could be slightly more streamlined.
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?
With no output schema, the description does not detail return values but acknowledges they are historical typical values. For 4 parameters and no nested objects, the description provides sufficient context for a typical estimation tool, though more precision on output format would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context for isTRX (explaining when to set true) and enumerates all valid operation values. This additional guidance goes beyond the schema 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 clearly states the tool estimates energy, bandwidth, and TRX cost for Moolah write operations. It specifies the domain (JustLend V2/Moolah) and distinguishes from sibling execution tools like moolah_borrow or other estimation tools like estimate_lending_energy.
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 instructs when to set isTRX=true and notes that estimation should happen before executing. It lists all covered operations. However, it does not explicitly exclude other protocols or provide guidance on when not to use this tool vs. estimate_lending_energy.
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, destructiveHint, idempotentHint, and openWorldHint. The description adds that it is paginated and mainnet-only, and lists specific action types included. This provides additional behavioral context beyond 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 two sentences long, front-loaded with the main verb 'Get', and contains no redundant or unnecessary information. Every sentence contributes value.
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?
Without an output schema, the description does not detail return format, but it clearly defines the content as a historical action log and contrasts it with active orders. It mentions pagination and mainnet-only. This is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description does not add extra semantics beyond the schema, except implicitly confirming network must be mainnet. Thus, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the user's JustLend energy-rental history, listing specific actions (rent, extend, rent_more, end, recycle). It explicitly distinguishes from the sibling tool get_user_energy_rental_orders which returns current active orders, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with the sibling tool: 'Distinct from get_user_energy_rental_orders which returns current active on-chain orders — this one returns the full historical action log.' It also notes pagination and mainnet-only usage, providing clear guidance on when and how to use it.
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=true, idempotentHint=true, destructiveHint=false. The description adds that it 'returns the exact loan token amount needed', which is helpful behavioral context. 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?
Three concise sentences each adding distinct value: purpose, parameter usage, and pre-execution context. No wasted words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description states what is returned. For a simple estimation tool, this is sufficient. It could be improved by mentioning return type or precision, but overall it is adequate.
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 100%, so parameters are documented. The description adds crucial mutual exclusivity guidance ('Provide either...not both'), which goes beyond schema descriptions. This significantly aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'estimate' and the resource 'loan token cost'. It distinguishes from the sibling tool 'moolah_liquidate' by noting it should be used before liquidation. The purpose is specific and unambiguous.
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 explicitly tells when to use this tool ('Use this before calling moolah_liquidate') and provides parameter guidance (not both seizedAssets and repaidShares). While it doesn't explicitly list alternatives, the context of being a quote tool before execution is clear.
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 safe read-only behavior (readOnlyHint, idempotentHint, destructiveHint=false). The description adds value by specifying that it returns both current values (totalBorrow, totalCollateral, apy) and a list of historical points, offering behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the main function and then detailing return structure and usage hint. Every sentence contributes meaning 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?
Given the tool's complexity (current data plus time series) and no output schema, the description explains the return structure adequately. However, it omits details about the fields within the historical points list, which might be needed for full completeness.
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 covers both parameters (network, marketId) with descriptions, achieving 100% coverage. The description adds context by noting that marketId should come from get_moolah_markets, enhancing the schema's meaning.
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 explicitly states it returns a 'Time series of a V2 Moolah market's borrow/supply APY, utilization, and totals', clearly identifying the verb (get), resource (V2 Moolah market history), and distinguishing it from sibling tools like get_moolah_market (current snapshot) or get_moolah_markets (list of markets).
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 advises to 'Use marketId (bytes32 hex) from get_moolah_markets', guiding the user to first retrieve the marketId from a sibling tool. While it does not explicitly state when not to use this tool, it provides sufficient context for appropriate usage.
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, openWorldHint, and destructiveHint=false. The description adds behavioral details such as returning merkleIndex, index, amounts, proof, and USD total, and explains the includeClaimed parameter behavior. No contradictions.
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 three sentences, each earning its place: first sentence states purpose, second lists return fields, third explains usage and parameter. No superfluous text, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description compensates by listing return fields (merkleIndex, index, amounts, proof, total). It adequately covers the tool's behavior and parameter usage, though it doesn't mention pagination or error handling. Still sufficient for a read-only list 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?
Schema coverage is 100% with descriptions for all 3 parameters. The description adds extra meaning for includeClaimed (default false matches rewards card behaviour) and implies that address and network are optional. Baseline 3, plus 1 for additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get), resource (claimable V2 mining airdrop rounds), and scope (already settled and merkle-published). It distinguishes itself from siblings like claim_moolah_mining_period and get_moolah_mining_accruing by specifying the state of the rounds.
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 explicitly tells the agent to feed periodKey into claim_moolah_mining_period for the next step, and explains when to use includeClaimed=true. While it doesn't explicitly list alternatives, the context from sibling tools and the focus on settled rounds provides clear usage context.
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 indicate destructiveHint=true, but the description adds valuable behavioral context: 'max' requires no active borrows, and withdrawing too much while borrowing will revert. It also suggests checking health factor. No contradictions 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 extremely concise: two sentences. The first sentence defines the core purpose, and the second provides critical usage constraints. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, destructive hint, no output schema), the description adequately covers usage, special cases, and safety warnings. It could optionally mention return values (e.g., transaction hash), but not necessary for a withdraw action.
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 coverage is 100% with descriptions for all three parameters (amount, network, marketId). The description adds meaning by explaining the special value 'max' for amount and the condition for its use, going beyond the schema's pattern and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'withdraw collateral from a Moolah market' and distinguishes from sibling tools like moolah_supply_collateral, moolah_borrow, etc. The special case of using 'max' and the condition of no active borrows further clarify the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use (withdrawing collateral) and when not (with active borrows if not using max, or withdrawing too much while borrowing). It advises checking health factor first, but does not explicitly name alternative tools for withdrawing from other contexts (e.g., generic withdraw).
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?
Discloses cost (energy/bandwidth) and approval requirements, adding value beyond annotations. Does not contradict destructiveHint=true. Cost info is useful for agent planning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose. No redundant words. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisite, special value, and cost. Lacks details on return value or side effects, but annotations already indicate destructive nature. Adequate for this complexity.
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?
Adds context to parameters: clarifies amount 'max' usage, and links market to TRC20 approval. Schema coverage is 100%, so baseline is 3; the additional prerequisite info raises the score.
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?
Clearly states the action ('repay borrowed assets') and the target ('JustLend market'), distinguishing it from sibling 'moolah_repay'. Includes specific details like approval prerequisite for TRC20.
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?
Describes when to use (repaying borrowed assets), prerequisite (approval for TRC20), and special value 'max'. Lacks explicit comparison to alternatives, but context is clear given 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 indicate destructiveHint=true and readOnlyHint=false, so the description does not need to restate those. It adds behavioral context by specifying the proposal must be completed or canceled, and that votes are reclaimed, which aligns with the destructive nature.
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 only two sentences, with the first sentence stating the action and limitation, and the second describing the effect. Every word is necessary, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and destructive annotations, the description covers the main aspects: what it does, when it works, and the result. It does not mention prerequisites like having votes deposited, but that is implied by the action and the context of voting tools. Overall, it is sufficiently complete.
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 coverage is 100%, so the baseline is 3. The description adds value by implying that the proposalId parameter must refer to a completed or canceled proposal, which is not explicitly stated in the schema's parameter description. This extra guidance improves parameter understanding.
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 explicitly states the action 'Withdraw (reclaim) votes from a completed or canceled proposal,' using a specific verb and resource. It distinguishes itself from siblings like 'withdraw_votes_to_jst' by focusing on the proposal rather than conversion to JST.
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 states the tool only works for proposals that are no longer active, providing a clear when-to-use condition. It also mentions that votes become available for other proposals or conversion to JST, giving context on subsequent actions, though it does not explicitly name alternative 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?
Annotations include destructiveHint: true, consistent with a withdrawal. The description adds important context about the lock constraint on votes. However, it does not mention potential fees or the transaction cost, which would add further value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. No unnecessary words, every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple mutation tool with no output schema. It explains prerequisites and constraints. However, it could optionally mention the transaction hash return or any side effects like JST balance updates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'amount' and 'network' have descriptions. The tool description does not add new information beyond the schema for the parameters, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Withdraw WJST back to JST.' It distinguishes from sibling tools like 'deposit_jst_for_votes' (the reverse) and 'withdraw_votes_from_proposal' (different scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Can only withdraw votes that are not currently locked in active proposals. Use get_vote_info to check your surplus (available) votes before withdrawing.' This provides clear precondition and a prerequisite step.
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 indicate idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful context: it's a prerequisite for deposit, not needed for TRX vaults, and explains the risk of 'max' approval and revocation ('amount=0'). 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 three concise sentences with no wasted words. It front-loads the purpose and key guidance, making it easy to parse quickly.
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 simple approval tool with no output schema, the description covers all necessary context: what it does, when required, parameter tips, and safety warnings. It is complete for the task.
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 has 100% coverage with parameter descriptions. The description adds significant nuance for the 'amount' parameter (exact vs. max, revocation nuance), improving the agent's understanding beyond the schema. The other parameters ('vaultSymbol', 'network') are not elaborated, but the added value for 'amount' raises the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool approves TRC20 token spending for a Moolah vault before depositing, distinguishing it from TRX vaults and other approval tools. It specifies the action, resource ('Moolah vault'), and scope, setting it apart from siblings like 'approve_moolah_proxy'.
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 tells when to use (before depositing, not for TRX vaults) and gives recommendations (exact amount preferred, 'max' only with user opt-in). It lacks explicit mention of alternatives among sibling approve tools, but the context is clear.
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 and idempotentHint. Description adds specific return fields (APY, TVL, utilization, etc.) and confirms it's for a specific market, providing useful behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and output, second provides usage hint. No unnecessary words, front-loaded with key 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?
No output schema, but description lists all returned fields. For a simple read-only data retrieval tool, the description provides enough context for an agent to understand inputs and outputs.
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 coverage is 100% with parameter descriptions. Description adds meaning by explaining jToken symbol and giving examples, adding value beyond schema definitions.
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?
Description clearly states the tool retrieves detailed market data for a specific JustLend market, listing specific fields (supply/borrow APY, TVL, etc.) and giving a usage example (jToken symbol). This distinguishes it from siblings like get_all_markets.
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?
Explicitly says 'Use jToken symbol like 'jUSDT' or 'jTRX'' and implies it's for a single market detail, but does not explicitly state when not to use or mention alternatives.
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 readOnlyHint, idempotentHint, destructiveHint. Description adds value by listing specific data fields (APY, LLTV, utilization, total supply/borrow, vaults) included in the output, which is not in 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?
Two concise sentences: first defines purpose and scope, second offers sibling guidance. No unnecessary words.
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?
Tool is a single-item query with safe read operations; description lists included fields (APY, LLTV, etc.) to set expectations. No output schema needed given this clarity.
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 provides descriptions for both parameters. Description adds format example '0xabc...' for marketId and notes default network is mainnet, enhancing understanding beyond schema.
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?
Clearly states verb 'Get', resource 'Moolah market', and identifier 'marketId'. Also distinguishes from sibling get_moolah_markets by specifying it retrieves full details for 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using get_moolah_markets to find marketIds before calling this tool, providing clear guidance for use. No explicit when-not, but the sibling reference 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 provide destructiveHint=true, readOnlyHint=false. Description adds value by stating it returns vault shares, which explains the outcome beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. First sentence gives purpose, second adds prerequisite and return value. Efficient and well-structured.
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 3 parameters, no output schema, and annotations present, description covers purpose, prerequisite, and return value adequately for tool selection and invocation.
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 coverage is 100%, but description adds context by naming specific TRC20 vault symbols (USDT, USDD) for vaultSymbol, aiding parameter understanding beyond basic schema.
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?
Description clearly states 'Deposit assets into a Moolah ERC4626 vault to earn yield' with specific verb and resource. Distinguishes from sibling tools like 'approve_moolah_vault' by noting prerequisites for TRC20 vaults.
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?
Explicitly instructs to call 'approve_moolah_vault' first for TRC20 vaults (USDT, USDD), providing clear when-to-use guidance. Lacks explicit comparison with other deposit-related siblings, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals behavior beyond annotations: automatic TRX calculation, pre-checks, and differentiation between new and renewal behavior. Annotations indicate destructiveHint=true and readOnlyHint=false, which are consistent. The description adds valuable context without contradiction.
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 paragraph but flows logically: action, then new/renewal rules, then pre-checks. It is concise with no filler. However, breaking into bullet points could improve readability, but not required.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers inputs and behavior well but does not mention output or return format. Since there is no output schema, the agent must infer what the tool returns (e.g., transaction result). This is a gap for a tool that modifies state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: explains energyAmount minimums based on rental type, and clarifies durationHours conditional behavior. This goes beyond the schema's static descriptions, providing actionable semantics for the AI agent.
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 'Rent energy from JustLend for a specified receiver address.' It specifies the verb (rent), resource (energy), and platform (JustLend). It also distinguishes between new rentals and renewals, adding specificity. While it does not directly compare to siblings, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: durationHours is required for new rentals, optional for renewals; minimum energy amounts differ (300,000 new, 50,000 renewal). It mentions pre-checks (not paused, within limits, sufficient TRX). However, it does not state when not to use the tool or suggest alternatives, which would elevate it to a 5.
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 declare readOnly, openWorld, idempotent. The description adds valuable behavioral details: automatic resolution of symbols to contract addresses via JustLend markets, and that the balance is pre-formatted (decimals applied) so agents must not re-divide. This exceeds annotation-only information.
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?
Four short sentences that front-load the purpose and quickly deliver key usage warnings. Every sentence adds value; no fluff.
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?
Despite no output schema, the description explains return format (formatted balance) and critical usage nuances. It covers the main edge case (deprecated addresses) and defaults. Slightly incomplete on error handling for invalid symbols, but adequate for the tool's simplicity.
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 coverage is 100% with good descriptions. The description adds extra semantics: the preference for symbol over address, the auto-resolution mechanism, and the formatting behavior. This provides context beyond the raw schema.
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 'Get TRC20 token balance for an address' with a specific verb and resource. It distinguishes from sibling tools (e.g., get_trx_balance, get_strx_balance) by focusing on TRC20 tokens. The explanation of symbol vs. address resolution adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Always prefer using token symbols over raw addresses' with a concrete example and rationale about deprecated addresses. This tells the agent when and how to use the parameters correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the destructiveHint annotation: it requires holding and approving a loan token, specifies mutual exclusivity of seizedAssets and repaidShares, and suggests a prior step. This aligns with the tool's destructive nature and provides critical usage constraints.
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 four concise sentences, front-loading the main action. Each sentence serves a purpose: action, prerequisites, parameter rule, and recommendation. No unnecessary 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?
The description covers the core action, prerequisites, parameter constraints, and a helpful recommendation. It does not describe the return value, but given no output schema, this is acceptable. The overall context is sufficient for a mutation 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?
With 100% schema coverage, baseline is 3. The description adds value by explicitly stating the mutual exclusivity of seizedAssets and repaidShares and clarifying their roles, which is not fully captured in the schema descriptions. This helps the agent choose correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Liquidate an undercollateralized Moolah position.' It uses a specific verb and resource, distinguishing it from sibling tools like moolah_borrow or moolah_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 provides necessary prerequisites (must hold loan token and approve via approve_liquidator_token) and recommends using get_moolah_liquidation_quote first. It does not explicitly mention when not to use or alternatives, but the guidance is sufficient for the tool's context.
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 idempotentHint and destructiveHint, but description adds behavioral context: the approval is a write operation, and 'max' grants unlimited spending until revoked, which is critical safety information.
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?
Four sentences, each essential. Front-loaded with action and necessity, followed by parameter guidance. No redundant or vague language.
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?
No output schema needed; effect is clear. Covers prerequisite, parameter choices, and safety considerations. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers parameters with descriptions (100% coverage). Description adds value by explaining the rationale for exact vs max amount and the risk of max, which goes beyond schema syntax.
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?
Describes the specific action (approve JST for WJST voting contract), states the prerequisite role, and distinguishes from sibling approval tools by naming the target contract and use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before depositing JST for voting), provides clear recommendation for amount parameter (exact amount recommended, 'max' only with user opt-in), and warns about consequences of unlimited approval.
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 indicate idempotentHint=true and not destructive. The description adds context about the implications of 'max' (unlimited spending until revoked) and the recommended exact amount. It does not contradict 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?
Three sentences: purpose, prerequisite, and detailed instruction. Front-loaded with key action. No redundancy or unnecessary words.
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 simple nature (approval with a key parameter), the description covers purpose, usage context, and parameter nuance. It also mentions the follow-up tool (moolah_liquidate) and revocation, making it complete for agent use.
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 covers all parameters (100%), baseline 3. The description significantly enriches the 'amount' parameter with actionable guidance beyond the schema, explaining the trade-offs of 'exact' vs 'max' and how to revoke.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'approve' and the specific resource 'loan token spending for the Moolah public liquidator contract'. It distinguishes this tool from sibling approval tools by naming the specific contract and linking to moolah_liquidate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Required before calling moolah_liquidate.' Provides guidance on amount usage and warns about 'max' only with user opt-in, and mentions revoking with amount='0'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly explains the behavior beyond annotations: it details the two approval modes (exact vs. max) and their consequences, including the risk of unlimited spending. It also specifies that the tool writes transaction data (implied by 'approve' and not read-only). 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 concise (few sentences), front-loaded with the core purpose, and each sentence adds unique guidance. It does not waste 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?
The description covers the purpose and usage well but does not mention the output (e.g., transaction hash) or prerequisites (e.g., wallet must be connected). Given the tool's complexity (blockchain approval), the description could be more complete by explaining the expected result and any necessary prior actions. However, the high schema coverage and annotations partially compensate.
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 schema covers all parameters with descriptions (100% coverage). The tool description adds extra context for the 'amount' parameter, specifying when to use exact vs. max and the associated risks, which enhances semantic understanding beyond the schema's pattern and description. For other parameters, the description doesn't add new info, but the schema 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 clearly states the action (approve TRC20 token spending), the target (Moolah core contract), and the context (before supplying collateral or repaying). It also explicitly notes it's not needed for TRX operations, distinguishing it from other operations. Given sibling tools have different approval targets, this description effectively differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (before supplying collateral or repaying), what amount to pass (exact recommended, 'max' only with explicit user opt-in), and what not to use it for (TRX operations). This provides clear decision guidance for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reinforces annotations (readOnlyHint=true, destructiveHint=false) by stating it's a check. Adds context about prerequisite step, no contradictions. High 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?
Two sentences, front-loaded with action, no unnecessary words. Efficient and clear.
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 simple read-only check, description is complete. No output schema needed; binary result is implied. Provides full context for agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters are well-described with defaults and patterns. Description adds no extra meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resource 'JST allowance for WJST voting contract'. It distinguishes from siblings like 'check_allowance' by specifying the context and from 'approve_jst_for_voting' which is the write counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Must be approved before depositing JST to get votes', indicating when to use and implying the need for 'approve_jst_for_voting' if not approved. Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures match annotations (destructiveHint=true) and add value by stating that deposited JST can be withdrawn after voting. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences covering action, prerequisite, conversion, and reversibility. No fluff.
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?
Complete for its complexity: explains workflow, prerequisites, conversion, and withdrawal. Aligns well with sibling tools.
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 has 100% coverage for parameters. Description adds meaning with '1 JST = 1 Vote', clarifying the impact of the 'amount' parameter beyond schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deposit), resource (JST into WJST contract), and purpose (get voting power). It distinguishes from sibling tools like 'approve_jst_for_voting' and 'withdraw_votes_to_jst'.
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?
Explicitly states prerequisite (use approve_jst_for_voting first), guiding the agent on the correct sequence. Lacks explicit 'when not to use' but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial behavior: 'Tries on-chain simulation first; falls back to historical typical values if simulation fails.', 'Returns per-step breakdown...', and 'For supply/repay: automatically checks current allowance — if sufficient, the approve step is skipped.' This provides transparency about reliability and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and well-structured. It lists operations in a sentence and explains fallback, breakdown, and special cases. It is slightly long but each sentence adds value; a minor trim could improve conciseness without losing 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?
Despite no output schema, the description explains the return value: per-step breakdown, total energy, total bandwidth, estimated TRX cost. It covers all operations, fallback behavior, and handle edge cases (allowance check, custom spender). This is complete for an estimation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage). The description adds significant meaning: explains default amount ('1'), clarifies spender usage for approve, and notes which operations omit amount (enter_market, withdraw_all, etc.). This enriches understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates energy, bandwidth, and TRX cost for any JustLend operation before execution. It lists all covered operations (supply, withdraw, etc.) and implies it is for estimation, not execution. This is specific and distinguishes from siblings like estimate_moolah_energy.
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 tells when to use: 'whenever the user asks about gas/energy/cost for any lending operation'. It also says 'BEFORE executing' which implies it is not for after the fact. While it does not explicitly state when not to use, the context and fallback behavior are clear. Could be more explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds significant context: explains the meaning of 'accruingUsd' and 'settlingUsd', the settlement window conditions, the 'globalSettlementStatus' flag, and warns that per-token amounts are provisional. No contradictions 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 dense yet concise, with no wasted words. It front-loads the core purpose and uses structured clauses to explain edge cases. Every sentence 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?
Given the lack of output schema, the description fully explains the return values (accruingUsd, settlingUsd, globalSettlementStatus) and their provisional nature. Combined with strong annotations, the tool is well-documented for an agent.
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 coverage is 100% and both parameters are described in the schema. The description adds value by noting the defaults (address defaults to configured wallet, network defaults to mainnet) and the optional nature, which aids agent decision-making.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves accruing and settling V2 mining rewards across vaults, specifying the two types with precise definitions. It distinguishes itself from sibling tools like 'get_mining_rewards' by focusing on the V2 mining context and the settlement window logic.
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 explains when to use the tool (to get accruing/settling rewards) and provides detailed accounting logic to avoid double-counting. However, it does not explicitly mention alternatives or state when not to use it, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses on-chain pre-checks (isClaimed, merkleRoots) to avoid gas waste on reverting transactions. Annotations already mark destructiveHint=true, but the description adds valuable context about gas-saving behavior and current network restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, usage options, pre-checks, and network status. Front-loaded with core action, no wasted words.
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?
Thoroughly covers all aspects needed for an agent to use the tool: method, input options, pre-checks, and current deployment status. No output schema needed since it's a mutation.
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 provides full parameter descriptions (100% coverage). The description adds value by highlighting periodKey as preferred and explaining how override params work. Slight deduction because the schema already does heavy lifting.
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?
Clearly states it claims a single V2 mining airdrop round via multiClaim(). Distinguishes from sibling claim_v1_mining_period by specifying V2 and referencing get_moolah_pending_mining_periods for periodKey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using periodKey from get_moolah_pending_mining_periods or supplying override params directly. Warns about mainnet error and suggests nile testnet as alternative. Provides clear when-to-use and current limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: conditional return values based on wallet mode, and a guide when no mode is selected. No contradictions.
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 that efficiently conveys all necessary information. It is front-loaded and concise without any redundancy.
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 0-parameter tool with comprehensive annotations, the description fully covers the tool's behavior, including the three possible return scenarios. No output schema exists, but the description adequately explains the return values.
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 no parameters, so schema coverage is 100%. The description adds no parameter information, but given zero parameters, this is acceptable. Baseline 4 for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the active wallet address, specifying different return values based on wallet mode (browser, agent, or none). It distinguishes itself from sibling tools like get_wallet_balances or list_wallets by focusing on the active address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines when to use the tool (to get the current wallet address) and the behavior in different modes, including a guide when no mode is set. It implicitly guides the agent to use this tool for the active address, while alternatives exist for balances or listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits: cost (~23k energy + 265 bandwidth), idempotent (safe to call repeatedly), and risk of unlimited approval. Annotations (idempotent=true, destructive=false) are consistent, and description adds significant context beyond 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?
Very concise: four sentences covering purpose, prerequisite, amount recommendation with caveat, and cost. No filler; each sentence earns its place. Front-loaded with core action.
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 no output schema, the description fully covers what an agent needs: prerequisites (TRC20 markets), parameter usage (amount, market, network), edge cases (max approval), and cost. Complete for a transaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining the amount parameter's practical meaning (exact vs. max with security warning) and the context of market parameter (jToken symbol). Does not merely repeat schema.
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?
Clearly states the tool approves jToken contract to spend underlying TRC20 tokens. Specifies when required (before supply/repay for TRC20 markets, not for jTRX), distinguishing it from sibling approve tools like approve_jst_for_voting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (required before supply/repay for TRC20 markets) and when not (jTRX). Provides clear guidance on amount: recommend exact, 'max' only with explicit user opt-in. No ambiguity.
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

Copy to your README.md:

[![mcp-server-justlend MCP server](https://glama.ai/mcp/servers/justlend/mcp-server-justlend/badges/card.svg)](https://glama.ai/mcp/servers/justlend/mcp-server-justlend)

Score Badge

Copy to your README.md:

[![mcp-server-justlend MCP server](https://glama.ai/mcp/servers/justlend/mcp-server-justlend/badges/score.svg)](https://glama.ai/mcp/servers/justlend/mcp-server-justlend)

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/justlend/mcp-server-justlend'

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