mcp-server-TLD
Server Quality Checklist
Latest release: v1.10.0
- Disambiguation4/5
Most tools have distinct purposes, but there is some overlap among data retrieval tools like get_market_data, get_all_markets, and get_markets_from_api, which provide similar market information from different sources. Descriptions help differentiate, but an agent might still select the wrong one without careful analysis.
Naming Consistency5/5Tool names consistently follow a verb_noun pattern with underscores (e.g., get_wallet_address, approve_underlying, cast_vote). Even longer names like get_markets_from_api and get_jtoken_details_from_api maintain this pattern, making the naming predictable and easy to understand.
Tool Count3/5With 37 tools, the set is somewhat large for a single lending protocol. While many are necessary for comprehensive coverage (including governance and helper tools), some like the multiple market data tools could be consolidated, making the count feel slightly excessive for the apparent scope.
Completeness5/5The tool set covers all core lending operations (supply, withdraw, borrow, repay, collateral management, approvals) plus governance (voting, depositing votes) and utility tools (balance checks, energy estimation). There are no obvious gaps for a user interacting with JustLend protocol.
Average 4.1/5 across 37 of 37 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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 provide readOnlyHint, idempotentHint, and openWorldHint, which cover safety. The description adds context about return contents (interest rate model, reserve info), which is helpful but does not disclose any behavioral traits beyond what annotations already 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loaded with the main action, and provides examples of return content without waste. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions return content (interest rate model, reserve info) but uses 'etc.' which introduces vagueness. Since there is no output schema, a more complete description of the return structure would be beneficial, but for a simple tool it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond the schema descriptions, such as format details or defaults for the network parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets detailed jToken information from an API and returns comprehensive market details. However, it does not explicitly distinguish itself from sibling tools like get_market_data, which may have similar functionality. The 'from API' hint provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_market_data or get_all_markets. The description implies usage when a jToken address is known, but lacks explicit context 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. The description adds no further behavioral context (e.g., on validity of addresses, network behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Remarkably concise at one sentence. Slightly more context could be added, but for a simple tool this is mostly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description omits the return value type. Also does not mention default address behavior, which is in the schema but not captured here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description does not add extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get TRX balance for an address' uses a specific verb and resource, clearly distinguishing it from siblings like 'get_token_balance' which handles other tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as 'get_token_balance' or 'get_account_summary'. The description does not mention preconditions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds little behavioral context beyond stating it 'gets' data. No additional disclosures about auth, rate limits, or 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that front-loads the purpose. No wasted words, but could be slightly more structured (e.g., bullet points for different data types).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description provides minimal context. It names two data types but doesn't specify structure or return format. Adequate but would benefit from listing key fields or noting that results are a single config object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter info; it is clear that the tool takes no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves WBTC mining configuration and supply mining activity details. It distinguishes from similar tools like get_usdd_mining_config and get_mining_rewards by specifying the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_mining_rewards). No context about 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, destructiveHint=false, idempotentHint=true. Description adds no behavioral traits beyond annotations (e.g., no mention of authentication, rate limits, or return format). Adequate but no extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundant words, front-loaded with key action. Extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with full annotation coverage and complete schema, the description is sufficient. However, it could mention default address behavior or return type. Still, it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond what's already in the schema. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the exact action ('get'), the resource ('number of votes'), and the scope ('a user has locked in a specific proposal'). It distinguishes from siblings by making the proposal-specificity obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_user_vote_status or get_vote_info. No when-not-to-use or context 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 indicate readOnlyHint=true and destructiveHint=false, so the description's mention of returning status and details adds some context but is not extensive. It does not cover potential rate limits, authorization requirements, or behavior for empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and include key output details (status, votes, sorting). Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 adequately explains the return values (status, vote counts, details, sorted). It covers defaults for limit and network. Suitable 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value. It mentions defaults (e.g., limit default 10) which are already in the schema. The description does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of governance proposals with status, vote counts, and details, sorted by newest first. It uses a specific verb ('Get') and resource ('proposal list'), distinguishing it from sibling tools like get_vote_info which focus on individual votes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing proposals but provides no explicit guidance on when to use this tool versus alternatives (e.g., for filtered views or specific proposal details). No exclusions or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, which is reinforced by the description's wording 'List'. The description adds that it returns addresses and underlying assets, which is helpful. No contradictions. However, no mention of network filtering behavior or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 14 words, directly describing the tool's purpose. No fluff or redundant information. Front-loaded with the key action 'List all available JustLend lending markets'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 optional param, no output schema), the description is adequate but lacks context about how it differs from similar sibling tools like get_all_markets or get_markets_from_api. Could be more complete by noting this is the canonical way to list supported markets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter 'network', which is already described in the schema. The description does not add any additional meaning beyond the schema's definition. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists all available lending markets (jTokens) and specifies that it includes addresses and underlying assets. This is a specific verb+resource combination that distinguishes it from similar tools like get_all_markets or get_market_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. There are multiple sibling tools for retrieving markets (e.g., get_all_markets, get_markets_from_api), but the description does not explain why an agent should choose this one. No usage context or constraints 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 indicate destructiveHint=true (state change). The description adds that you can add more votes to a previously voted proposal, implying non-idempotent behavior. It does not disclose error conditions (e.g., insufficient votes), permissions, or rate limits. The description adds moderate context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences that front-load the purpose. Every sentence provides essential information: what it does, prerequisites, parameter semantics, and repeatability. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and full schema coverage, the description covers the action, prerequisites, and parameter details. It mentions that you can add more votes, which is important. It doesn't specify return values or error handling, but for a simple vote action, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters. The description adds that votes can be added to an existing vote, which provides extra behavioral context for the 'votes' parameter. However, it largely duplicates the schema for 'support' and doesn't add new detail for 'proposalId' or 'network'. Minimal additional value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cast a vote on a governance proposal.' It specifies the meaning of the 'support' parameter (FOR/AGAINST) and notes the prerequisite of having available votes. This distinguishes it from sibling tools like 'get_user_vote_status' or 'deposit_jst_for_votes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes important usage context: you must have available votes (deposit JST first if needed) and you can add more votes to a proposal already voted on. However, it does not explicitly state when to use this tool versus siblings like 'withdraw_votes_from_proposal' or 'check_jst_allowance_for_voting', nor does it provide alternatives 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?
The description does not add behavioral information beyond annotations. Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description repeats that data is from an API but does not disclose additional traits like rate limits or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and no wasted words. Every sentence adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and annotations covering safety and idempotence, the description provides enough context to understand the return value scope. No output schema exists, but the description hints at the data returned. Could mention pagination or format, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (network) with 100% coverage. The description does not add any meaning beyond the schema, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves the JustLend protocol dashboard from an API and lists specific protocol-level statistics it returns (total supply, total borrow, TVL, etc.). This clearly distinguishes it from sibling tools like get_wallet_address or get_market_data which serve 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for fetching overall protocol metrics but does not explicitly state when to use this tool versus alternative tools like get_protocol_summary or get_all_markets. No guidance on context or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds what data is returned but does not disclose additional behaviors like error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and output, second provides usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key data fields and parameterization method. For a read-only tool with no output schema, it provides sufficient context for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description reinforces the parameter usage with examples, adding marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed market data for a specific JustLend market' and lists the specific fields (APY, TVL, etc.), distinguishing it from sibling tools like get_all_markets and get_supported_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example of usage: 'Use jToken symbol like 'jUSDT' or 'jTRX'', but does not explicitly state when to use this tool versus alternatives like get_all_markets or get_markets_from_api.
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 value by specifying the exact data returned (Comptroller config, close factor, etc.) but does not disclose any additional behavioral traits such as authentication requirements, rate limits, or scope of data (e.g., whether it covers all networks or just the specified one). Given the annotations are strong, the description is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Get JustLend protocol-level info') and lists key contents. Every word is functional with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema, comprehensive annotations), the description is complete enough. It clarifies the scope (protocol-level vs. market-level) and specifies the fields returned. Minor improvement could include noting that results are for a given network, but the schema already addresses that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (network) with a description ('Network. Default: mainnet'), providing 100% schema coverage. The tool description does not add any additional meaning beyond that. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves JustLend protocol-level information including specific fields (Comptroller config, close factor, liquidation incentive, total markets). It uses a specific verb ('Get') and identifies the resource ('protocol-level info'), distinguishing it from sibling tools like get_market_data which focus on individual markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for protocol-level summary data via the phrase 'protocol-level info', but it does not explicitly state when to use it versus alternatives like get_market_data or get_all_markets. No when-not or exclusion criteria are provided. Usage is inferred but not directly guided.
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?
Description is consistent with annotations (readOnlyHint, idempotentHint) but adds no extra behavioral details beyond what annotations already 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficiently complete for a simple 0-parameter tool with clear annotations; no output schema but listing networks is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so baseline 4 applies; description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and the resource 'supported TRON networks for JustLend', distinguishing it from sibling tools like get_supported_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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; lacks explicit when-to-use or when-not-to-use 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 declare readOnlyHint=true and destructiveHint=false, so the description adds value by explaining how mining APY is calculated and the formula for totalSupplyAPY, providing context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant words. Could be slightly more structured but is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the data points included (APYs, TVL) and the mining APY calculation. It does not mention pagination or limits, but for an overview of all markets this is likely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 elaborate on the 'network' parameter but does not conflict with it; no added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('overview data for ALL JustLend markets'), listing key fields (supply APY, borrow APY, etc.). This clearly distinguishes it from sibling tools like get_market_data (single market) or get_dashboard_from_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description strongly implies use when market-wide overview is needed via 'ALL', but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like get_supported_markets or get_market_data.
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 that it's a read-only check and idempotent (implied by 'check'), but does not need to repeat annotation content. With rich annotations, the description adds moderate value by specifying TRC20 context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the core purpose, then provides usage context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and schema richness, the description is complete enough. It explains the prerequisite context (supply/repay) and edge case (jTRX not needed). No output schema, so return values are not expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description adds minimal extra detail (e.g., default address and network behavior), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a TRC20 token is approved for a jToken market, using the verb 'check' and specifying the resource. It distinguishes from siblings by noting it is needed before supply/repay and not required for jTRX.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says when to use (before supply/repay for TRC20 markets) and when not (not for jTRX). It does not explicitly name alternative tools, but the context of usage is 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Description adds context about the voting contract and prerequisite, but behavioral traits are well-covered by 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Purpose is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only check with rich annotations and no output schema, the description is sufficient. Provides necessary context about the voting contract prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. Description adds no additional parameter meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks if JST is approved for the WJST voting contract, with a specific verb and resource. It distinguishes from sibling tools like approve_jst_for_voting and deposit_jst_for_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it must be used before depositing JST, providing clear when-to-use guidance. Does not explicitly mention when not to use, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about stability and comprehensiveness, and lists return data types. This is adequate given the annotations, though no additional behavioral constraints 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences. The first sentence immediately states the core purpose, and the second adds comparative value and enumerates return data. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must cover what is returned. It lists key data points (lending positions, balances, mining rewards, health factor, etc.), providing sufficient context. A more exhaustive list would improve completeness, but 'etc.' is acceptable for a high-level description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 extra meaning beyond what the schema already provides for the two parameters. The description's mention of 'Leave empty to use configured wallet' is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get user account data from JustLend API.' It specifies the data source and lists returns. It distinguishes from contract queries, and the sibling context shows many get_* tools, but this one is focused on account data from the API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a comparative statement: 'More stable and comprehensive than contract queries,' which guides when to use this tool over contract-based alternatives. However, it does not explicitly compare to other API-based siblings like get_account_summary, leaving some ambiguity.
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 and idempotentHint=true, indicating safe read operations. The description adds value by specifying exactly what data is returned (supply balances, borrow balances, health factor, etc.), which supplements 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the purpose and lists key data fields. Every word adds value, with no redundancy or wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 optional parameters and no output schema. The description lists the returned fields (supply balances, borrow balances, etc.) but could benefit from additional detail on output structure, formatting, or edge cases. However, it is 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both parameters (address, network) are fully documented in the input schema. The description does not add additional meaning or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a comprehensive view of a user's JustLend positions' and lists specific data fields (supply balances, borrow balances, etc.). It distinguishes from sibling tools like get_market_data (specific market) or get_protocol_summary (protocol-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a full account overview but does not explicitly state when to use this tool versus alternatives like get_market_data or get_all_markets. No when-not-to-use or alternative 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 indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the tool returns specific reward details from an API, enhancing transparency without contradictory 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the purpose, no wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 optional parameters and no output schema. The description covers return values (unclaimed rewards, APY, breakdown) but lacks response format details. Adequate for a read-only query with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description does not add further parameter semantics beyond the 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/5Does 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 'mining rewards', specifies the scope (supply markets like USDD, WBTC), and lists return contents (unclaimed rewards, mining APY, reward breakdown). This distinguishes it from sibling claim_rewards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like claim_rewards or get_market_data. The purpose is clear, but there is no when-not-to-use or mention of 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 readOnly and idempotent behavior. The description adds value by detailing the exact information returned (proposals voted on, vote amounts, withdrawable votes) and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with the main action front-loaded. Every word adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description is reasonably complete, covering the key outputs. However, it does not mention potential pagination, limits, or whether all proposals (past and active) are included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any information about the parameters beyond what the schema provides (address defaults to configured wallet, network defaults to mainnet).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'user's voting status across all governance proposals', specifying what information is returned (vote amounts, withdrawable votes). It distinguishes from sibling tools like get_vote_info by covering all proposals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking a user's overall voting status but does not explicitly state when to use this tool versus alternatives like get_vote_info, get_locked_votes, or cast_vote. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, specifically the typical cost ('~90,000 energy + ~300 bandwidth'). It also confirms the destructive nature (all assets withdrawn). No contradictions with annotations (destructiveHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a cost note. Every word is essential, no redundancy. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values (e.g., transaction hash, status). While the action is simple, without an output schema, the description should briefly mention what to expect as a result. Otherwise, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds no further meaning beyond what the schema provides (e.g., 'jToken symbol (e.g. 'jUSDT')' is already in 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Withdraw ALL supplied assets'), the resource ('JustLend market'), and the mechanism ('redeeming all jTokens'). It effectively distinguishes from sibling tools like 'withdraw' (partial) and 'supply'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for full withdrawal only, but does not explicitly state when to use this tool versus the partial withdrawal sibling 'withdraw'. No when-not or alternatives are given, but the purpose is clear enough.
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 the description adds critical context: the proposal must be non-active, and votes become available again. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each conveying essential information without fluff. The description is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers prerequisites (inactive proposal), effects, and postconditions. It could mention return values, but overall it's complete for a withdrawal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond the schema. It repeats the parameter purpose but does not provide additional details like format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'withdraw' and resource 'votes from a proposal', specifying 'completed or canceled' proposals, which distinguishes it from siblings like 'withdraw_votes_to_jst' and 'cast_vote'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the condition 'Only works for proposals that are no longer active' and explains the outcome for alternative uses. It could be more explicit about when not to use, but it's 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 indicate mutation (readOnlyHint=false). The description adds valuable behavioral insight by disclosing the typical resource cost (energy and bandwidth), which is beyond what the annotations provide and aids in decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the purpose and one providing cost details. Every word is necessary, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 core purpose and cost. It lacks mention of the effect (transfer to wallet) but this is implied. Overall, it is fairly complete 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'network' is fully described in the schema (100% coverage) with a default value. The tool description does not add additional meaning about the parameter, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'claim' and the resource 'accrued JustLend mining rewards', making the action specific and distinct from sibling tools like get_mining_rewards which only read 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for claiming rewards and provides cost information (~60,000 energy + ~330 bandwidth) to help the agent decide if it can proceed. However, it does not explicitly mention when not to use or suggest checking rewards first with get_mining_rewards.
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 readOnlyHint=false and destructiveHint=true, consistent with the description's 'Deposit' mutation. The description adds behavioral context: it requires prior approval, describes the voting power rate (1 JST = 1 Vote), and mentions reversibility (withdrawable). This goes beyond annotations by specifying the prerequisite and outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover purpose, prerequisite, and key details (rate and reversibility). No redundant or irrelevant information. Every sentence adds value, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, prerequisites, and outcome. It lacks details on error behaviors (e.g., insufficient balance) or return values, but given the simplicity of the tool (2 parameters, no output schema), the content is largely complete. Missing minor context prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('amount' and 'network') with 100% coverage. The description does not add any further parameter details beyond what the schema gives, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Deposit JST into the WJST contract to get voting power.' It identifies the specific resource (WJST contract) and the purpose (voting power), distinguishing it from sibling tools like approve_jst_for_voting or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use approve_jst_for_voting first as a prerequisite, guiding when to call this tool. It also notes that deposited JST can be withdrawn later, providing context on the lifecycle. However, it does not explicitly state when not to use this tool (e.g., if insufficient allowance).
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, so the safety profile is covered. The description adds behavioral context by detailing the config contents (mining periods, reward tokens, schedule), which aids understanding of what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (18 words) that front-loads the action and resource. Every word adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a reasonable overview of the config contents (mining periods, reward tokens, schedule). For a read-only, parameterless tool, this is sufficient to inform the agent of what data will be returned, though additional structure details could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter semantics, but the baseline for zero parameters is 4. No additional value is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'USDD mining configuration', listing specific contents (mining periods, reward tokens, schedule). This provides direct purpose and distinguishes from sibling tools like get_wbtc_mining_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving USDD mining config, but does not explicitly state when to use this tool versus alternatives (e.g., get_wbtc_mining_config) or provide exclusion criteria. It is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds value by detailing the specific data returned (wallet balance, surplus votes, etc.). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and outputs, second provides usage context. No extraneous words. Highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (read-only, optional params, no output schema). The description lists the key return data points and usage context, which is sufficient for an agent to decide when to call it. Lacks detail on return format but acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions (address: TRON address, network: Network), achieving 100% schema coverage. The description does not add new details beyond referring to 'a user', which maps to address. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'voting power info', listing specific data returned (JST balance, surplus votes, deposited votes, cast votes). It distinguishes itself from siblings by positioning it as 'the key tool to check before voting', implying a specific 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it: 'to check before voting'. It indicates it shows available votes, which is the primary use case. However, it does not explicitly exclude alternatives or mention 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations by noting possible failure if assets are used as collateral and specifying typical cost in energy and bandwidth, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, front-loaded with purpose, and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main risks (collateral blockage), cost, and required parameters, though lacks explicit mention of output or immediate effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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's mention of 'underlying units' does not significantly add beyond the schema example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('withdraw'/'redeem') and resource ('supplied assets from a JustLend market'), and distinguishes itself from sibling tools like 'supply' and 'borrow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context such as amount units and potential failure due to collateral, but does not explicitly contrast with alternatives like 'withdraw_all'.
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 idempotent and non-destructive write operation. Description adds the 'amount=max' tip and clarifies the approval action, going beyond the annotations 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and purpose, zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no output schema. Description covers purpose, prerequisite, and a usage tip, fully adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters at 100%. Description adds minor value by reinforcing the 'max' option for amount, but network parameter and details like format are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Approve' and resource 'JST token for the WJST voting contract', clearly distinguishing it from siblings like check_allowance and deposit_jst_for_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Required before depositing JST to get voting power', providing clear when-to-use context. Does not explicitly exclude other scenarios, but the prerequisite relationship is well conveyed.
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 context beyond annotations by stating the wallet is 'configured' and used for 'all lending operations,' which helps the agent understand the significance and scope. No contradictions with annotations (readOnlyHint, idempotentHint, destructiveHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The first sentence states the action and resource, the second adds context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool that returns a single wallet address, the description is complete. It explains what it retrieves and its relevance to lending operations. No output schema is needed as the return is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter details; the baseline score of 4 is appropriate as the description adds no confusion and the purpose is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get') and the resource ('configured wallet address'), and distinguishes the tool by noting its use in lending operations, which differentiates it from sibling tools like get_token_balance or get_account_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing the wallet address for lending operations, but provides no explicit guidance on when to use versus alternatives like get_account_summary or other getters. The simplicity of the tool (no parameters) reduces the need for elaborate 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?
The description adds significant behavioral context beyond annotations: returns a jToken balance, typical energy and bandwidth costs, and prerequisite approval for TRC20. Annotations indicate destructiveHint and not idempotent, consistent with a deposit operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and well-structured: purpose, prerequisite, return value, cost info. It is front-loaded and contains no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial transaction tool with no output schema, the description covers purpose, prerequisites, return value, costs, and references an estimation tool. It could be improved by explaining error cases or authorization details, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for amount (example format), market (jToken symbol), and network (optional, default mainnet). The tool description adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Supply (deposit)'), the resource ('JustLend market'), and the purpose ('earn interest'). It distinguishes the tool from siblings like borrow, withdraw, and repay by specifying the deposit 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: requiring approve_underlying for TRC20 markets, direct TRX for jTRX, and referencing estimate_lending_energy for cost estimation. It does not explicitly state when not to use the tool, but the sibling context from tool names provides differentiation.
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 behavioral context beyond annotations: it notes the typical cost (~100,000 energy + ~313 bandwidth) and the need to check health_factor, complementing destructiveHint=true and readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the main purpose, prerequisites, and cost information, with no wasted words or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main aspects: what the tool does, prerequisites, and cost. Though it lacks details about return values, it is adequate for typical use given the schema covers parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage), so the description adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Borrow assets') and resource ('from a JustLend market against your collateral'), clearly distinguishing it from sibling tools like supply, withdraw, or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites: must have entered a market as collateral and sufficient liquidity, and advises checking account_summary and health_factor before borrowing. It does not explicitly mention when not to use or alternatives, but provides sufficient context for safe usage.
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 stability advantage and lists specific return fields (APY, TVL, etc.), adding value beyond annotations (readOnlyHint, idempotentHint). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words. First sentence states purpose, second adds context and return details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return data adequately for a simple read tool with one optional parameter. Lacks mention of potential errors or limits, but annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the network parameter. The tool description adds no extra parameter information, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get all market data from JustLend API' with specific verb and resource. Distinguishes from siblings like get_market_data or get_all_markets by emphasizing bulk data from a stable API source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage hint: 'More stable than contract queries,' indicating when to prefer this tool. Could be improved by explicitly stating when not to use it or listing alternatives, but the guidance is helpful.
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 (write operation). The description adds value by disclosing the need for prior approval on TRC20, the 'max' special value, and typical energy/bandwidth costs, which go beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: stating the main action, providing a prerequisite, and giving a usage tip with typical costs. No filler, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, prerequisites, special input values, and costs. It does not explain the result of the action (e.g., reduced borrow balance), but given the lack of output schema, this is acceptable and sufficient 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already covers 100% of parameters with descriptions, the tool description adds extra meaning: it explains the special 'max' value for amount and provides cost context that helps the agent interpret the parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Repay' and resource 'borrowed assets to a JustLend market', which is specific and distinct from sibling tools like borrow or withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool (repaying borrows), includes a prerequisite for TRC20 markets ('must have approved underlying first'), and provides practical guidance on using 'max' and typical costs. It does not explicitly state when not to use it, 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 indicate destructiveHint=true and readOnlyHint=false, so the mutation nature is clear. The description adds the important behavioral detail about the locked-vote restriction, but does not elaborate on return values or side effects beyond the expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states purpose, second adds constraint, third advises a prerequisite. Every sentence is informative and there is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool without an output schema, the description covers purpose, constraints, and prerequisite. The only omission is a mention of what the tool returns (e.g., transaction hash), but given the tool's simplicity and the context of sibling tooling, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (amount and network) are described in the schema. The description does not add new semantic information beyond the schema, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (withdraw WJST back to JST) and specifies a constraint (only votes not locked in active proposals). It differentiates itself from sibling tools like 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (only for free votes) and advises checking surplus with get_vote_info first, providing clear guidance on prerequisites 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?
Description adds significant behavioral context beyond annotations: it discloses typical cost (~23,000 energy + ~265 bandwidth) and the fact that the call is required before supply/repay. No contradiction with annotations: readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false all align.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that concisely convey the purpose, prerequisites, and a usage hint. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 what the tool does, when to use it, and includes practical details (cost, 'max' usage). It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds only the note about amount='max' for unlimited approval, which is also in the schema description. The cost information is not parameter-specific. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: approve jToken contract to spend underlying TRC20 tokens. It specifies the context (required before supply/repay for TRC20-backed markets, not for jTRX), providing a specific verb and resource with necessary differentiation from siblings 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states when to use (before supply/repay for TRC20-backed markets) and when not (not for jTRX). It lacks explicit mention of alternatives but the context is clear given sibling tools like supply and repay. The hint about using 'max' for unlimited approval adds usage 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?
The description adds valuable behavioral context beyond annotations: it states the cost (energy + bandwidth), which is critical for the agent to estimate resource usage. Annotations already indicate idempotent and non-destructive, and the description aligns with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences cover the purpose, prerequisite, effect, and cost with no fluff. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only two parameters, the description fully informs the agent about action, prerequisite, effect, and cost. No gaps remain for using this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented clearly. The description does not add extra parameter-level details 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables a jToken market as collateral and explains its role as a prerequisite for borrowing. It distinguishes from siblings like exit_market by emphasizing the borrowing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is 'required before borrowing' and explains the effect on borrowing capacity, providing clear usage guidance. It does not explicitly mention alternatives, but the sibling tool list includes exit_market which is the inverse.
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 (destructiveHint=true), the description adds valuable behavioral details: it fails if undercollateralized, and provides typical energy/cost estimates. This informs the agent of consequences and preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information: action, failure condition, safety tip, and cost. No redundant or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with safety implications, the description covers the core action, failure mode, precondition, and cost. No output schema is present, but return values are straightforward and need not be detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already well-described in the schema. The description adds no additional meaning to 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool disables a jToken market as collateral. It uses a specific verb ('disable') and identifies the resource ('jToken market as collateral'), distinguishing it from sibling tools like supply or borrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it will fail if it would cause undercollateralization and advises to check account_summary first. This provides clear context for when to use the tool, though it does not name the alternative (enter_market) explicitly.
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 declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds crucial behavioral details: it tries on-chain simulation first, falls back to historical values, provides a per-step breakdown, and automatically checks allowance for supply/repay. This goes well 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured and front-loaded with the core purpose. Every sentence adds value, though a few details (e.g., 'Covers ALL operations...') could be implied. Overall, it balances completeness with readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains what the tool returns (per-step breakdown, total energy, bandwidth, TRX cost) and covers edge cases like fallback and allowance checks. It leaves no significant gaps for an agent to make mistakes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are documented in the schema, but the description adds extra context: default values for amount ('1'), address (configured wallet), network (mainnet), and notes that spender is only used for 'approve'. It clarifies which operations don't need amount, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 9 operations (supply, withdraw, etc.) and explicitly contrasts with execution tools by saying 'BEFORE executing it', distinguishing from sibling tools like supply or borrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'whenever the user asks about gas/energy/cost for any lending operation'. It provides context on fallback behavior and automatic allowance checks for supply/repay. It does not explicitly list when not to use, but the broad coverage and clear purpose make it unambiguous.
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 readOnlyHint annotations, description reveals that balances are already formatted (decimals applied), avoiding common error of re-dividing. Also warns about deprecated addresses and automatic symbol resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured paragraph with clear purpose, usage guidance, and important warnings. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only balance tool with 4 optional parameters and no output schema, description covers token selection, address usage, return format, and deprecation warnings comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers descriptions (100%), but description adds practical guidance: prefer token over tokenAddress, automatic resolution, deprecation warning for USDD. Adds value over raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets TRC20 token balances for an address, specifying token symbol or contract address. It distinguishes itself from sibling tools like get_trx_balance (for TRX) by focusing on TRC20 tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer token symbols over raw addresses to avoid deprecated contracts, e.g., USDD. Implicitly distinguishes from related tools (get_trx_balance, check_allowance) but no explicit 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.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/bbsyaya/mcp-server-tld'
If you have feedback or need assistance with the MCP directory API, please join our Discord server