Armor Crypto MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools cover distinct areas like wallets, groups, orders, swaps, and staking, but there is some overlap. For example, 'search_official_token_address' and 'search_token_details' both search for token information, and 'cancel_dca_order' and 'cancel_order' both cancel orders, which could cause confusion. However, the descriptions help clarify their specific purposes.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., 'create_wallet', 'list_groups', 'archive_wallets'), but there are minor deviations like 'calculator' (noun only) and 'wait_a_moment' (verb phrase). Overall, the naming is predictable and readable, with only a few inconsistencies.
Tool Count2/5
With 37 tools, the count is excessive for a crypto wallet server, making it heavy and potentially overwhelming. While the domain is broad, many tools could be consolidated (e.g., multiple archive/unarchive tools) or omitted (e.g., 'get_current_time', 'wait_a_moment'), leading to a bloated interface.
Completeness4/5
The tool set provides comprehensive coverage for crypto wallet management, including CRUD operations for wallets and groups, trading (orders, swaps), staking, and token analysis. Minor gaps exist, such as no direct tool for editing wallet details beyond renaming, but agents can work around this with existing tools.
Average 2.8/5 across 37 of 37 tools scored. Lowest: 1.1/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 GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but fails completely. It doesn't indicate whether this is a read or write operation, what permissions are required, whether the cancellation is reversible, what happens to funds in a DCA order, or what the response looks like. The description actually misrepresents the tool's behavior by suggesting creation rather than cancellation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While brief (two sentences), the description is not appropriately structured. The first sentence is factually incorrect, and the second sentence adds confusion rather than clarity. The brevity comes from under-specification rather than efficient communication. The description fails to front-load the actual purpose of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a financial operation (canceling DCA orders) with no annotations, 0% schema coverage, and a misleading description, this is completely inadequate. While an output schema exists, the description doesn't provide the basic context needed to understand what the tool does, when to use it, or how to structure the request. The presence of sibling tools like 'cancel_order' and 'list_dca_orders' makes the incompleteness even more problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 1 parameter, the description provides no meaningful information about the 'cancel_dca_order_requests' parameter. It mentions 'dca_order_requests' but doesn't explain what this container should contain, how to specify which DCA orders to cancel, or what format the requests should take. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a DCA order' directly contradicts the tool name 'cancel_dca_order', creating confusion about whether this tool creates or cancels orders. The note about 'Make a single or multiple dca_order_requests' further compounds the confusion by suggesting creation rather than cancellation. This is misleading and fails to state the actual purpose of the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention the sibling tool 'cancel_order' (which might handle different types of orders) or 'list_dca_orders' (which might help identify orders to cancel). There's no indication of prerequisites, timing considerations, or when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose critical behavioral traits: it doesn't mention security risks (e.g., exposing private keys), authentication needs, rate limits, or what the output might be. The description is dangerously incomplete for a tool handling sensitive data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it's under-specified rather than efficiently informative. It front-loads the action but lacks necessary details. While not verbose, it fails to earn its place by omitting critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (sensitive operation with 1 parameter, 0% schema coverage, no annotations, but has output schema), the description is severely incomplete. It doesn't address security implications, usage context, or parameter details, making it inadequate for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'mnemonic or private key' but doesn't explain the 'private_key_request' parameter's structure, format, or requirements. No additional meaning is provided beyond the vague reference, leaving the parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Send') and target ('to telegram'), but it's vague about what exactly is being sent ('the mnemonic or private key') without specifying the purpose or context. It doesn't distinguish from siblings like 'transfer_tokens' or 'create_wallet', which might involve similar security-sensitive operations. The description is not tautological but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given siblings like 'transfer_tokens' or security-related tools, there's no indication of prerequisites, risks, or appropriate contexts. The description is misleading as it implies sending sensitive data without safety warnings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Rename wallets' implies a mutation operation but doesn't disclose whether this requires specific permissions, whether the rename is reversible, what validation occurs, or what happens to wallet identifiers. The mention of returning 'a list' is the only behavioral hint, but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) but this brevity comes at the cost of being under-specified rather than efficient. The first sentence is tautological, the second provides minimal technical detail. While not wordy, it fails to convey necessary information that would help an agent use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 1 parameter (0% schema coverage), no annotations, but with an output schema, the description is severely incomplete. While the output schema may document return values, the description fails to explain the core operation, its behavioral implications, parameter requirements, or usage context. The presence of an output schema doesn't compensate for these fundamental gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides almost no parameter information. It mentions 'Expects a RenameWalletRequestContainer' which names the parameter but gives no semantic meaning - what this container should contain, what fields are needed, or what 'rename' actually requires. The description adds minimal value beyond what the bare schema structure provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Rename wallets' which is a tautology that merely restates the tool name without adding specificity. It doesn't clarify what type of wallets (crypto, digital, etc.) or what the rename operation entails. Compared to sibling tools like 'create_wallet' or 'archive_wallets', this provides minimal differentiation beyond the obvious verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when renaming is appropriate, what happens to existing wallet references, or how this differs from related operations like creating or archiving wallets. The agent receives zero contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. 'Execute' implies a write/mutation operation, but it doesn't disclose permissions needed, whether it's irreversible, rate limits, or what happens on success/failure. The description mentions input/output container types but doesn't explain their significance or behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences, and the first sentence directly states the action. However, the second sentence about input/output containers feels technical without adding user-facing value, slightly reducing efficiency. Overall, it's brief but under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction execution tool with no annotations, 0% schema coverage, but with an output schema, the description is incomplete. It doesn't explain the mutation nature, security implications, or practical usage context. While the output schema might document return values, the description fails to provide necessary operational context for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so adequately. It mentions 'StakeTransactionRequestContainer' as the expected parameter but provides no semantic explanation of what this container contains, what fields are required, or what values are valid. For a single parameter tool with zero schema documentation, this leaves critical gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute a stake transaction' is a tautology that essentially restates the tool name 'stake_transaction' without adding meaningful specificity. It doesn't clarify what 'stake' means in this context, what resources are involved, or how it differs from sibling tools like 'stake_quote' or 'unstake_transaction'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or differentiate from related tools like 'stake_quote' (which likely provides a quote) or 'unstake_transaction' (which likely reverses the operation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. 'Create' implies a write operation, but it does not disclose permissions needed, side effects, error conditions, or rate limits. It mentions input/output types but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. However, the second sentence is somewhat redundant with the schema and could be more informative, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with no annotations and 0% schema coverage, the description is inadequate. It does not explain what a DCA order is, its purpose, or how it interacts with the system, despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names the parameter (DCAOrderRequestContainer) but does not explain its structure, required fields, or semantics. This adds minimal value beyond the schema, warranting a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a DCA order' restates the tool name without adding specificity. It mentions the input type (DCAOrderRequestContainer) and output (list of DCAOrderResponse), but does not explain what a DCA order is, what resource it creates, or how it differs from sibling tools like create_order or cancel_dca_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or comparisons to sibling tools like create_order or list_dca_orders, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the input/output containers but doesn't describe what the tool actually does behaviorally: whether it's a blockchain transaction submission, if it requires confirmation, what happens to the staked assets, potential fees, irreversible nature, or any side effects. 'Execute' implies a write/mutative operation, but no further behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the action and input/output types. There's no wasted text or unnecessary elaboration. However, the extreme brevity comes at the cost of completeness, making it more under-specified than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a financial transaction tool with no annotations, 0% schema coverage, but with an output schema, the description is incomplete. It doesn't explain the unstaking operation's purpose, risks, or workflow context. While the output schema may document the return structure, the description fails to provide necessary context about what 'unstake' means, when to use it, or what behavioral outcomes to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only states 'Expects a UnstakeTransactionRequestContainer' without explaining what this container contains, what fields are needed, or what unstaking parameters are required. This adds minimal value beyond the schema's structural information. For a single parameter tool with 0% schema coverage, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Execute[s] an unstake transaction', which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'unstake_quote' or explain what 'unstake' means in this context. The purpose is understandable but lacks specificity about the financial/blockchain operation involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There's no mention of prerequisites (like needing a staked position first), when-not-to-use scenarios, or comparison to related tools like 'unstake_quote' (which likely provides a quote before execution) or 'stake_transaction' (the opposite operation). The description assumes the user already knows when unstaking is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the input/output container types without behavioral details. It doesn't disclose permissions needed, rate limits, side effects (e.g., fund deductions), or error conditions, which are critical for a mutation tool like order creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, but the second sentence about input/output containers adds minimal value without elaboration. It avoids redundancy but could be more informative given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (order creation with financial implications), no annotations, and 0% schema coverage, the description is incomplete. While an output schema exists, the description lacks crucial context like authentication needs, order constraints, or error handling, making it minimally adequate but with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only names the parameter ('CreateOrderRequestContainer') without explaining its structure, required fields, or semantics. This fails to compensate for the lack of schema documentation, leaving the parameter meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates an order and lists three specific types (limit, take profit, stop loss), which provides a clear verb and resource scope. However, it doesn't differentiate from sibling tools like 'create_dca_order' or 'cancel_order', leaving ambiguity about when to use this versus those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_dca_order' or 'cancel_order'. The description only states what it does without context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool expects a CandleStickRequest and returns a list of candle sticks, but doesn't disclose critical traits like whether it's read-only, requires authentication, has rate limits, or what 'candle sticks' represent (e.g., time-series data). The description adds minimal context beyond basic input-output, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded: the first states the purpose, and the second covers input-output. There's no wasted text, but it could be more structured by elaborating on key details. It's appropriately sized for a simple tool but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with 0% schema coverage, no annotations, but an output schema exists (which reduces the need to explain return values), the description is incomplete. It covers basic input-output but lacks details on parameter semantics, behavioral traits, and usage context. It's minimally adequate but has clear gaps for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and there is 1 parameter ('candle_stick_requests') with a nested reference to CandleStickRequest. The description mentions 'Expects a CandleStickRequest' but doesn't explain what this request entails (e.g., token identifiers, time ranges, intervals). It adds minimal meaning beyond the schema, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get candle data about any token for analysis' which provides a clear verb ('Get') and resource ('candle data about any token'), but it's vague about what 'candle data' specifically entails and doesn't distinguish from siblings like 'get_top_trending_tokens' or 'search_token_details' that might also provide token-related data. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare to sibling tools such as 'get_all_orders' or 'search_token_details' that might serve similar analytical purposes. Usage is implied only by the name and description, with no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Expects a list of wallet names, returns a list of WalletArchiveOrUnarchiveResponse', which gives basic input/output expectations. However, it doesn't describe what 'archive' entails (e.g., whether it's reversible, requires permissions, affects wallet functionality, or has side effects), leaving critical behavioral traits unspecified for a mutation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded: the first states the purpose, and the second covers input/output. There's no wasted text, but it could be more structured (e.g., separating usage notes). It's appropriately sized for a simple tool, though slightly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 1 parameter, no annotations, but an output schema), the description is minimally adequate. The output schema exists, so the description needn't detail return values, but it lacks context on archival behavior, error handling, or sibling differentiation. It covers basics but leaves significant gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It states that the tool 'Expects a list of wallet names', which clarifies the parameter 'archive_wallet_requests' as containing wallet names. However, it doesn't explain the structure of 'ArchiveWalletsRequestContainer' (e.g., format of wallet names, validation rules, or batch limits), leaving gaps. The description adds some meaning but doesn't fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Archive wallets', which is a clear verb+resource combination. However, it doesn't distinguish this tool from its sibling 'archive_wallet_group' or 'unarchive_wallets', leaving ambiguity about whether this archives individual wallets versus groups. The purpose is understandable but lacks sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'archive_wallet_group', 'unarchive_wallets', and 'create_wallet', there's no indication of prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the return type ('list of orders') but doesn't cover critical aspects like pagination, rate limits, authentication requirements, or whether this is a read-only operation (implied by 'retrieve' but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences that directly state the action and return value. It's front-loaded with the main purpose, though it could be more structured by explicitly separating purpose from output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which handles return values) and no annotations, the description is minimally adequate but incomplete. It covers the basic purpose but fails to address parameter semantics, usage context, or behavioral details needed for a tool with undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the single required parameter 'get_all_orders_requests'. The description doesn't explain what this parameter expects, its format, or its purpose, leaving the parameter completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'limit, take profit and stop loss orders', making the purpose understandable. However, it doesn't distinguish this tool from potential sibling order-related tools like 'list_dca_orders' or 'cancel_order', which would require more specific 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_dca_orders' or 'cancel_order'. The description lacks context about prerequisites, timing, or comparison with other order-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning 'a list of Wallets and assets', which gives basic output info, but lacks critical behavioral details: whether this is a read-only operation, if it requires authentication, any rate limits, pagination for large result sets, or error conditions. The misspelling 'asssets' undermines clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but inefficiently structured. The first sentence states the purpose clearly, but the second is redundant with the output schema and contains a typo ('asssets'). It could be condensed into a single, error-free sentence without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and an output schema (which handles return values), the description is minimally adequate but incomplete. It covers the basic purpose and output type but misses parameter documentation and behavioral context, making it insufficient for reliable tool invocation without external schema inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all, despite there being 1 required parameter ('get_all_wallets_requests'). The description fails to explain what this parameter does, its expected format, or how it influences the retrieval, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('all wallets with balances'), making the purpose understandable. It distinguishes from siblings like 'get_wallet_token_balance' (single wallet) and 'list_groups' (different resource). However, it doesn't explicitly differentiate from 'get_all_orders' or other list-style tools beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for retrieving all wallets, or compare to siblings like 'list_groups' or 'get_wallet_token_balance' for specific needs. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions 'returns a list of SwapQuoteResponse', which hints at output format, but lacks details on rate limits, authentication needs, error conditions, or whether this is a read-only operation (implied by 'retrieve' but not explicit). The 'Be sure to add slippage!' is a useful constraint but insufficient for comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (three sentences) and front-loaded with the core purpose, but the second sentence ('Be sure to add slippage!') is somewhat vague and could be integrated more smoothly. It avoids redundancy but under-specifies key details, making it more sparse than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and an output schema exists (so return values are documented elsewhere), the description is incomplete. It identifies the tool's purpose and hints at a parameter requirement but lacks sufficient detail on input semantics and behavioral context for a tool involving financial quotes, leaving gaps in usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but does poorly. It names 'SwapQuoteRequestContainer' as the expected parameter but provides no explanation of what this contains (e.g., tokens, amounts, slippage). The 'Be sure to add slippage!' hints at a required field but doesn't clarify parameter structure or semantics beyond the schema's bare reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Retrieve a swap quote' (verb+resource), which is specific and unambiguous. It distinguishes from siblings like 'swap_transaction' (execution vs. quote) and 'stake_quote' (different operation). However, it doesn't explicitly differentiate from 'unstake_quote' or other quote tools beyond the 'swap' prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Be sure to add slippage!' which hints at a required parameter consideration but doesn't explain when to use this tool versus alternatives like 'swap_transaction' or 'stake_quote'. No explicit when/when-not rules or prerequisite context is provided, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'Execute[s] a swap transaction', implying a write/mutation operation, but doesn't disclose critical details like authentication needs, rate limits, side effects, or error handling. This is a significant gap for a transactional tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences that directly state the action and input/output. There's no fluff, and it's front-loaded with the core purpose. However, it could be more structured by including usage hints, but within its brevity, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a swap transaction likely involves financial operations), no annotations, and 0% schema coverage, the description is incomplete. It mentions the output ('returns a list of SwapTransactionResponse'), which aligns with the presence of an output schema, but fails to cover behavioral aspects or parameter details adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Expects a SwapTransactionRequestContainer', adding some context beyond the schema's generic parameter name. However, it doesn't explain what this container includes or how to structure it, leaving key semantics undocumented. Baseline 3 is appropriate as it adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Execute[s] a swap transaction', which provides a clear verb ('Execute') and resource ('swap transaction'). However, it doesn't differentiate from sibling tools like 'swap_quote' or 'transfer_tokens', leaving the specific scope ambiguous. The purpose is understandable but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'swap_quote' (which likely provides a quote without execution) or 'transfer_tokens' (which might handle simple transfers). There's no mention of prerequisites, context, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it 'Expects a list of group names, returns a list of GroupArchiveOrUnarchiveResponse', which gives some context about input/output, but fails to describe critical behaviors like whether unarchiving is reversible, requires permissions, has side effects, or involves rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point with two sentences that cover the action and input/output expectations. There's no unnecessary fluff, and it's front-loaded with the main purpose. However, it could be slightly more structured by explicitly separating usage notes from behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and low schema coverage, the description is minimally complete. It covers the basic action and input/output but lacks depth on behavioral aspects, error handling, or integration with sibling tools, making it adequate but with clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic value beyond the input schema. It specifies that the tool 'Expects a list of group names', which clarifies the parameter's purpose, but with 0% schema description coverage and 1 parameter, this doesn't fully compensate for the lack of schema details. The baseline is 3 since it provides some context, but more details on the request format would be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Unarchive wallet groups' which provides a clear verb ('Unarchive') and resource ('wallet groups'), but it doesn't specify what unarchiving entails or differentiate it from sibling tools like 'unarchive_wallets' or 'archive_wallet_group'. The purpose is understandable but lacks specificity about scope or effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'unarchive_wallets' or 'archive_wallet_group'. The description only states what it does without context about prerequisites, timing, or comparisons to sibling tools, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the input format ('list of wallet names') and output type ('WalletArchiveOrUnarchiveResponse'), but lacks critical details: whether this requires specific permissions, if it's reversible, what happens to archived data, or any rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. Both sentences add value: the first states the purpose, the second specifies input and output. There's no redundant information, though it could benefit from more detail given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), the description doesn't need to explain outputs. However, for a mutation tool with no annotations and 0% schema coverage, the description is incomplete: it lacks error handling, side effects, and usage context. It provides a basic framework but misses key operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that the parameter expects 'a list of wallet names', adding meaning beyond the schema's generic 'UnarchiveWalletRequestContainer'. However, it doesn't explain the structure of this list (e.g., format, constraints, or what constitutes a valid wallet name), leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('unarchive') and resource ('wallets'), making the basic purpose clear. However, it doesn't differentiate from the sibling tool 'unarchive_wallet_group', leaving ambiguity about whether this tool handles individual wallets versus groups. The purpose is stated but lacks specificity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'unarchive_wallet_group' or 'archive_wallets'. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the input and output types ('UnstakeQuoteRequestContainer' and 'SwapQuoteRequestContainer'), but fails to describe what the tool actually does behaviorally—such as whether it's a read-only operation, if it has side effects, rate limits, or authentication needs. This leaves significant gaps for understanding its 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded, stating the purpose first and then the input/output. There's no wasted text, but it could be more structured by including usage context or parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a financial quote tool with no annotations), the description is incomplete. It mentions input and output types, but lacks details on behavior, usage, or parameters. The presence of an output schema helps, but the description doesn't leverage this to provide a complete picture, leaving gaps in understanding the tool's role and operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by naming the parameter type ('UnstakeQuoteRequestContainer'), but with 0% schema description coverage and 1 parameter, it doesn't explain what this container includes or how to use it. Since there are no parameters documented in the schema, the baseline is 4, but the description fails to compensate adequately, offering only a type name without context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Retrieve[s] an unstake quote', which provides a clear verb ('Retrieve') and resource ('unstake quote'). However, it doesn't differentiate from sibling tools like 'stake_quote' or 'swap_quote' beyond the 'unstake' prefix, leaving the specific purpose somewhat vague compared to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'stake_quote' or 'swap_quote'. The description lacks context about prerequisites, timing, or exclusions, offering no help for an agent to choose between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'quickly calculating market prices' which implies read-only, non-destructive behavior, but does not disclose critical traits like rate limits, authentication needs, error handling, or whether it's a simulation vs. actual transaction. For a financial tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded: the first states the purpose, the second adds context, and the third covers input/output. There is no wasted text, though it could be slightly more structured (e.g., bullet points for parameters). Overall, it's efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage, no annotations, and an output schema exists (so return values are documented), the description is incomplete. It covers the basic purpose and input/output types but lacks parameter details, behavioral context, and usage guidelines. For a tool in a financial context with siblings, this is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It states 'Expects a ConversionRequestContainer' but does not explain what this contains (e.g., token pairs, amounts) or provide examples. With 1 undocumented parameter, the description adds minimal semantic value beyond naming the container, failing to clarify parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Perform token conversion quote between two tokens' specifies the verb (perform conversion quote) and resource (tokens). It distinguishes from siblings like 'swap_quote' by focusing on conversion rather than swapping, though the distinction could be more explicit. The addition 'Good for quickly calculating market prices' reinforces the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'quickly calculating market prices' but does not specify scenarios, prerequisites, or exclusions compared to siblings like 'swap_quote' or 'stake_quote'. Without explicit when/when-not instructions, the agent lacks clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists orders and returns a specific response type, but lacks critical details: whether it's read-only, requires authentication, supports pagination, or has rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the action and return type. There's no fluff or redundancy. However, the brevity comes at the cost of completeness, as noted in other dimensions, but structurally it's well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no nested objects) and the presence of an output schema (which covers return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it should provide more context on parameters and behavioral traits to be fully complete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all, despite the schema having one required parameter ('list_dca_order_requests'). This leaves the agent guessing about input requirements, failing to add value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all DCA orders'), making the purpose immediately understandable. It distinguishes from siblings like 'cancel_dca_order' or 'create_dca_order' by focusing on retrieval rather than modification. However, it doesn't specify scope beyond 'all' (e.g., filtering criteria), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_all_orders' or 'cancel_dca_order'. It doesn't mention prerequisites, context for usage, or exclusions. The agent must infer usage from the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves details (implying a read-only operation) and mentions the return type ('SingleGroupInfo'), but lacks critical information such as error handling (e.g., what happens if the group doesn't exist), authentication requirements, rate limits, or data freshness. For a read tool with zero annotation coverage, this is insufficient to inform the agent fully about its 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the purpose and key details (parameter and return type). There's no unnecessary information or redundancy. However, the brevity comes at the cost of completeness, as noted in other dimensions, but within its limited scope, it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, read operation) and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose and parameter hint but lacks details on usage guidelines, behavioral traits, and parameter specifics. With no annotations and low schema coverage, it doesn't fully compensate for these gaps, making it incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for its single parameter. The description adds some value by specifying that the parameter is 'group name', but it doesn't explain the parameter's format, constraints, or how it relates to the nested 'ListSingleGroupRequest' structure. This leaves significant gaps in understanding the parameter's semantics, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve details') and resource ('for a single wallet group'), making the purpose specific and understandable. It distinguishes from siblings like 'list_groups' by focusing on a single group rather than listing multiple groups. However, it doesn't explicitly contrast with other retrieval tools like 'get_wallet_token_balance' or 'get_all_wallets', which slightly limits 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it mentions the required parameter ('group name') but offers no context on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., group existence), exclusions, or comparisons to siblings like 'list_groups' for multiple groups or 'get_wallet_token_balance' for wallet-specific data. This leaves the agent with little direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states the action is 'Remove' (implying mutation) but doesn't disclose permissions needed, whether removal is reversible, rate limits, or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, input expectation, and return value. It's front-loaded with the core action, though the return statement could be more integrated. There's no wasted text, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, 0% schema coverage, but an output schema exists, the description is partially complete. It covers the basic purpose and return type but lacks details on parameters, behavioral traits, and usage context, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'group name and a list of wallet names', which hints at parameters but doesn't fully explain the single input schema property 'remove_wallets_from_group_requests' or its structure. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove wallets') and target ('from a specified group'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'unarchive_wallet_group' or 'rename_wallets' that might also affect wallet-group relationships, missing full sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., wallets must exist in the group), exclusions, or comparisons to siblings like 'add_wallets_to_group' or 'archive_wallet_group', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs a transfer operation but doesn't mention critical behavioral aspects like whether this requires authentication, has rate limits, is irreversible, or what happens on failure. This is inadequate for a financial transaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Both sentences are relevant, though the second sentence could be more informative about the response structure. There's minimal waste, but it borders on under-specification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial transfer), lack of annotations, and 0% schema coverage, the description is incomplete. While an output schema exists (which helps), the description doesn't adequately cover behavioral traits or parameter details. It's minimally viable but has significant gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the single parameter 'transfer_tokens_requests' is completely undocumented in the schema. The description only mentions the parameter name without explaining what a TransferTokensRequestContainer contains (e.g., source/destination wallets, token amounts, network details). This leaves the parameter meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Transfer tokens') and resources involved ('from one wallet to another'), which is a specific verb+resource combination. However, it doesn't differentiate this tool from potential sibling tools like 'swap_transaction' or 'stake_transaction' that might also involve token movements, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'swap_transaction' or 'send_key_to_telegram'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it 'Expects a list of group names' and 'returns a list of GroupArchiveOrUnarchiveResponse', which gives basic input/output context. However, it fails to disclose critical behavioral traits: whether archiving is reversible, if it requires specific permissions, what happens to wallets in archived groups, or any rate limits or side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences that are front-loaded: the first states the purpose, and the second covers input and output. There's no wasted text, but it could benefit from slightly more detail to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and 0% schema coverage, the description is incomplete. It mentions the return type ('GroupArchiveOrUnarchiveResponse'), which aligns with the presence of an output schema, reducing the need to explain return values. However, it lacks essential context such as error conditions, idempotency, or effects on related resources, making it minimally adequate but with clear gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema: it indicates the parameter is a 'list of group names', which clarifies the expected content of 'archive_wallet_group_requests'. However, with 0% schema description coverage, the schema provides no details about the parameter structure or constraints. The description doesn't compensate fully—it doesn't explain the format of group names, any validation rules, or the container structure—leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive') and resource ('wallet groups'), making the purpose understandable. However, it doesn't differentiate from the sibling 'unarchive_wallet_group' tool, which performs the opposite operation, or from 'archive_wallets' which archives individual wallets rather than groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'unarchive_wallet_group' for reversing the action or 'archive_wallets' for different resources. It lacks context about prerequisites, such as whether groups must be empty or active, and doesn't mention any exclusions or dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Cancel') but does not cover critical aspects like required permissions, whether the cancellation is reversible, potential side effects, or rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action, consisting of two sentences that avoid redundancy. It could be slightly more informative without sacrificing conciseness, but it efficiently conveys the essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 1 parameter and 0% schema coverage) and the presence of an output schema, the description is minimally adequate. It states the purpose and input/output types but lacks details on usage, behavior, and parameter specifics, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'CancelOrderRequestContainer' as the expected input, which adds some semantic context beyond the schema's 0% coverage. However, it does not explain what this container includes or how to structure it, leaving parameters largely undocumented. The baseline is adjusted due to low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Cancel') and resource ('a limit, take profit or stop loss order'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cancel_dca_order' or 'get_all_orders', which would require more detail to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'cancel_dca_order' or 'get_all_orders', nor does it mention prerequisites or exclusions. It lacks context for selection among similar tools, offering only a basic functional statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the input format ('list of group names') and output format ('list of CreateGroupResponse'), but lacks critical details: required permissions, whether groups can be modified/deleted later, rate limits, or error handling. For a creation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences that are front-loaded and waste-free. The first sentence states the purpose, and the second covers input/output expectations efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation operation), lack of annotations, and 0% schema coverage, the description is incomplete. However, the presence of an output schema mitigates the need to describe return values in the description. Still, critical behavioral and parameter details are missing for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'list of group names' which hints at the parameter's purpose, but doesn't explain the actual parameter name 'create_groups_requests', its structure, or constraints (e.g., name format, duplicates). The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new wallet groups', which is specific and unambiguous. It distinguishes from siblings like 'list_groups' (read) and 'archive_wallet_group' (modify), though it doesn't explicitly differentiate from 'create_wallet' (which creates individual wallets rather than groups).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing wallets first), compare to 'create_wallet' for individual wallets, or specify when group creation is appropriate versus other operations like adding wallets to groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('Create new wallets') and return type ('WalletInfo'), but lacks details on permissions, side effects, error handling, or rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. Both sentences are relevant, with no wasted words, though it could be slightly more structured (e.g., separating input and output details more clearly).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 1 parameter) and no annotations, the description is minimally adequate. It covers input and output at a high level, and an output schema exists, so return values needn't be detailed. However, it lacks behavioral context like error cases or dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'a list of wallet names' for the input, which adds meaning beyond the schema's generic 'create_wallet_requests'. However, it doesn't explain the structure of 'WalletInfo' in the output, though an output schema exists, mitigating this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new wallets'), making the purpose evident. It distinguishes from siblings like 'add_wallets_to_group' or 'rename_wallets' by focusing on initial creation, though it doesn't explicitly mention this 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify if this is for initial setup versus modifying existing wallets, or mention prerequisites like required permissions or system state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the input and output types but lacks details on rate limits, authentication needs, data freshness, or error handling. For a tool with no annotation coverage, this is insufficient to inform the agent about operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences that are front-loaded with the core purpose. Each sentence adds value: the first states the action, the second provides usage context, and the third clarifies input/output types. No wasted words, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 parameter with 0% schema coverage, no annotations, but has an output schema), the description is moderately complete. It covers the basic purpose and I/O types, but lacks details on parameters, behavioral traits, and usage guidelines. The output schema existence reduces the need to explain return values, but overall gaps remain for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It references 'TopTrendingTokensRequest' as the input and implies a time frame parameter, adding some semantic context beyond the schema. However, it doesn't detail what fields the request includes or their formats, leaving parameters largely undocumented. Baseline 3 is appropriate as it adds minimal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get the top trending tokens') and resource ('tokens'), and provides context about the time frame. It distinguishes itself from siblings by focusing on trending tokens rather than balances, orders, or other operations. However, it doesn't explicitly differentiate from potential similar tools like 'search_token_details' in terms of scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Great for comparing market cap or volume,' which implies a use case but doesn't specify when to use this tool versus alternatives like 'search_token_details' or 'get_token_candle_data.' No explicit when-not-to-use or prerequisite information is given, leaving gaps in usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details such as whether it's a read-only operation, requires authentication, has rate limits, or handles errors. This is a significant gap for a tool with financial data implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that directly address purpose and input/output. It's front-loaded with the main function and avoids unnecessary details, though it could be slightly more structured with bullet points or examples for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial balance queries), no annotations, and an output schema exists, the description is minimally adequate. It covers purpose and basic I/O but lacks behavioral context, error handling, and detailed parameter guidance, which are important for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the parameter 'WalletTokenPairsContainer' and its purpose, adding some semantics beyond the bare schema. However, it doesn't explain the structure or format of this container, leaving gaps in understanding how to construct valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('balance for a list of wallet/token pairs'), distinguishing it from siblings like 'get_all_wallets' or 'get_stake_balances'. However, it doesn't explicitly differentiate from similar tools beyond the resource specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare it to siblings like 'get_all_wallets' or 'get_stake_balances', leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the expected input and return types but doesn't describe what the tool actually does behaviorally - whether it's a read-only operation, if it has side effects, what permissions are required, or how it interacts with the system. The description is technically accurate but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two sentences that directly state the tool's function and its input/output types. There's no wasted verbiage or unnecessary information. However, the brevity comes at the cost of completeness, as it omits important contextual information that would help an agent use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which covers return values) and only 1 parameter, the description is minimally complete. However, for a financial/trading tool that likely has important behavioral considerations (costs, timing, prerequisites), the description lacks crucial context about how this tool fits into the broader workflow and what constraints apply to its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 1 parameter and 0% schema description coverage, the description adds significant value by specifying that the parameter is a 'StakeQuoteRequestContainer'. This gives semantic meaning to what would otherwise be a completely undocumented parameter. While it doesn't detail the container's structure, it provides essential context about the expected input type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Retrieve a stake quote', which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'unstake_quote' or 'swap_quote', leaving ambiguity about what distinguishes these quote retrieval operations. The purpose is understandable but lacks specificity about what makes a 'stake quote' unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple quote-related tools in the sibling list (unstake_quote, swap_quote), but the description doesn't explain when stake_quote is appropriate versus those other options. No context about prerequisites, timing, or use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the expected input and return type but lacks details on permissions, side effects, error handling, or rate limits, which are crucial for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by input and output details in the second. It uses minimal words effectively, with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, no annotations, and an output schema (which covers return values), the description is minimally adequate. However, it lacks critical context like permissions or error cases, making it incomplete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'group name' and 'list of wallet names', which adds some meaning beyond the schema's generic 'add_wallet_to_group_requests'. However, it doesn't fully explain the parameter structure or constraints, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resources 'wallets' and 'group', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'remove_wallets_from_group' or 'create_groups', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'create_groups' or 'remove_wallets_from_group'. The description only states what it does, not the context or prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a 'StakeBalanceResponse' but does not elaborate on what that includes, potential errors, rate limits, authentication needs, or whether it's a read-only operation. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences that directly state the purpose and return value. It is front-loaded with the main action and wastes no words. However, it could be slightly improved by integrating the return information more seamlessly, but overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists (implied by 'Returns a StakeBalanceResponse'), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, or error handling. For a simple tool, this is acceptable but not comprehensive, aligning with a score of 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add any parameter information, which is appropriate. A baseline score of 4 is assigned as the description does not need to compensate for any schema gaps, and it correctly avoids redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the balance of staked SOL (jupSOL).' It specifies the verb ('Get') and resource ('balance of staked SOL'), making it easy to understand. However, it does not explicitly differentiate from siblings like 'get_wallet_token_balance' or 'get_all_wallets', which might also retrieve balance-related information, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as whether it applies to specific wallets or groups. With siblings like 'get_wallet_token_balance' available, the lack of comparative usage advice leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get', implying a read operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or any other behavioral traits. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or usage context, which could be helpful for a complete understanding, though not strictly necessary for basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as it doesn't introduce confusion or redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the current Armor Wallet version' clearly states the verb 'Get' and the resource 'current Armor Wallet version', making the purpose specific and understandable. However, it doesn't distinguish this tool from its siblings, as none of them seem to directly overlap with version retrieval, but explicit differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or exclusions, leaving the agent to infer usage based solely on the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does ('Gets the current time and date') but doesn't disclose any behavioral traits such as whether it's read-only, if it requires authentication, rate limits, or what format the time is returned in. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Gets the current time and date') with zero waste. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, simple purpose) and the presence of an output schema, the description is minimally adequate. However, it lacks details on behavioral aspects like time format or timezone handling, which could be important for an agent to use it correctly, especially with no annotations provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and a baseline score of 4 is appropriate as it doesn't mislead or omit parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gets the current time and date' clearly states the verb ('Gets') and resource ('current time and date'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools, which are all unrelated to time retrieval, so it doesn't reach the highest score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it returns 'a list of GroupInfo' without detailing behavioral traits like pagination, rate limits, permissions, or error handling. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the action and return value. There is no wasted language, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate but lacks behavioral context. The output schema handles return values, but without annotations, more detail on operation traits would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate here, earning a baseline score above 3 due to the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all wallet groups'), making the purpose unambiguous. However, it doesn't distinguish itself from sibling tools like 'list_single_group' or 'create_groups', which would require explicit differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_single_group' or 'create_groups'. The description lacks context about prerequisites, timing, or exclusions, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the input/output types (TokenSearchRequest/TokenDetailsResponse) but doesn't describe what 'details' include, whether this is a read-only operation, any rate limits, authentication requirements, or error conditions. The description provides minimal behavioral context beyond the basic 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences that each serve a purpose: stating the core function, providing usage guidance, and specifying input/output types. It's front-loaded with the main purpose and avoids unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) but zero parameter documentation and no annotations, the description is moderately complete. It covers the basic purpose and provides some usage guidance, but fails to compensate for the complete lack of parameter documentation or behavioral context that annotations would normally provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 1 parameter (token_search_requests), the description provides no information about what constitutes a TokenSearchRequest, what fields it contains, or how to structure it. The description mentions the parameter type name but adds no semantic meaning beyond what's already implied by the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('search and retrieve details') and resource ('single token'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this from sibling tools like 'search_official_token_address' or 'get_token_candle_data' beyond a brief alternative mention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use an alternative tool ('get_official_token_address first' for address or symbol only), which helps the agent make appropriate choices. However, it doesn't specify when NOT to use this tool or compare it to other potential alternatives like 'get_top_trending_tokens'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the wait is 'short' and limited to 'no more than 10 seconds,' which adds context about duration constraints. However, it does not cover other behavioral traits such as whether the wait is blocking, if it respects system interrupts, error handling, or performance implications. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Wait for some short amount of time, no more than 10 seconds.' It is front-loaded with the core action and includes a key constraint without unnecessary details. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic purpose and a constraint, but lacks details on parameter usage, behavioral aspects, and output expectations. For a simple tool, it's adequate but could be more informative to fully guide an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('seconds') with 0% description coverage in the schema. The description does not explicitly mention or explain this parameter, but it implies it by stating 'some short amount of time, no more than 10 seconds,' which indirectly relates to the 'seconds' parameter. However, it does not add detailed meaning beyond what the schema's title ('Seconds') and type ('number') provide, such as valid ranges or units. With low schema coverage, the description compensates only partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wait for some short amount of time, no more than 10 seconds.' It specifies the verb ('wait') and the resource ('time'), and distinguishes itself from all sibling tools, which are related to crypto wallet management, trading, and data queries. However, it could be slightly more specific about the exact nature of the waiting (e.g., blocking vs. non-blocking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'some short amount of time, no more than 10 seconds,' which suggests it's for brief delays. However, it does not explicitly state when to use this tool versus alternatives (e.g., for timing operations, rate limiting, or testing), nor does it provide exclusions or prerequisites. The context is clear but lacks detailed guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the input and output types ('Expects a TokenDetailsRequestContainer, returns a TokenDetailsResponseContainer'), which adds some context, but it lacks details on error handling, rate limits, authentication needs, or what 'official' implies (e.g., source verification). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidelines and technical details. It uses three concise sentences with zero waste, each earning its place by adding distinct value (function, usage, I/O types). This is efficiently structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is reasonably complete. It covers purpose, usage guidelines, and I/O types. The output schema existence means return values don't need explanation. However, without annotations, it could benefit from more behavioral context (e.g., error cases), but it's adequate for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It references 'TokenDetailsRequestContainer' but doesn't explain what this contains (e.g., fields like token symbol or address). This adds minimal semantic value beyond the schema name. With 1 parameter and low coverage, the description provides some hint but doesn't fully clarify parameter usage, aligning with a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the official token address and symbol for a token symbol or token address.' It specifies the verb ('Get') and resource ('official token address and symbol'), making the function understandable. However, it doesn't explicitly differentiate from its sibling 'search_token_details' beyond usage ordering, which slightly limits distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Try to use this first to get address and symbol of coin. If not found, use search_token_details to get details.' This clearly states when to use this tool versus an alternative (search_token_details), including a fallback scenario, which is optimal for agent decision-making.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it 'safely evaluates' expressions (implying error handling or security), supports specific operations and functions, and allows custom variables via a dict. However, it lacks details on error messages, performance limits, or output format, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose and following with supported operations and parameter details. Every sentence adds value without redundancy, making it efficient and easy to scan for key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is mostly complete. It covers purpose, behavior, and parameter semantics well, but lacks details on output format (e.g., result type or error handling). For a calculation tool, this is a minor gap, as the core functionality is clearly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema by explaining that 'expression' is a 'mathematical or statistical expression string using Python syntax' and 'variables' is a 'dict' for 'custom variables... including lists for time series data'. This clarifies parameter purposes and usage, though it could provide more examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('evaluates a mathematical or statistical expression string') and resources ('using Python syntax'), distinguishing it from sibling tools focused on cryptocurrency operations like wallet management and trading. It explicitly mentions the types of operations supported, making its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for mathematical or statistical expressions, but does not explicitly state when to use this tool versus alternatives (e.g., other calculation tools or manual computation). It provides context on supported operations but lacks explicit guidance on exclusions or comparisons with sibling tools, which are unrelated to calculation.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/emmaThompson07/armor-crypto-mcp'

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