Ultrade MCP Server

Official

by ultrade-org

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools have distinct purposes, with clear separation between market, system, and wallet functions. However, some overlap exists, such as 'ultrade_market_orders' and 'ultrade_market_open_orders', which could cause minor confusion, and 'ultrade_market_create_order' vs 'ultrade_market_create_orders' being very similar but for single vs batch operations.
Naming Consistency5/5
All tools follow a consistent 'ultrade_[category]_[action]_[object]' snake_case pattern, with clear categories (market, system, wallet) and predictable verb-noun structures. This makes the tool set highly readable and organized.
Tool Count3/5
With 35 tools, the count is borderline high for a trading server, potentially overwhelming for agents. While it covers many aspects, some tools like 'ultrade_market_order_message' and 'ultrade_wallet_key_message' might be redundant or overly granular, suggesting the set could be streamlined.
Completeness5/5
The tool set provides comprehensive coverage for a trading platform, including market operations (assets, orders, depth, history), system info (time, version, maintenance), and wallet management (keys, sign-in, transactions, withdrawals). No obvious gaps are present; it supports full trading workflows.
Average 2.4/5 across 35 of 35 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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 the full burden of behavioral disclosure but offers none. It doesn't indicate if this is a read-only operation, if it has side effects (e.g., generates a signing message), what the output format might be, or any constraints like rate limits or authentication needs. The vague term 'Generate message' leaves behavior ambiguous.
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, short sentence ('Generate message from the order data'), which is concise and front-loaded. However, it's under-specified—the brevity comes at the cost of clarity, as it lacks essential details about purpose and usage, making it inefficient rather than optimally concise.
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 complexity (1 parameter with nested objects, 0% schema coverage, no annotations, no output schema), the description is severely incomplete. It doesn't explain what the tool does, how to use it, what the parameters mean, or what to expect as output, leaving the agent unable to effectively invoke this tool in context with its many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('data') with 7 nested properties (symbol, side, type, quantity, price, loginAddress, loginChainId), and schema description coverage is 0%. The description adds no information about these parameters—it doesn't explain what 'message' is generated from them, their roles, or any formatting requirements (e.g., quantity as a string). This fails to compensate for the lack of schema documentation.
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 'Generate message from the order data' restates the tool name 'ultrade_market_order_message' in slightly different words, making it tautological. It doesn't specify what kind of message is generated (e.g., confirmation, summary, signing request) or for what purpose, nor does it distinguish this from sibling tools like 'ultrade_market_create_order' or 'ultrade_wallet_key_message'.
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 (e.g., needing order data from another tool), context (e.g., before signing or submitting an order), or relationships to siblings like 'ultrade_market_create_order' or 'ultrade_wallet_signin_message'.
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 must fully disclose behavioral traits. It fails to do so, offering no information on whether this is a read-only or mutative operation, what permissions are required, what the generated message is used for (e.g., signing, display), or any side effects like rate limits or errors. The description is minimal and lacks essential behavioral context.
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, concise sentence, which is appropriately sized. However, it is under-specified rather than efficiently informative, as it lacks necessary details. While front-loaded, it doesn't earn its place by adding value beyond the tool name.
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 complexity (2 parameters with a nested object, no annotations, no output schema), the description is severely incomplete. It fails to explain the tool's purpose, usage, behavior, or output, leaving critical gaps for an AI agent to understand how to invoke it correctly in the context of sibling tools like 'ultrade_wallet_withdraw'.
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 50% (only 'customMessage' has a description), and the description does not compensate by explaining the parameters. It mentions 'withdrawal data' but does not clarify what the 'data' object contains or how parameters like 'loginAddress', 'tokenAmount', or 'fee' relate to message generation. This leaves most parameters semantically unclear beyond their schema types.
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 'Generate message from the withdrawal data' is tautological, essentially restating the tool name 'ultrade_wallet_withdraw_message' without specifying what type of message is generated or its purpose. It lacks a clear verb+resource combination and doesn't distinguish this tool from sibling tools like 'ultrade_wallet_withdraw' or 'ultrade_wallet_key_message'.
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 any context, prerequisites, or exclusions, leaving the agent with no indication of when this tool is appropriate compared to other wallet or withdrawal-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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses no behavioral traits. It doesn't indicate whether this is a read-only or mutating operation, what permissions are required, if it has side effects (e.g., generating a cryptographic signature), rate limits, or error conditions. The vague 'Generate message' leaves the agent guessing about critical 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 a single, efficient sentence with no wasted words. However, it's overly terse and under-specified for a tool with parameters and no annotations, bordering on cryptic rather than concise. It's front-loaded but lacks necessary detail.
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 2 parameters with nested objects, 50% schema coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't cover what the generated message is used for, output format, error handling, or integration with wallet workflows. For a tool in a security-sensitive context (wallet sign-in), this is inadequate.
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 50% (only 'data' object properties are described, 'customMessage' lacks description). The description adds no meaning beyond the schema—it doesn't explain what 'message' entails, how 'data' and 'customMessage' interact, or provide examples (e.g., message format, use of enums like 'ALGORAND'). With low coverage and 2 parameters, it fails to compensate for schema 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 'Generate message from the sign in data' restates the tool name 'ultrade_wallet_signin_message' without adding specificity. It vaguely indicates generating a message but doesn't clarify what type of message (e.g., authentication, signature request) or its purpose in the wallet sign-in flow. Compared to siblings like 'ultrade_wallet_signin' (likely performs sign-in) and 'ultrade_wallet_key_message' (likely generates key-related messages), it fails to distinguish its unique role.
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. It doesn't mention prerequisites (e.g., whether sign-in data must be prepared first), exclusions, or relationships to sibling tools like 'ultrade_wallet_signin' or 'ultrade_wallet_key_message'. The description offers no context for appropriate usage scenarios.
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 for behavioral disclosure. 'Create new orders' implies a write/mutation operation but reveals nothing about side effects (e.g., order placement, fund deductions), authentication requirements (implied by parameters but not stated), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with zero wasted text. It is front-loaded with the core action, though this brevity comes at the cost of informativeness. Every word earns its place, but the place is minimal.
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 tool's complexity (mutation with 3 required parameters, no output schema, and no annotations), the description is severely incomplete. It fails to address behavioral traits, parameter meanings, usage context, or output expectations, making it inadequate for safe and effective tool invocation by an agent.
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 67% (2 of 3 parameters have descriptions: walletAddress and walletToken). The description adds no parameter semantics beyond the schema—it doesn't explain the 'orders' array structure (containing message and signature objects) or their purposes. With low coverage and no compensation in the description, parameter understanding is incomplete.
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 new orders' is a tautology that essentially restates the tool name 'ultrade_market_create_orders'. While it indicates the action (create) and resource (orders), it lacks specificity about what kind of orders (e.g., trading orders, market/limit orders) and doesn't distinguish it from sibling 'ultrade_market_create_order' (singular vs. plural).
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. It doesn't mention prerequisites (like authentication via wallet parameters), differentiate from 'ultrade_market_create_order' (batch vs. single order creation), or specify appropriate contexts (e.g., after market data checks). This leaves the agent without usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get trading assets' implies a read operation but doesn't specify if it requires authentication, has rate limits, returns a list or single asset, or involves any side effects. This is inadequate for a tool in a financial trading context where such details are critical.
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 ('Get trading assets'), which could be efficient if it were informative. However, it's under-specified rather than truly concise, as it omits necessary context. It's front-loaded but fails to earn its place by providing sufficient value.
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 trading system and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'trading assets' entails, the return format, or how it fits among many sibling tools. This leaves significant gaps for an AI agent to operate effectively in this domain.
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 doesn't add parameter details, which is appropriate here. A baseline of 4 is applied as it compensates for the lack of parameters by not introducing confusion or redundancy.
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 'Get trading assets' states a basic action but lacks specificity. It doesn't clarify what 'trading assets' means in this context (e.g., cryptocurrencies, stocks, tokens) or distinguish this tool from siblings like 'ultrade_market_balances' or 'ultrade_market_symbols', which might provide overlapping or related information. While it includes a verb and resource, it remains vague about the exact scope.
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. With siblings such as 'ultrade_market_balances' (likely for account balances) and 'ultrade_market_symbols' (possibly for market symbols), the description offers no context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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. 'Create new order' implies a write/mutation operation, but it doesn't disclose any behavioral traits: no information on authentication requirements (though parameters hint at it), rate limits, idempotency, side effects (e.g., fund deductions), error conditions, or response format. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no wasted language. It's front-loaded with the core action, though this brevity comes at the cost of informativeness. Every word earns its place, but the place is minimal.
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 complexity (a mutation tool for financial orders), no annotations, no output schema, and a vague description, this is highly incomplete. The description fails to explain what an 'order' entails, authentication needs, return values, or error handling. It doesn't compensate for the lack of structured data, making it inadequate 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 100%, with clear descriptions for all 4 parameters (e.g., 'The signed message in hex format'). The description adds no parameter information beyond the schema. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
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 new order' is a tautology that essentially restates the tool name 'ultrade_market_create_order'. It specifies the verb 'create' and resource 'order', but lacks any detail about what type of order (e.g., buy/sell, limit/market) or on what market/asset. It doesn't distinguish from siblings like 'ultrade_market_create_orders' (plural) or 'ultrade_market_cancel_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. It doesn't mention prerequisites (e.g., authentication via wallet), differentiate from 'ultrade_market_create_orders' (batch creation), or specify scenarios like placing trades versus managing orders. The description offers no context for usage decisions.
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 the full burden of behavioral disclosure. 'Get market details' implies a read-only operation but does not specify authentication requirements, rate limits, error conditions, or what the output entails (e.g., structured data vs. raw text). This leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Get market details') that is front-loaded and wastes no words. However, it is overly terse, bordering on under-specification, which slightly reduces its effectiveness despite the brevity.
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 lack of annotations and output schema, the description is incomplete for a tool that likely returns complex market data. It fails to explain what 'details' include, the format of the response, or any behavioral context, making it inadequate for an agent to use effectively without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'symbol' documented as 'Market symbol, e.g. sol_eth'. The description adds no additional parameter semantics beyond this, so it meets the baseline score of 3 for high schema coverage without compensating value.
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 'Get market details' restates the tool name 'ultrade_market_details' with minimal elaboration, making it tautological. It specifies a verb ('Get') and resource ('market details') but lacks specificity about what details are retrieved, failing to distinguish it from siblings like 'ultrade_market_price' or 'ultrade_market_depth' that might also provide market-related information.
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. With many sibling tools (e.g., 'ultrade_market_price', 'ultrade_market_depth', 'ultrade_market_history'), the description offers no context, prerequisites, or exclusions, leaving the agent to guess based on 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.
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 but only states 'Get fee rates' without any behavioral details. It does not disclose whether this is a read-only operation, requires authentication, has rate limits, returns real-time or static data, or any error conditions, making it inadequate 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two words, but it is under-specified rather than efficiently informative. It lacks front-loaded critical details like scope or context, making it too brief to be truly helpful, though it avoids unnecessary verbosity.
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 no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It fails to explain what fee rates are retrieved, the return format, or any behavioral traits, leaving significant gaps for the agent to operate effectively in a market context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, but with no parameters, a baseline score of 4 is appropriate as there is nothing to compensate for.
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 'Get fee rates' states a basic action but is tautological with the tool name 'ultrade_market_fee_rates', which already implies retrieving fee rates. It lacks specificity about what fee rates (e.g., trading, withdrawal, maker/taker) or for which market context, and does not distinguish from sibling tools like 'ultrade_market_withdrawal_fee' that might handle similar data.
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. With siblings like 'ultrade_market_withdrawal_fee' that might relate to fees, the description offers no context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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 the full burden of behavioral disclosure. 'Get markets' implies a read operation but doesn't specify whether this requires authentication, what data format is returned, if there are rate limits, or any side effects. For a tool with zero annotation coverage, this description fails to provide essential behavioral context needed for safe and effective use.
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 ('Get markets') but borders on under-specification rather than effective brevity. While it uses minimal words, it fails to provide necessary context that would help an AI agent understand the tool's purpose. The structure is front-loaded but incomplete, lacking any explanatory details.
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 financial market tools and the absence of both annotations and an output schema, the description is insufficiently complete. 'Get markets' doesn't explain what constitutes a market in this system, what data is returned, or how this differs from similar sibling tools. For a tool in a financial trading context with many alternatives, more specificity is needed.
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 (empty schema). Since there are no parameters to document, the description doesn't need to compensate for any gaps. The baseline score for zero parameters is 4, as the description appropriately doesn't waste space discussing non-existent parameters.
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 'Get markets' is a tautology that essentially restates the tool name 'ultrade_market_markets'. It specifies the verb 'Get' but doesn't clarify what 'markets' means in this context or differentiate it from similar sibling tools like ultrade_market_symbols or ultrade_market_details. The purpose remains vague without additional context about what constitutes a 'market' in this system.
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. With multiple sibling tools related to markets (e.g., ultrade_market_symbols, ultrade_market_details, ultrade_market_price), there is no indication of what distinguishes this tool from others or when it should be preferred. No usage context, prerequisites, or exclusions are mentioned.
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. 'Get trading keys' implies a read operation, but it doesn't disclose behavioral traits like authentication requirements (though parameters hint at it), rate limits, what 'trading keys' entail (e.g., API keys, permissions), or the response format. It lacks critical context for safe and effective use.
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?
The description is overly concise at three words, leading to under-specification rather than efficiency. It fails to front-load essential information, such as what 'trading keys' are or why this tool is needed. Every sentence should earn its place, but here the single phrase lacks substance.
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 no annotations and no output schema, the description is incomplete. It doesn't explain the return values (e.g., key details, format), error conditions, or how it fits with sibling tools. For a tool with authentication parameters and complex sibling relationships, this minimal description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions ('Login wallet address', 'Login session token'). The description adds no meaning beyond the schema, as it doesn't explain parameter relationships or usage. With high schema coverage, the baseline is 3, but the description doesn't compensate or enhance understanding.
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 'Get trading keys' restates the tool name 'ultrade_wallet_keys' in a tautological manner. It doesn't specify what 'trading keys' are, what resource they belong to, or how this differs from sibling tools like 'ultrade_wallet_add_key' or 'ultrade_wallet_revoke_key'. The purpose is vague rather than specific.
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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing authentication via 'ultrade_wallet_signin'), context for retrieving keys, or relationships with sibling tools that manage keys (add/revoke). The description provides zero usage context.
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. 'Withdraw token' implies a destructive/mutative operation that moves assets out, but the description doesn't disclose any behavioral traits: it doesn't mention authentication requirements (though parameters suggest it), rate limits, irreversible nature, confirmation times, network fees, or what happens on success/failure. For a financial transaction tool with zero annotation coverage, this is completely inadequate.
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 maximally concise with just two words. While severely under-specified, it's not wordy or poorly structured—every word earns its place by stating the core action. There's no fluff or redundant 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 this is a financial transaction tool (withdraw) with no annotations, no output schema, and 4 required parameters, the description is completely inadequate. It doesn't explain what 'token' means, the withdrawal destination, success/failure behavior, authentication flow, or relationship to sibling tools. The agent would struggle to use this correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 4 parameters clearly documented in the schema itself (message, signature, walletAddress, walletToken). The description adds no additional meaning about parameters beyond the verb 'withdraw', which implies these are authentication/signing parameters for a withdrawal operation. Since the schema does the heavy lifting, baseline 3 is appropriate.
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 'Withdraw token' states the verb and resource but is extremely vague. It doesn't specify what type of token (cryptocurrency, utility token, etc.), from where (wallet, exchange, specific platform), or to where (external address, another wallet). While it distinguishes from most siblings (which are market-related or other wallet operations), it doesn't differentiate from 'ultrade_wallet_withdraw_message' which appears related. The description is a near-tautology of the tool name.
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 (e.g., needing authentication via 'ultrade_wallet_signin' first), when withdrawal is appropriate versus other wallet operations like 'ultrade_wallet_transactions', or any constraints (e.g., minimum amounts, network fees). There's no reference to the sibling 'ultrade_wallet_withdraw_message' which likely provides a message to sign for this 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get orders' implies a read operation but lacks details on permissions, rate limits, pagination, or return format. It does not address whether it retrieves all orders, filtered orders, or specific subsets, leaving critical behavioral traits unspecified.
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 'Get orders' is extremely concise but under-specified, not efficiently informative. While it avoids unnecessary words, it fails to front-load essential details, making it too brief to be helpful rather than optimally structured.
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 no annotations, no output schema, and a vague description, the tool is incomplete for a read operation with 4 parameters. It lacks context on what 'orders' entails, how results are returned, or differentiation from siblings, making it inadequate for effective agent use despite the schema covering inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters (walletAddress, walletToken, tradingKey, companyId) with descriptions. The description adds no meaning beyond this, such as explaining relationships between parameters or usage examples, but the schema provides adequate baseline information.
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 'Get orders' is a tautology that restates the tool name 'ultrade_market_orders' without adding specificity. It does not clarify what type of orders (e.g., open, historical, by ID) or distinguish it from sibling tools like 'ultrade_market_open_orders' or 'ultrade_market_order_by_id', leaving the purpose vague and undifferentiated.
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. With siblings such as 'ultrade_market_open_orders' and 'ultrade_market_order_by_id', it fails to specify context, exclusions, or prerequisites, offering no help for selection among 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 the full burden of behavioral disclosure. 'Get last trades' implies a read-only operation, but it does not specify whether authentication is required, rate limits apply, or what the output format looks like (e.g., list of trades, timestamps, prices). For a tool with zero annotation coverage, this lack of behavioral context is a significant gap, though it does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, making it front-loaded and efficient. However, this brevity borders on under-specification, as it sacrifices clarity and completeness for conciseness. While it avoids waste, it could benefit from slightly more detail to enhance utility without becoming verbose.
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 tool's complexity (2 parameters, no output schema, no annotations), the description is incomplete. It does not explain return values, error conditions, or behavioral aspects like pagination or data freshness. With no output schema and minimal description, the agent lacks sufficient context to understand what the tool returns or how to interpret results, making it inadequate for 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 input schema has 100% description coverage, with clear documentation for 'symbol' and 'limit' parameters, including constraints like the 100 maximum. The description adds no additional meaning beyond the schema, such as examples or usage tips. According to the rules, with high schema coverage, the baseline score is 3, as the schema adequately handles parameter semantics without extra description input.
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 'Get last trades' is a tautology that essentially restates the tool name 'ultrade_market_last_trades', providing minimal additional meaning. It specifies the verb 'Get' and resource 'last trades', but lacks specificity about what 'last trades' entails (e.g., recent transactions, market data) and does not differentiate from sibling tools like 'ultrade_market_history' or 'ultrade_wallet_trades', leaving ambiguity in scope.
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. There is no mention of context, prerequisites, or exclusions, and it fails to reference sibling tools such as 'ultrade_market_history' (which might overlap) or 'ultrade_wallet_trades' (which could be user-specific). This absence of usage instructions leaves the agent without direction for selection.
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 but discloses no behavioral traits. It doesn't mention if this is a read-only operation, requires authentication, has rate limits, returns structured data, or any other behavioral aspects. This is a significant gap 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 ('Get market symbols')—just three words—and front-loaded with the core action. There's no wasted language, making it efficient for quick understanding, though it sacrifices detail for brevity.
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 no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It doesn't explain what 'market symbols' entail, the return format, or any behavioral context, making it inadequate for an agent to use effectively without additional assumptions.
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 doesn't add param info, but that's acceptable here. Baseline is 4 since there are no parameters to compensate for, and the description doesn't introduce confusion.
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 'Get market symbols' states a verb ('Get') and resource ('market symbols'), but it's vague about what 'market symbols' are (e.g., trading pairs, asset codes) and doesn't differentiate from siblings like 'ultrade_market_markets' or 'ultrade_market_assets', which might overlap in purpose. It avoids tautology by not just repeating the name, 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. With many sibling tools (e.g., 'ultrade_market_markets', 'ultrade_market_assets'), the description doesn't indicate if this is for a specific type of symbol, context, or use case, leaving the agent to guess without any explicit or implied 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. 'Get operation details' implies a read-only operation, but it doesn't specify whether this requires authentication, what format the details are returned in (e.g., JSON structure), potential rate limits, or error conditions. For a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with zero wasted text. It is front-loaded with the core action ('Get operation details'), making it easy to parse quickly. Every word earns its place, though this conciseness comes at the cost of completeness.
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 implied by the sibling tools (e.g., trading operations), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'operation details' include, how they relate to other tools, or what the agent can expect in return. For a tool in a financial/trading context with rich sibling functionality, this minimal description fails to provide adequate context for 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 input schema has 100% description coverage, with one parameter 'operationId' documented as 'Operation ID'. The description adds no additional meaning beyond this, such as explaining what constitutes a valid operation ID or where to obtain it. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't enhance parameter understanding.
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 'Get operation details' is a tautology that essentially restates the tool name 'ultrade_market_operation_details'. It specifies the verb 'Get' and resource 'operation details', but doesn't clarify what 'operation' means in this context (e.g., trade, order, transaction) or how it differs from similar tools like 'ultrade_market_order_by_id' or 'ultrade_market_history'. The purpose is vague without domain-specific context.
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?
There is no guidance on when to use this tool versus alternatives. Given siblings like 'ultrade_market_order_by_id' (which might retrieve order details) and 'ultrade_market_history' (which might list past operations), the description provides no context to help an agent choose appropriately. It lacks any mention of prerequisites, exclusions, or typical use cases.
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 but fails to do so. It states 'Add a trading key' but doesn't explain what this operation does (e.g., modifies wallet permissions, requires authentication, has side effects like rate limits or irreversible changes). The lack of detail leaves the agent guessing about critical behavioral 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 extremely concise with a single phrase, 'Add a trading key', which is front-loaded and wastes no words. However, it's overly terse to the point of under-specification, lacking necessary detail for a tool with 9 required parameters and no annotations. It earns a 4 for brevity but loses points for insufficient content.
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 (9 required parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's role in the broader system (e.g., wallet management), what 'adding a trading key' achieves, or any behavioral context. For a mutation tool with significant parameters, this minimal description fails to provide adequate context for an 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 schema description coverage is 100%, with each parameter well-documented in the input schema (e.g., 'message' as signed hex, 'addKey' toggles add/revoke). The description adds no additional meaning beyond the schema, but since coverage is high, the baseline score is 3. No parameter-specific context is provided in the description to elevate the 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 'Add a trading key' restates the tool name 'ultrade_wallet_add_key' with minimal elaboration, making it tautological. It doesn't specify what 'adding' entails operationally or distinguish it from sibling tools like 'ultrade_wallet_revoke_key', which handles revocation. The purpose is vague beyond the basic action implied by the name.
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. It doesn't mention prerequisites (e.g., needing a signed message from 'ultrade_wallet_key_message'), exclusions, or contextual cues. The description alone offers no help in distinguishing it from related wallet or market 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.
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 for behavioral disclosure. 'Get market history' implies a read-only operation but doesn't specify any traits like rate limits, authentication needs, data freshness, or what 'history' includes (e.g., candles, volume). This leaves critical behavioral aspects undocumented.
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 just three words, front-loaded to convey the core purpose immediately. There's no wasted verbiage, making it efficient for quick scanning, though this brevity contributes to gaps in other dimensions.
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 (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'market history' returns (e.g., OHLC data), how to interpret parameters like 'interval', or any behavioral constraints. For a tool with multiple parameters and no structured output, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters clearly documented in the schema (e.g., 'symbol' as market symbol, 'interval' as resolution). The description adds no additional meaning beyond the schema, such as explaining typical interval values or format implications. Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Get market history' clearly states the action (get) and resource (market history), which is better than a tautology. However, it doesn't specify what 'market history' entails (e.g., OHLC candles, trades) or distinguish it from sibling tools like 'ultrade_market_last_trades' or 'ultrade_market_price', leaving the purpose somewhat vague.
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 'ultrade_market_last_trades' (likely for recent trades) and 'ultrade_market_price' (likely for current prices), there's no indication of how this tool differs, such as for historical data over a range versus real-time updates.
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. 'Cancel open order' implies a destructive mutation, but it doesn't disclose behavioral traits like side effects (e.g., order removal, potential fees), authentication needs (implied by wallet parameters but not stated), or error conditions. The description is too sparse to inform the agent adequately about the tool's 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 extremely concise ('Cancel open order'), which is front-loaded and wastes no words. However, it borders on under-specification given the tool's complexity (3 required parameters, no annotations). While efficient, it might be too brief to be fully helpful without supporting context.
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 tool's complexity (mutation operation with 3 required parameters, no annotations, no output schema), the description is incomplete. It doesn't cover return values, error handling, or behavioral nuances. For a cancel operation in a trading context, more detail is needed to guide the agent effectively, making this inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., 'Order ID to cancel'). The tool description adds no additional meaning beyond the schema, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra value is provided.
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 'Cancel open order' states the action (cancel) and resource (open order), which is clear but minimal. It doesn't distinguish from sibling 'ultrade_market_cancel_orders' (plural), leaving ambiguity about whether this tool handles single vs. batch operations. The purpose is understandable but lacks specificity 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 like 'ultrade_market_cancel_orders'. The description doesn't mention prerequisites (e.g., needing an open order), exclusions, or contextual cues. Without annotations or explicit instructions, the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Get open orders' suggests a read-only operation, but it doesn't specify authentication requirements (implied by wallet parameters), rate limits, pagination, error handling, or what 'open' means (e.g., pending, active). This leaves significant gaps in understanding the tool's 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 extremely concise ('Get open orders'), which is efficient and front-loaded. However, it may be overly brief, risking under-specification for a tool with multiple parameters and no annotations. Every word earns its place, but more context could improve clarity.
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 tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error cases, or behavioral nuances like how 'open' is defined. For a financial tool with authentication parameters, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying filtering by 'open' status and possibly by symbol (via the optional parameter). Since the schema handles parameter details, a baseline score of 3 is appropriate, with no extra value from the description.
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 'Get open orders' clearly states the action (get) and resource (open orders), but it's vague about scope and doesn't distinguish from sibling tools like 'ultrade_market_orders' or 'ultrade_market_order_by_id'. It specifies the type of orders (open) but lacks detail on what constitutes 'open' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'ultrade_market_orders' (which might fetch all orders) or 'ultrade_market_order_by_id'. The description implies filtering for open orders, but it doesn't clarify prerequisites, dependencies, or exclusions, 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. 'Get order by ID' suggests a read-only operation, but it doesn't mention authentication requirements (implied by wallet parameters), rate limits, error handling, or what data is returned. For a tool with authentication parameters and no output schema, 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 extremely concise with just three words, which is front-loaded and wastes no space. However, it's arguably under-specified given the tool's complexity (involving authentication and financial data), so it loses a point for not being appropriately detailed while remaining efficient.
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 (financial trading tool with authentication parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what an 'order' contains, how authentication works with the parameters, or what the return value looks like. This leaves the agent with insufficient context to use the tool effectively beyond basic parameter passing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (orderId, walletAddress, walletToken, tradingKey) with basic descriptions. The description adds no additional meaning beyond implying that 'orderId' is used to retrieve the order, which is already clear from the schema. This meets the baseline of 3 when schema coverage is high.
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 'Get order by ID' clearly states the verb ('Get') and resource ('order'), but it's vague about scope and doesn't differentiate from siblings like 'ultrade_market_orders' (which likely lists multiple orders) or 'ultrade_market_order_message' (which might retrieve order messages). It specifies retrieval by ID, which provides some distinction but lacks detail about what an 'order' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this is for retrieving a single order by its unique ID, as opposed to using 'ultrade_market_orders' for a list or 'ultrade_market_open_orders' for pending ones. The description implies usage by ID but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Generate message' but doesn't disclose behavioral traits such as whether this is a read-only or mutating operation, authentication requirements (implied by 'walletToken'), side effects, or error handling. The description is too vague to inform the agent about how the tool behaves beyond basic parameter usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It's front-loaded and to the point, though it could be more informative. There's no unnecessary elaboration, making it efficient but potentially under-specified.
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 tool's complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the generated message is used for, how it integrates with other tools, or what the expected outcome is. For a tool that likely involves key management operations in a trading context, more context is needed to guide 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 100%, so the schema already documents all parameters thoroughly with descriptions and enums. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters (e.g., how 'addKey' interacts with 'type' or 'expiredDate'). Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate message from the trading key data' states a general purpose but lacks specificity. It mentions 'message' and 'trading key data' but doesn't clarify what type of message (e.g., authorization, transaction) or what the message is used for. It doesn't distinguish from sibling tools like 'ultrade_wallet_add_key' or 'ultrade_wallet_revoke_key' that might handle similar operations.
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. The description doesn't mention prerequisites, context, or relationships to sibling tools such as 'ultrade_wallet_add_key' or 'ultrade_wallet_revoke_key', which appear to handle related key operations. Usage is implied only through parameter names like 'addKey', but not explicitly stated.
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. 'Sign in to trading account' implies a mutation (authentication action) but doesn't specify if it creates a session, requires specific permissions, has side effects like rate limits, or what happens on failure. This is a significant gap for a tool that likely involves security-sensitive operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it's under-specified rather than concise—it could benefit from more detail without becoming verbose, so it's not a perfect 5.
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 (authentication tool with 4 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't cover behavioral aspects like session management, error handling, or return values, leaving the agent with insufficient context 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 75% (3 of 4 parameters have descriptions), so the schema does most of the work. The description adds no meaning beyond the schema—it doesn't explain the relationship between 'message', 'signature', and 'data', or why 'referralToken' is optional. Baseline 3 is appropriate as the schema provides adequate documentation.
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 'Sign in to trading account' states a clear action (sign in) and target (trading account), but it's vague about what 'sign in' entails compared to siblings like 'ultrade_wallet_signin_message' or 'ultrade_wallet_keys'. It doesn't specify if this establishes a session, authenticates for trading, or something else, making it less distinct.
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 explain if this should be used before other wallet tools, how it relates to 'ultrade_wallet_signin_message', or any prerequisites like needing a signed message first. This leaves the agent without context for proper 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 only states the action ('Get filtered wallet transactions') without detailing authentication needs (implied by walletAddress/token parameters), rate limits, response format, pagination, or error handling. This leaves significant gaps for a tool that likely requires authentication and returns transaction data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more informative. The brevity is appropriate but under-specified rather than 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 the tool's complexity (3 parameters, likely authentication-dependent, no output schema) and lack of annotations, the description is incomplete. It doesn't address authentication flow, response structure, or error cases, making it inadequate for safe and effective use by an 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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond implying filtering (which the parameters might enable), but doesn't explain how parameters interact or what 'filtered' entails. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get filtered wallet transactions' states a clear verb ('Get') and resource ('wallet transactions'), but lacks specificity about what 'filtered' means and doesn't distinguish from sibling tools like 'ultrade_wallet_trades' or 'ultrade_market_history'. It's vague about the filtering mechanism beyond what the parameters imply.
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. The description doesn't mention prerequisites, context (e.g., after authentication), or differentiate from sibling tools that might handle similar data, leaving the agent without 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get market settings' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns structured data, or involves any side effects. For a tool with no annotation coverage, this is a significant gap in transparency about how the tool behaves beyond its basic function.
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 just three words ('Get market settings'), which is front-loaded and wastes no space. For a simple tool, this brevity is appropriate, though it may sacrifice clarity. Every word serves a purpose, making it efficient in structure.
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 (a read operation with one parameter) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'market settings' includes, how results are returned, or any behavioral traits. For a tool in a crowded sibling set, more context is needed to help the agent use it correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'domain' documented as 'Domain of the dApp'. The description doesn't add any meaning beyond this, such as examples or context for the domain parameter. With high schema coverage, the baseline score is 3, as the schema adequately handles parameter documentation without extra help from the description.
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 'Get market settings' clearly states the action (get) and resource (market settings), which is adequate. However, it doesn't distinguish this from sibling tools like 'ultrade_market_details' or 'ultrade_market_fee_rates', which might also retrieve market-related information. The purpose is understandable but lacks specificity about what 'market settings' entails compared to similar tools.
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 many sibling tools (e.g., 'ultrade_market_details', 'ultrade_market_fee_rates'), it's unclear if this is for general settings, specific configurations, or other purposes. There's no mention of prerequisites, context, or exclusions, leaving the agent to guess based on 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. 'Get withdrawal fee' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns real-time or cached data, or what format the fee information is in. For a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with zero wasted text. It's front-loaded with the core action and resource. Every word earns its place, though this brevity contributes to the vagueness in other dimensions.
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 tool's complexity (3 required parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain what the withdrawal fee represents, how the parameters interact, or what the return value looks like. For a tool that likely involves cross-chain token transfers, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter names and types. The description adds no additional meaning beyond the schema, which already documents 'tokenIndex', 'tokenChainId', and 'recipientChainId'. This meets the baseline of 3 when schema coverage is high, but doesn't compensate with extra context like examples or edge cases.
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 'Get withdrawal fee' clearly states the action (get) and resource (withdrawal fee), but it's vague about what exactly is being retrieved. It doesn't specify whether this is a fee amount, percentage, structure, or policy, nor does it distinguish this tool from sibling tools like 'ultrade_market_fee_rates' or 'ultrade_wallet_withdraw' that might also involve fees.
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 sibling tools like 'ultrade_market_fee_rates' and 'ultrade_wallet_withdraw' that likely relate to fees, there's no indication of how this tool differs or when it's appropriate. No context or prerequisites are mentioned.
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. 'Revoke' implies a destructive mutation, but it doesn't disclose behavioral traits such as permissions required, irreversibility, effects on active trades, or rate limits. This leaves significant gaps for an agent to understand the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It's appropriately sized for the tool's purpose, though brevity contributes to gaps in other dimensions. Every word earns its place.
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 no annotations, no output schema, and a mutation tool with 4 parameters, the description is incomplete. It lacks details on behavior, output, error cases, and integration with sibling tools (e.g., 'ultrade_wallet_key_message' for message generation). More context is needed 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 100%, so parameters are documented in the schema. The description adds no meaning beyond the schema (e.g., it doesn't explain how 'message' and 'signature' relate to key revocation). Baseline is 3 as the schema does the heavy lifting, but no extra value is added.
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 'Revoke a trading key' clearly states the action (revoke) and resource (trading key), but it's vague about what 'revoke' entails (e.g., disabling vs. deleting) and doesn't differentiate from siblings like 'ultrade_wallet_keys' (list) or 'ultrade_wallet_add_key' (add). It's functional 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a signed message from 'ultrade_wallet_key_message'), exclusions, or related tools like 'ultrade_wallet_keys' for listing keys. Usage is implied only by the name and parameters.
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 'Get filtered wallet trades', lacking details on authentication needs (e.g., walletToken usage), rate limits, response format, or error handling. It doesn't contradict annotations, but it's insufficient for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse.
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 no annotations, no output schema, and a tool with 3 parameters (one required), the description is incomplete. It doesn't cover behavioral aspects like authentication, response format, or error cases, leaving significant gaps for 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?
Schema description coverage is 100%, so parameters are documented in the schema. The description adds no meaning beyond implying filtering, but it doesn't explain how parameters relate to filtering (e.g., walletToken for auth, tradingKey for specific trades). Baseline is 3 as schema handles documentation.
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 'Get filtered wallet trades' states a verb ('Get') and resource ('wallet trades'), but it's vague about what 'filtered' means and doesn't distinguish from siblings like 'ultrade_wallet_transactions'. It provides a basic purpose 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?
No guidance is provided on when to use this tool versus alternatives such as 'ultrade_wallet_transactions' or 'ultrade_market_history'. The description implies filtering but doesn't specify 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get account balances' implies a read-only operation, but it doesn't specify authentication requirements (e.g., whether walletToken or tradingKey are needed for certain balances), rate limits, error conditions, or what 'balances' includes (e.g., fiat, crypto, locked funds). This leaves significant gaps for a tool that likely accesses sensitive financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence ('Get account balances') with zero wasted words. It efficiently conveys the core purpose without unnecessary elaboration, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data tools, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication, error handling, or return format (e.g., balance types, currencies), which are critical for an agent to use this tool effectively in a trading or wallet context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for walletAddress, walletToken, and tradingKey. The description doesn't add any meaning beyond the schema (e.g., it doesn't explain relationships between parameters or typical usage patterns), so it meets the baseline score of 3 where the schema does the heavy lifting.
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 account balances' clearly states the verb ('Get') and resource ('account balances'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ultrade_wallet_transactions' or 'ultrade_wallet_trades' that might also retrieve financial data, 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. With many sibling tools available (e.g., 'ultrade_wallet_transactions' for transaction history, 'ultrade_market_assets' for asset listings), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on naming 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 full burden. It states 'Cancel multiple open orders' but lacks behavioral details: no mention of permissions required, whether cancellation is reversible, rate limits, error handling, or what happens if some orders fail. For a mutation 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 with zero waste. It's front-loaded and appropriately sized for its purpose, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, authentication needs (implied by wallet parameters but not stated), or response format, leaving critical gaps for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying 'orderIds' refers to 'multiple open orders', which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel multiple open orders' clearly states the verb ('Cancel') and resource ('multiple open orders'), making the purpose unambiguous. However, it doesn't differentiate from sibling 'ultrade_market_cancel_order' (singular), which might be important for agent selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'ultrade_market_cancel_order' (singular) or prerequisites. The description implies it's for multiple orders but doesn't specify thresholds or constraints, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get blockchain chains' implies a read-only operation, but it doesn't specify if this requires authentication, has rate limits, returns paginated results, or what the output format is. For a tool with zero annotation coverage, this lacks critical behavioral details, though it doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words ('Get blockchain chains'), which is front-loaded and wastes no space. For a simple tool with no parameters, this brevity is appropriate and efficient, making it easy to scan and understand at a glance.
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 tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't clarify what 'blockchain chains' entails (e.g., a list of chain names, detailed metadata) or how it differs from similar siblings. Without annotations or output schema, more context is needed to guide effective use, making this inadequate for a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's acceptable since there are no parameters. This meets the baseline for tools with zero parameters, as it doesn't mislead or omit necessary info.
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 'Get blockchain chains' states a clear verb ('Get') and resource ('blockchain chains'), but it's vague about what 'blockchain chains' means in this context (e.g., networks, protocols, or specific chains). It doesn't distinguish from siblings like 'ultrade_market_markets' or 'ultrade_market_symbols', which might overlap in purpose. However, it avoids tautology by not just restating the name.
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 many sibling tools (e.g., 'ultrade_market_markets', 'ultrade_market_symbols'), it's unclear if this is for listing available chains, retrieving chain details, or another purpose. There's no mention of prerequisites, context, or exclusions, 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?
No annotations are provided, so the description carries full burden. It mentions 'Get order book depth' but doesn't disclose behavioral traits such as whether this is a read-only operation, rate limits, authentication needs, or what the return format looks like. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get order book depth') that front-loads the core purpose with zero waste. Every word earns its place, making it appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description is incomplete for a tool with 2 parameters. It lacks information on return values, behavioral context, or usage guidelines, which are crucial for an AI agent to invoke it correctly in a server with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('symbol' and 'depth') with descriptions. The description adds no additional meaning beyond the schema, such as examples or edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Get') and resource ('order book depth'), making the purpose understandable. It distinguishes from siblings like 'ultrade_market_price' or 'ultrade_market_history' by focusing on depth data. However, it doesn't explicitly differentiate from all siblings (e.g., 'ultrade_market_details' might overlap), keeping it from 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. With many sibling tools (e.g., 'ultrade_market_price' for price data, 'ultrade_market_open_orders' for order status), it lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
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 tool retrieves data ('Get'), implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication requirements, error conditions, or what 'last market price' specifically means (e.g., bid/ask/mid, timestamp). For a financial data tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 that immediately conveys the core functionality. Every word earns its place with no redundancy or unnecessary elaboration. It's appropriately sized for a simple data retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value includes (e.g., price numeric, currency, timestamp) or address potential complexities like invalid symbols or data freshness. For a market price tool in a financial context, more context is needed for reliable 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 100%, with the single parameter 'symbol' documented as 'Market symbol, e.g. sol_eth'. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('Get last market price') and the resource ('by pair symbol'), making the tool's purpose immediately understandable. It distinguishes itself from siblings like 'ultrade_market_depth' or 'ultrade_market_history' by focusing specifically on the most recent price. However, it doesn't explicitly differentiate from 'ultrade_market_last_trades', which might provide similar recent trade data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 'ultrade_market_last_trades' (potentially similar) and 'ultrade_market_depth' (different data), there's no indication of which tool to choose for specific price-related queries. The agent must infer usage from tool names 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 states 'Get system version', implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns structured data, or involves any side effects. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
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 'Get system version' is extremely concise—just three words—and front-loaded with the core action. There is no wasted language or unnecessary elaboration, making it efficient for quick comprehension.
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 tool's simplicity (0 parameters, no annotations, no output schema), the description is minimal but insufficient. It doesn't explain what 'system version' entails (e.g., format, scope) or the expected output, leaving the agent without enough context to use the tool effectively in a broader system with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter information, so it meets the baseline expectation. No additional semantic details are required or provided.
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 'Get system version' clearly states the verb ('Get') and resource ('system version'), making the basic purpose understandable. However, it lacks specificity about what 'system version' refers to (e.g., API version, software version, platform version) and doesn't distinguish this from sibling tools like 'ultrade_system_maintenance' or 'ultrade_system_time', which are also system-related but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 use cases (e.g., for debugging, compatibility checks), prerequisites, or relationships to sibling tools like 'ultrade_system_maintenance' or 'ultrade_system_time', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation ('Get'), but doesn't specify authentication requirements, rate limits, response format, or error conditions. For a 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 a single, clear sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too minimal. It doesn't explain what 'maintenance status' entails, the return format, or behavioral aspects like whether it requires authentication. Given the lack of structured data, more context is needed.
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 no parameter documentation is needed. The description appropriately doesn't mention parameters, earning a baseline score of 4 for not introducing unnecessary complexity.
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 system maintenance status' clearly states the action (Get) and resource (system maintenance status), making the purpose understandable. However, it doesn't differentiate from sibling tools like ultrade_system_time or ultrade_system_version, which are also system-related read operations.
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, timing considerations, or how it differs from other system tools like ultrade_system_time, leaving the agent without 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get current system time,' which implies a read-only operation, but does not disclose any behavioral traits such as rate limits, authentication requirements, or what format the time is returned in. This leaves significant gaps 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 'Get current system time' is a single, efficient sentence that is front-loaded and wastes no words. It directly conveys the tool's purpose without unnecessary elaboration, 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 (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks details on behavioral aspects like return format or potential errors. Without annotations or output schema, more context would be helpful, but it meets the basic requirement for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add parameter semantics, but this is acceptable as there are no parameters. Baseline is 4 for 0 parameters, as the description does not need to compensate for any gaps.
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 'Get current system time' clearly states the verb ('Get') and resource ('current system time'), making the purpose specific and unambiguous. It effectively distinguishes this tool from its siblings, which are focused on market operations, wallet management, and other system functions like maintenance or version checks.
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 stating 'Get current system time,' suggesting it should be used when the current system time is needed. However, it does not explicitly guide when to use this tool versus alternatives (e.g., other time-related tools if they existed) or provide exclusions. The context is clear but lacks explicit alternatives or when-not-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

[![ultrade-mcp MCP server](https://glama.ai/mcp/servers/ultrade-org/ultrade-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ultrade-org/ultrade-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/ultrade-org/ultrade-mcp'

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