mcp-pionex
Server Quality Checklist
Latest release: v1.1.0
- Disambiguation5/5
Every tool has a clearly distinct purpose: market data, technical indicators, trading, dual investment, and bot management are all separated. Even similar tools like get_klines and get_klines_history are easily distinguishable by their limits and use cases, with no ambiguity between them.
Naming Consistency5/5All 43 tools follow a consistent snake_case verb_noun pattern (get_, list_, prepare_, confirm_, cancel_, compute_, detect_, check_). The naming convention is uniform and predictable, making it easy for an agent to infer function from name.
Tool Count2/5With 43 tools, the server exceeds the 25+ threshold for 'too many'. Although the broad scope (market data, indicators, trading, bots, dual products) justifies a large surface, the sheer number will likely overwhelm agents and increase selection overhead. This is well beyond the typical well-scoped 3-15 tool range.
Completeness5/5The tool surface is comprehensive: it covers market data, technical analysis, order placement/cancellation, portfolio rebalancing, grid bot lifecycle, dual investment subscription/revoke, and account balances. The prepare/confirm pattern for risky actions is well-implemented, and there are no obvious dead ends or missing critical operations.
Average 3.7/5 across 43 of 43 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This server has been verified by its author.
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?
The description does not disclose behavioral traits such as read-only nature, side effects, or what kind of data is returned. It only states what the data represents, not how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, containing no unnecessary words. It is a noun phrase rather than a sentence, but it is still clear enough for the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about what 'dual-investment' means, what the returned balances look like, and when this tool is appropriate. Given the many sibling tools with similar get operations, this description is too minimal to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters to describe. The description does not explain that the tool takes no arguments, but since there are none, this is not a major gap. A more explicit statement could clarify that it returns all balances without filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase stating the account's dual-investment balances, but it lacks an explicit action verb like 'get' or 'fetch'. The tool name implies the action, but the description could be more explicit about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other get tools (e.g., get_balances, get_dual_prices). The description does not mention any distinguishing use case or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden, and it does add a useful behavioral detail: the quote convention for BTC/ETH pairs. However, it omits other behavioral aspects like whether the operation is read-only or requires authentication, but for a list endpoint this is less critical. The provided detail is valuable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences that are easy to parse. The first sentence states the purpose, and the second adds a necessary caveat. While the first sentence is a fragment, it remains efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with an optional parameter; it never explains what 'base' controls or how results behave when it's omitted. It also doesn't indicate the return format. The quote convention note is helpful but addresses only a narrow aspect, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's only parameter 'base' is undocumented (0% coverage), and the description does not mention it at all. Since the schema provides no hints and the description offers no compensation, the agent is left guessing what 'base' does, making the tool hard to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Pairs supported by Dual Investment,' which indicates the resource and action. It doesn't explicitly use the verb 'list' but the meaning is unambiguous. It doesn't name sibling tools but the context of Dual Investment differentiates it from other list 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/5Does 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 list_dual_products or get_dual_prices. The note about quote conventions is a usage tip but not about tool selection. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does disclose the two-step confirmation-token flow, the cap check, and a safety admonition to show the plan first. However, it omits failure behavior (what happens if an order breaches the cap), permission need for market-order execution, and whether rejection to project a bounces back a warning or an error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the 'STEP 1 of 2' framing that immediately sets process context. Each sentence earns its place: what it is, what it does, how to act on the result. Efficient and well-ordered, though the 'confirmation token' contract could be one clause tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool this complex — two-step confirmation flow, notional cap enforcement, an unexplained JSON weights argument and a threshold parameter — the description is incomplete. It lacks the weights format, threshold semantics, the step-2 (confirm_action) handoff, and the differentiation from compute_rebalance_plan. An agent has just enough to start but not enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description gives no parameter-level guidance. It never explains the target_weights_json format (JSON string, which symbol/weight shape), nor what threshold (default 0.01) quantifies — rebalance deviation cutoff, drift tolerance, or something else. An agent cannot construct correct arguments from this text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action — preparing/executing a portfolio rebalance as market orders — and concrete behaviors: recomputes from live data, checks against the notional cap, returns a confirmation token plus the exact plan. Loses a point because the similarly-named sibling compute_rebalance_plan could plausibly do the same thing; nothing here clearly separates this tool from it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Conveys the two-step flow and instructs 'Show the plan to the user before confirming,' which is useful routing context. But it never names compute_rebalance_plan as the likely alternative, nor says when to prefer this tool over it, nor states exclusions. The agent must guess the difference between prepare_rebalance and compute_rebalance_plan.
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 supplied, so the description carries full responsibility. It discloses that results are limited to open/unfilled spot orders, but it does not mention permissions, pagination, or response shape. For a tool without annotation support, this is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The key scoping detail ('open/unfilled') is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description gives the core purpose, but because there are no annotations and no output schema, the agent is left without information about return format, possible empty results, or error conditions. It feels incomplete for an automated caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only says 'for a symbol,' adding little beyond the schema's 'Symbol' title. It does not clarify the expected format (e.g., 'BTCUSDT') or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource pattern: it states the tool returns 'Currently open (unfilled) spot orders for a symbol.' This distinguishes it from order history or individual order lookup, though it doesn't explicitly name sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get_order, get_order_history, or get_fills. The description implies a read operation but offers no exclusions or preferred contexts.
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 present, so the description carries the full burden of behavioral disclosure. It reveals only that this is step 1 and returns a token; it does not state whether the revoke is already partially applied, whether the token expires, or what side effects the preparation may have.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: 'STEP 1 of 2' immediately signals the workflow, and 'returns a confirmation token' gives the key output. Every sentence earns its place, though it is short on richness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a two-step workflow with no annotations and no output schema, so the description must be self-sufficient. It not missing next step, token purpose, or any safety context, leaving the agent without enough information to safely complete the full revoke operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the three required parameters: base, product_id, and client_dual_id. The bare parameter names provide little context and the description adds nothing to clarify their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and purpose: it is the first step to revoke an unsettled dual investment and explicitly notes it returns a confirmation token. This distinguishes it from a full revoke and from investing tools, though it does not name the step-2 sibling or the confirmation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives the core usage context: use this as the first step for revoking an unsettled dual investment. However, it does not state when not to use it, nor does it name the next tool or validate the follow-up step, so the agent must infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the computed heuristic and that results may vary from other definitions, which is useful. However, it doesn't disclose the return format beyond 'Estado: fresh/mitigated/broken', doesn't mention data requirements (how many candles needed), or performance considerations. For a compute-heavy analysis tool, this feels thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the key heuristic. The Spanish is technical and precise. It wastes little, though it could have front-loaded the purpose statement more clearly before diving into the heuristic formula.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (algorithmic indicator, 5 params, output state machine), the description covers the algorithm but leaves out operational context: what data is needed, what error conditions exist, what the output structure is (though output schema exists). The heuristic explanation is solid, but for an indicator tool with no annotations, the lack of when-to-use guidance is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 5 parameters. It explains displacement_factor (in the heuristic), lookback implicitly via '200 default', only_unmitigated not mentioned, symbol/interval obvious. The description explains the core heuristic so the displacement_factor and lookback semantics are derivable, but only_unmitigated's behavior is completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects order blocks using a specific displacement heuristic with concrete details (displacement_factor × ATR(14), last opposite candle in prior 3). It has a clear verb+resource and matches its name. It doesn't explicitly distinguish from detect_fvg, but the heuristic detail is strong enough to stand alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the heuristic definition and notes it's computational, but gives no guidance on when to use this vs detect_fvg or get_market_structure, and no context on typical trading scenarios or data requirements. The note "HEURÍSTICA computada" warns about differences from other OB definitions, but doesn't route the agent to an alternative.
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 it provides minimal detail. It doesn't state whether this is a read-only operation (which is likely but not stated), rate limits, or any side effects. It also doesn't mention what happens if the symbol is invalid. The description is too sparse to be transparent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It's a single sentence that gets to the point. However, it could be slightly more structured with a separate mention of 'market_type', but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 optional parameters and no output schema, the description should provide more context for correct use. It lacks information about return format, the meaning of 'market_type' (e.g., SPOT vs other), and any prerequisites. The description is too thin for an agent to call this tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must explain the parameters, but it only mentions 'symbol' indirectly ('if symbol is empty') and doesn't address 'market_type' at all. Given 0% coverage, the description fails to compensate; the agent has no idea what 'market_type' does or its possible values. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get the best bid/ask for a symbol or all symbols. It uses a specific verb ('get') and resource ('book ticker'), and it's distinct from siblings like 'get_price' and 'get_ticker_24h'. However, it doesn't explicitly differentiate from the most similar siblings, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need best bid/ask) but does not provide explicit guidance on when not to use it or alternatives. For example, it doesn't mention that 'get_price' might be used for last price, or 'get_ticker_24h' for 24-hour stats. This leaves the agent to infer the appropriate 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. It discloses the 'recent' scope and the limit range, but it doesn't state whether the data is real-time, how recent 'recent' is, if there's pagination, or what the response structure looks like. For a data-fetching tool without annotations, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose and key parameter constraint. It earns its place with no fluff, though it could be slightly more structured by separating the limit info, but it's appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no annotations, no output schema, and a low schema description coverage, the description is too thin. It doesn't explain what 'recent' means, whether the data is aggregated or individual trades, or how it differs from get_price or get_depth. An agent calling this would lack critical context about the response and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description covers the limit parameter's range and default, which adds value beyond the schema's default=100 (by adding the allowed range 10-500). However, the symbol parameter is not described beyond the schema's type and required status. With 0% schema description coverage, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Recent public trades for a symbol.' It indicates the tool retrieves recent trades, which is distinct from siblings like get_price or get_ticker_24h. However, it doesn't explicitly differentiate from other trade-related tools (none exist in the sibling list), so it's clear but not explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, use cases, or exclusions. For instance, it doesn't clarify if this is for public market data only or if it's the right tool for historical trades versus recent ones. With many sibling market data tools, usage guidance is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden here. It adds useful traits: 'requires API credentials (read permission)' and 'Balances are live account facts — never estimate them.' This signals read-only, authoritative data. However, it doesn't cover output shape, error cases, or rate limits. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then adds auth requirement and behavioral caveat. Efficient and no fluff, though it misses the parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple single-param balance fetch with no output schema, the description covers the resource and a live-data caveat hats and the auth requirement)Skip context: no mention of when to prefer this over get_portfolio or get_dual_balances, and the include_zero parameter is left unexplained. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the only parameter, include_zero. It does not. The description explains the return object (free, frozen, total) but never tells the agent what include_zero=true/false does. With zero schema coverage, this is a real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb+resource: 'Account balances per coin' with breakdown into 'free, frozen and total'. Clear what the tool returns)Skip confusion with get_dual_balances (dual-product balances) but doesn't explicitly distinguish itself from siblings — that nuance is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus alternatives like get_dual_balances or get_portfolio. It mentions requiring API credentials (a prerequisite) but never states conditions for choosing this tool or exclusions. No when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 discloses that data is derived and not from the exchange, which is useful, but it does not mention other behavioral aspects like potential lag, rate limits, or whether it includes only closed candles vs current forming candle. It also doesn't mention what happens with invalid periods or symbols.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core purpose. The additional detail on periods and the derived nature is relevant, but the sentence about being derived could be integrated more cleanly. Overall, it avoids unnecessary verbosity and stays focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema (though not shown here), which may cover return values. The tool is relatively simple with 4 params, but the 0% schema coverage and lack of annotations mean the description must explain both parameters and behavior. It partially does, but the gaps on limit, interval, and error handling reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'periods' parameter format and semantics, but does not clarify 'limit', 'symbol', or 'interval' beyond their names. It provides no context on how these affect the output or what values are expected (e.g., interval format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns current EMA values based on real candle closes, and specifies the output includes EMA value, whether price is above, and distance percentage. It distinguishes itself from raw kline data by noting it's derived, which helps set it apart from siblings like get_klines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions that periods is a comma-separated list and that it's derived from live klines, not an exchange data point, implying usage context. However, it does not explicitly state when to use this over siblings like get_indicators or detect_fvg, nor does it explain when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it 'fetches the bot's live state' and 'returns a confirmation token,' which suggests read-only behavior, but it does not explicitly state whether it has side effects, requires authentication, or has rate limits. With no annotations provided, the description carries the full burden, and while it provides some insight, it leaves ambiguity about operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff, front-loading the key 'STEP 1 of 2' context. Every word serves a purpose, making it efficient and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sparse given that there is no output schema and no annotations. It fails to explain how the returned token should be used, what the summary contains, or how to handle errors. The parameter is undefined, and there is no mention of the second step or how to proceed after obtaining the token.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter bu_order_id has no schema description (0% coverage), and the description does not explain its meaning or format. The agent must infer from the parameter name alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's role as 'STEP 1 of 2 to close a running spot grid bot,' identifying the specific resource (spot grid bot) and action (prepare cancel). It also distinguishes from sibling tools like cancel_order by framing it as a preparation step that fetches state and returns a token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies it is part of a two-step process but does not explicitly state when to use this tool versus alternatives (e.g., cancel_order, prepare_cancel_all_orders). It lacks guidance on when not to use it or how it relates to confirm_action.
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 only states what the tool fetches ('underlying index price') without any mention of side effects, permissions, rate limits, or return format. As a getter it's presumably safe, but that is not disclosed, leaving a significant gap in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key concept ('Underlying index price') with no wasted words. It is appropriately sized for the tool's simplicity and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema, no annotations), the description provides the core purpose but omits any information about return values or output format. Since no output schema exists, the description should at least indicate what the agent will receive (e.g., a numeric price), but it doesn't. This is a minor gap for a simple getter, but it leaves the agent slightly uncertain about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions for 'base' and 'quote' (0% schema coverage), so the description must compensate. It adds context that the tool operates on a 'dual-investment pair', which implies base and quote are the two assets of the pair. This gives minimal semantic meaning, but it doesn't explain expected formats, examples, or any additional parameter details, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('underlying index price for a dual-investment pair'), which makes the tool's purpose clear. It doesn't explicitly differentiate from siblings like 'get_dual_prices', but the term 'underlying index price' suggests a distinct concept from product prices, giving some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in the context of dual-investment pairs (for retrieving the index price), but provides no explicit guidance on when to use this tool versus alternatives such as 'get_dual_prices' or when not to use it. The context is clear enough to infer basic usage, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only mentions that yields and strike prices come verbatim from the exchange, which is a data fidelity note but does not disclose whether the operation is read-only, has side effects, or any rate or auth considerations. For a list tool, safety and side effects are not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and contains no fluff. Two sentences deliver the essential information: what the tool does and which parameters require special care. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and key parameter semantics, but it does not mention the shape of the response, pagination, or error behavior. Since there is no output schema, the agent has to infer the return format. It also lacks explicit guidance on when not to use this tool relative to siblings. Adequate for a simple listing tool but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the product_type parameter with allowed values ('DUAL_BASE' / 'DUAL_CURRENCY') and provides examples for base and quote (BTC, USDT). However, the 'currency' parameter is not explained at all, leaving a gap. Partial compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'Dual-investment products currently open for subscription.' This is a specific verb-resource combination that distinguishes it from siblings like list_dual_symbols (which lists symbols) and get_dual_prices (which gets prices). The product_type explanation further clarifies the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter constraints (product_type values) but does not explain when to use this tool versus alternatives. There is no explicit guidance on when to prefer this over siblings like get_dual_prices or list_dual_symbols. The usage context is implied from the tool name and purpose but not 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?
No annotations are present, so the description must carry behavioral transparency. It indicates a read operation (fetching fills) but does not mention any side effects, permissions, or response characteristics. Minimal detail beyond the core purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the primary function (retrieve fills for an order) and its intended use. No superfluous words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the basic purpose but omits details like return format, potential errors, or examples. It is adequate for a straightforward retrieval but lacks completeness for a robust agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, order_id, is mentioned in the description as 'one order' but not explicitly linked to the parameter name. The schema already provides the name, and the description adds little semantic value beyond that, such as expected format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches fills for a specific order (a filtering subset of get_fills) and ties to the use case of computing average entry price. This distinguishes it from sibling tools like get_fills or get_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case (compute average entry price) but does not explicitly state when to use this tool versus alternatives like get_fills or get_order. The context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries a heavier burden, and it does reveal relevant behavioral context: it returns only 'últimos valores' (latest values), it is 'DERIVADO de klines vivas', and it uses standard formulas with specific periods. It does not document live-updating behavior or the exact number of candle samples each indicator consumes, but the information given is accurate and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the indicator list immediately and the derivation note appended. Each part earns its place, and there is no redundant filler. The only minor issue is that it is written in Spanish in an otherwise English-oriented tool set, which may add a tiny amount of friction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only indicator tool with an output schema, the description provides enough to understand the main result domain and the data source. However, it falls short on parametrized documentation: an agent cannot infer the required format of 'symbol', acceptable 'interval' values, or how 'limit' changes the calculation or response under the current explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only textual place to explain the parameters. It does not mention 'symbol', 'interval', or 'limit' at all, nor enumerate possible interval values or the meaning of the limit. The names in the schema are somewhat self-explanatory, but with a 0% coverage gap this still leaves significant room for the agent to guess incorrectly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies what the tool returns: classic indicators over live candles, listing RSI(14), MACD(12,26,9), ATR(14), Bollinger(20,2), and SMA/EMA 20/50/200. It distinguishes the tool from raw klines and from the single-indicator get_emas sibling by indicating it is a multi-indicator panel, though it phrases this as a noun phrase ('Panel de indicadores') rather than an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool is derived from live klines with standard formulas, which implies it is the right choice when you want computed indicators rather than raw klines. However, it does not explicitly describe when to use this instead of get_emas or get_klines, nor does it mention any exclusion conditions or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It conveys a read-only intent ('details of a single order') and discloses the returned fields (status, filed size, avg price, fee), which is helpful. It doesn't address error behavior, neither what happens for a nonexistentId id, but for a state read it explains the core behavior the agent needs. Placing a baseline 3 given zero annotation coverage. This adds some value beyond trivially implying 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, short, front-loaded line with zero fluff. It leads with the target resource (the order + identifier) and inlines the return fields with expected
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A single-parameter read tool with Schema covers the 1 param requirement; description discloses the 4 return fields (status, size, avg price, fee) which compensates for lack of output schema. It does not mention error/not-found behavior). Given the simplicity and absence of output schema, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is 100% undocumented (title coverage 0%), so the description carries the param burden. It clarifies numeric order id ('numeric order.decision.numeric order.decision.pullId') matching the integer type, which adds a little default correctness meaning. It does NOT explain the need to place order exists first or the possible value domain of and of the value domain now domain of 'orderId' range; only. schema) probably hasn't gone thereby by description alone., but the added value is small — baseline 3 for an instructional param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope: 'Details of one order by its numeric orderId.' It is an accessor for a single order, which distinguishes it from the listing siblings (get_open_orders, get_order_history, list_bot_orders), though it doesn't name them explicitly as 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to prefer this tool. It does not mention that this is for looking up a specific order as opposed to sibling getters like get_order_by_client_id or get_fills_by_order, nor does it note any prereq/prerequisite (e.g., order placed via orders via prepare_order). The agent must infer usage from the context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does disclose the primary behavior (rolling 24h stats for one or all symbols) and the effect of an empty symbol. However, it does not mention any side effects, rate limits, authentication requirements, or whether the operation is read-only, though 'get' implies read-only. The time window is stated, but other behavioral traits are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundancy. The main purpose and scope are front-loaded, and the empty-symbol behavior is stated succinctly. Every phrase contributes essential information, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description covers the core functionality and lists the returned fields, which is helpful. However, it fails to explain the market_type parameter and does not describe the response format beyond the field list. With no annotations and no output schema, more behavioral and parameter context would be expected, but given the simplicity, the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameter meanings. It explains the 'symbol' parameter well (empty means all symbols), but it completely ignores 'market_type'. With two parameters and zero schema documentation, leaving one undefined is a significant gap. The description adds value for symbol but not for market_type, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('24-hour rolling stats') with a clear resource (symbol) and enumerates the exact data fields (open/close/high/low/volume/amount/count). It distinguishes itself from siblings like get_price or get_book_ticker by specifying the rolling statistics scope, and it clarifies the all-symbols behavior when symbol is empty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_price or get_klines. The only usage hint is the behavior when symbol is empty, which is more about parameter handling than selection criteria. There is no mention of when to prefer this over other market data endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' implies a read-only operation, and the account scoping is stated, but there is no disclosure about pagination, result format, filter matching behavior, or any rate-limit considerations. It is adequate for a simple list tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core purpose is front-loaded, and the filter details are packed efficiently into the second sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all four parameters, which is enough to make a basic call. However, with no output schema, it does not describe the return shape or whether it returns bots or orders, and it lacks usage guidance relative to siblings. This leaves meaningful gaps for an agent deciding how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does: status gets concrete examples ('RUNNING', 'FINISHED'), bot_types gets a comma-separated example ('SPOT_GRID,FUTURES_GRID'), and base/quote are explained as coin filters. It adds real meaning beyond the bare schema, though base/quote format is not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'the account's trading bots', which distinguishes it from sibling list tools like list_symbols and list_dual_products. However, the tool name says 'bot_orders' while the description says 'trading bots', creating slight ambiguity about whether it returns bots or their orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains optional filters but gives no guidance on when to use this tool versus alternatives such as get_spot_grid or get_order_history. There is no mention of exclusions, prerequisites, or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It adds meaningful behavioral detail: default/max limit ('default 50, max 200') and the time format ('epoch-ms'). It omits edge behaviors like how 0-valued time params are handled or whether the list is sorted, but for a simple read operation it discloses the key knobs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero fluff, with the core purpose front-loaded and constraints packed efficiently into parentheticals. Every clause earns its place. Minor deduction: the lone detail ordering could be slightly more scannable with explicit param names, but it's already near-optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-style tool (4 params, no nesting, no enums, no annotations, no output schema), the description covers the essentials: what's fetched, the limit bounds, and time format. It leaves a couple of minor gaps — the default behavior when time params are absent (0) and ordering of results — but nothing that critically blocks correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates substantially: 'default 50, max 200' explains the limit semantics and 'epoch-ms time range' clarifies the unit/format for start_time_ms and end_time_ms. These format hints go beyond what the schema's type/title fields convey, directly answering the most likely agent questions for an otherwise simple 4-parameter interface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('Historical orders') and scope ('for a symbol'), making the primary function unambiguous despite lacking an explicit verb. It correctly implies this retrieves past orders per symbol, distinguishing it from siblings like get_open_orders, though it doesn't explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: 'for a symbol' and 'historical' imply this is for past order lookup, contrasted with get_open_orders and get_order among the siblings. However, there's no explicit guidance on when to prefer this over get_order, get_fills, or get_order_by_client_id, nor exclusions for when not to use it — leaving the agent to infer the decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation ('get') but does not describe the output format or any side effects. It mentions 'enforces' but doesn't clarify if the rules affect other tools. Lacks detail on return structure, making it harder for an agent to use the result effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. It efficiently conveys what the tool does and a typical use case. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, the description is mostly complete. It explains the purpose and a use case. However, it doesn't mention the output schema or any potential prerequisites (like authentication). Given the simplicity, this is a minor gap, so a 4 is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100% and no additional explanation is needed. The description adds nothing about parameters, but since none exist, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'get' and the resource 'safety rules', and specifies it returns the full list. It sets it apart from sibling getters by focusing on anti-hallucination and safety rules. However, it could more explicitly distinguish it from other safety-related tools, but the name is self-explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage scenario: 'Use it to explain to the user why an action was blocked.' This gives a concrete when-to-use instruction. It doesn't mention when not to use it, but for a simple read-only getter, that's acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the effect (cancelling an order is low-risk and reversible in effect), which is useful, and it states the directness (no token needed). However, it doesn't describe failure modes (e.g., what happens if the order is already filled or cancelled), or the response format. The 'never from memory' warning is a good safety disclosure, but overall it's a moderate disclosure for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three short sentences. The main action is front-loaded ('Cancel ONE specific open order by orderId'), followed by safety context and a source warning. Every sentence adds distinct value — no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and no output schema, the description covers the purpose, the restrictive scope, and the source of order_id. It lacks details on what happens on failure (e.g., if the order doesn't exist), and doesn't explain the 'symbol' parameter's role. For a mutation tool with zero annotation support, it covers the essentials but not edge cases. An agent would likely call it correctly for a normal case but might not know how to handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the two parameters. It mentions 'order_id' and where it must come from, which adds meaning beyond the schema's bare 'Order Id' title. However, it doesn't explain the 'symbol' parameter — why it's needed and how it relates to the order. Symbol's purpose is implied but never states that the order belongs to that symbol or that symbol is used for validation. Partial compensation leaves a gap on the symbol parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cancels ONE specific open order by orderId, which is a specific verb+resource. It distinguishes from siblings like prepare_cancel_all_orders and prepare_dual_revoke by explicitly saying 'ONE specific open order' and 'which orders it never applies to' — the restriction to a single identified order differentiates it from bulk cancel tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use it: when cancelling a single identified order, and crucially states the order_id must come from get_open_orders or a prior placement, never from memory. It doesn't explicitly name the alternative for cancelling all orders, but the 'single' qualifier implies not for bulk cancellation, and the sibling list shows prepare_cancel_all_orders exists. Clear context is given, but it doesn't explicitly say 'for bulk cancels use prepare_cancel_all_orders'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose a key trait—this operation creates nothing—and indicates an external exchange call is made. However, it does not mention error behavior, latency, authentication needs, or what the returned verdict looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core purpose, a sequencing rule, and a rationale with no filler. The non-mutating trait is front-loaded before the usage instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description omits both parameter semantics and return-value expectations. It correctly conveys when to use the tool but not enough about how to invoke it correctly or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level meaning. The agent is left to infer what base, quote, top, bottom, row, quote_investment, and grid_type represent solely from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action—ask the exchange to validate spot-grid parameters—and explicitly frames it as a non-creating operation. This distinguishes it from prepare_create_spot_grid and other spot-grid tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit sequencing guidance: 'Always run this before prepare_create_spot_grid.' It also states why this tool should be used over local reasoning, making the selection criterion unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It mentions the limitation of 'latest 100' but does not address other aspects like read-only nature, authentication requirements, or error conditions. Some transparency is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the tool's purpose, scope, and returned fields without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for a simple retrieval tool: it states what is returned, the limit, and the primary parameter. It does not describe the output structure, but that is not required since no output schema exists. Overall, the context is mostly complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and types with no descriptions. The description clarifies that 'symbol' refers to the trading pair, but it does not explain the purpose or format of 'start_time_ms' and 'end_time_ms'. Since schema coverage is 0%, the description fails to adequately compensate for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieving recent trade fills), the resource (fills for a symbol), and the scope (latest 100, with specific fields listed). It effectively distinguishes from sibling tools like 'get_fills_by_order' by specifying 'for a symbol'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying recent fills for a symbol but does not explicitly state when to choose this over alternatives such as 'get_fills_by_order' or 'get_recent_trades'. No when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and it does a decent job: it discloses that this is a computed heuristic, that it operates on real candles, and exactly how swing_strength is used. It does not discuss error behavior or prerequisites, but the algorithmic caveat is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core purpose, then drills into the algorithm and output. The all-caps 'HEURÍSTICA computada' is slightly abrupt, but it adds useful context without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to elaborate return values. It covers the algorithm, core parameters, and output semantics at a usable level. The main missing contextual element is explicit relationship to sibling tools and a clearer definition of lookback.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains swing_strength as the candle count on each side of a fractal. Symbol, interval, and lookback are left to their names and defaults; lookback in particular could use more explanation since it determines the analysis window.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb-resource pairing: it computes market structure from real candles. It further defines the exact output: pivot fractals labeled HH/LH/HL/LL and a trend reading of uptrend/downtrend/range. This clearly distinguishes it from siblings like get_indicators, detect_fvg, or detect_order_blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool computes but gives no explicit guidance about when to choose this tool over alternatives such as get_indicators, detect_fvg, or detect_order_blocks. There is no mention of usage context, exclusions, or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose the output fields (bounds, rows, investment, profit, status), which adds some value beyond the tool name. However, it does not state that this is a read-only operation (though 'get' implies it), nor does it mention error conditions, rate limits, or any side effects. It provides partial transparency but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and enumerates the return contents. There is no fluff or redundant phrasing, making it highly efficient for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is relatively complete: it says what it returns. However, it omits potential error conditions (e.g., invalid or non-existent buOrderId), any rate-limit expectations, and how this tool fits into a broader workflow. It covers the essentials but lacks depth that could help an agent handle unusual cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists only bu_order_id with a title 'Bu Order Id', but the description clarifies that this parameter identifies the spot grid bot by its buOrderId, which is a meaningful addition. Since schema description coverage is 0%, this explanation compensates for the lack of schema detail. It could be more explicit about the format, but it correctly conveys the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the full state of a spot grid bot by its buOrderId, and enumerates the contained fields (bounds, rows, investment, profit, status). This is a specific verb-resource pair that distinguishes it from sibling tools like list_bot_orders (which likely lists bots) and prepare_create_spot_grid (which creates them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies usage when you need the full state of a single bot, but it does not mention when to prefer it over siblings like get_order or list_bot_orders, nor does it provide any exclusions or prerequisites. The context is only implicit from the phrase 'Full state of one spot grid bot'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should convey whether the operation is read-only, what happens if the order is not found, or any potential side effects. The description provides none of this, leaving behavioral aspects ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It directly states the action and the key identifier without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple retrieval operation, clearly indicating the input and that 'details' are returned. While it doesn't specify the output structure or error behavior, the minimal context is adequate given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter client_order_id is described in the tool description as 'the clientOrderId string it was created with,' which clearly defines its purpose. Although the schema lacks a per-field description, the tool description compensates adequately for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves details of a single order using the clientOrderId, which is a specific and unambiguous resource identifier. It distinguishes itself from sibling tools like get_order (likely by system order ID) and list_orders by the exact field used for lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used when you have a clientOrderId, but it does not explicitly contrast it with other order lookup tools or state conditions for use. It lacks explicit guidance on when to prefer this over get_order or list_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It adds value by noting that stale or invented profit is rejected, which is a critical behavioral trait. However, it doesn't explicitly state it's read-only (though 'current prices' implies it) or describe response format, pagination, or error behavior. It partially discloses behavior but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences with no redundancy. The first sentence states the purpose, the second provides a critical usage note. Every word contributes to clarity and actionable guidance, and the key directive is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the critical profit requirement, but it does not specify the response structure, such as whether it returns an object or array with fields like price and yield. Without an output schema, this gap means an agent may not know how to extract the required profit. For a simple get operation, it's adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify parameters. It does for `product_ids` by specifying 'comma-separated', but it does not explain `base` and `quote`, which are required. The description adds some meaning but leaves two of three parameters unexplained, so it only partially compensates for the lack of schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning current prices/yields for specific dual products, with product IDs as comma-separated input. It distinguishes itself from siblings like list_dual_products (listing) and get_dual_index (index) by focusing on prices/yields. The verb 'get' and resource 'dual prices' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a strong usage directive: the `profit` value MUST come from this tool, implying it is the authoritative source for investing. This tells the agent when to use it (before investing) but doesn't explicitly mention alternatives or when not to use it. It provides clear context without exclusions, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears the transparency burden. It discloses the source/type of the data (AI-recommended, exchange-provided) but not the return structure's full meaning, possible errors, or other behavioral details. The 'get' naming implies a read-only operation, so this is acceptable but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, dense sentences. The first states what the tool returns, and the second adds actionable usage guidance. No redundancy, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two plain parameters, the description explains the essence and even names the output fields (top/bottom/row). It does not belt-and-ribbon around symbol formats or error cases, but the core use case is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'a pair' without clarifying the expected formats for 'base' and 'quote' or the relationship between them. The agent must infer that base/quote are market symbols, which is a notable gap given the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the action ('get'), the resource ('Pionex's own AI-recommended grid parameters: top/bottom/row'), and the scope ('for a pair'). It clearly differentiates this from ordinary grid creation by emphasizing these are exchange-provided numbers rather than user-invented bounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage directive: 'Use these exchange-provided numbers instead of inventing grid bounds,' which tells the agent when this tool should be called. It does not explicitly name alternative tools or edge cases, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key behaviors: it pages backwards, returns an oldest-first flat list, and is capped at 5000 candles. These cover pagination, ordering, and limits. It doesn't mention error handling or rate limits, but these are less critical for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The core action and key differentiator are front-loaded, and the use case and limit are added succinctly. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists and covers returns, the description omits essential usage details: how to set end_time_ms for paging backwards, how total interacts with paging, and what happens if total exceeds 5000. For a tool designed for long lookbacks, this information is critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies total is the number of candles ('Fetch MORE than 500 candles') but does not explain symbol, interval, or the crucial end_time_ms parameter used for pagination. This is a significant gap that leaves the agent guessing about parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches more than 500 candles by paging backwards, which is a specific verb and resource. It also distinguishes itself from the sibling get_klines by implying a higher limit and historical pagination, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use for backtests/long lookbacks', giving a clear context for when to choose this tool. It also notes a 5000 candle cap, implying that ordinary short lookbacks might use get_klines, though it doesn't explicitly name the alternative. This is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explicitly discloses this is a computed heuristic and not an exchange fact, and it details the output state (open/partially_filled/filled) and how detection works. This is a strong disclosure beyond mere tool naming.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it leads with the core definition, then explains key parameters, and ends with a crucial caveat about heuristic nature. Every sentence adds value and there is no redundancy or fluff, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core logic, parameter effects, and output structure, and since an output schema is present, the return format need not be restated. It misses minor edge-case info (e.g., behavior when no FVGs found), but overall provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must explain parameters. It clearly describes the meaning and effect of only_open and min_gap_pct, but leaves symbol, interval, and lookback unaddressed. While the latter are self-explanatory, a more complete explanation would raise the score; as is, it partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool detects Fair Value Gaps and provides the exact algorithmic conditions (e.g., low[i+1] > high[i-1] for bullish), clearly differentiating it from siblings like detect_order_blocks by its specific resource (FVG) and logic. The purpose is unambiguous and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's functionality and how parameters modify behavior (only_open, min_gap_pct), which implies when it might be used. However, it does not explicitly state when to use this tool versus alternatives such as detect_order_blocks, nor does it provide any 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses that the tool returns symbol metadata, implies a read-only operation, and adds the operational caution that values must not be sourced from memory. It does not describe error behavior or market_type effects, but for a simple lookup this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the core return fields front-loaded and the usage caution in the second sentence. No redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter metadata lookup it is largely self-contained, and the description names the key return fields despite no output schema. However, it omits any explanation of `market_type` and symbol-format expectations, and there are no annotations to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter documentation. It does not define the `symbol` format or the `market_type` default/possible values; only the phrase 'one symbol' appears. The listed return fields do not map to parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Exchange metadata for one symbol') and enumerates the concrete fields returned (precision, minimum trade size, minimum notional, enabled status). This clearly distinguishes it from price/ticker/depth siblings, which return market data rather than symbol configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to call it 'before sizing any order' and cautions that precision and minimums 'come from here, never from memory.' This is a clear when-to-use directive, even though it does not name exclusion conditions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It provides meaningful behavioral context: prices are fetched live, value and weight are computed from those live prices, results are sorted by value, and a total is included. This goes beyond the schema and helps the agent predict 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core output and then adding behavioral detail on live pricing and calculation. There is no repetition of schema fields or irrelevant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small, read-only tool with a single optional parameter and an output schema, the description is mostly complete. It names what is returned, how it is sorted, how values are computed, and that prices are live. The only real gap is not providing usage/routing guidance or explicit allowed values for quote, but the default value and clear language partly compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, and there is one parameter, quote. The description explains that the portfolio is valued in the quote currency, which gives meaning to the quote parameter. Combined with the default of USDT in the schema, this is enough for an agent to understand the parameter's role, though it doesn't enumerate possible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's output: a whole-portfolio view in quote currency with per-coin amount, live price, value, weight sorted by value, plus total. This is specific enough to distinguish the tool from siblings like get_balances and get_price, which serve narrower or different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a live-valued portfolio snapshot is needed, but it does not explicitly state when to choose this tool over get_balances, get_price, or other pricing/balance tools. No alternatives or explicit exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two major behavioral traits: it does NOT create anything (deferred execution) and it returns a confirmation token. It also enumerates the validation dimensions (bounds, row 2-200, grid_type whitelist, notional cap, exchange checkParams endpoint). This is honest and actionable. Could add what happens on failure (error message? no token?), which is a minor 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key fact 'STEP 1 of 2'. Each clause carries weight: validation types, the checkParams endpoint, the token, and the explicit negation of creation. No fluff, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a complex two-step creation flow with 7 params and no output schema. The description covers the essential flow (prepare → confirm) and the validation scope. Missing: parameter constraints details (beyond row 2-200), default for grid_type not explained, exchange-specific API requirements not mentioned. Given its complexity, would benefit from a 'see check_spot_grid_params for details' pointer. Slightly short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 0% of parameters. The description mentions 'row 2-200' and 'notional cap' and lists validation types but not the semantics of each parameter. It names base, quote, top, bottom, row, quote_investment as the required set (implicitly by listing them) but doesn't explain what top/bottom mean (price bounds?), what grid_type does (arithmetic vs geometric), or the format of quote_investment. The description helps a bit but doesn't fully compensate for 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies itself as STEP 1 of a two-step creation process, names the specific resource (spot grid bot) and its actions (validates locally and against exchange). The phrase 'Nothing is created until confirm_action with that token' disambiguates it from its sibling prepare_cancel_spot_grid and the actual creation step confirm_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use it: as the first step before confirm_action. It implicitly says not to use it if you only need to check parameters (sibling check_spot_grid_params exists) or to cancel (prepare_cancel_spot_grid). However, it doesn't explicitly state alternatives like check_spot_grid_params. It does provide clear procedural sequencing which is highly useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses that levels are [price, size] strings returned verbatim from the exchange, and specifies the limit range. It does not explicitly state it is read-only, but the nature of a 'get' operation and absence of side effects are strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then the limit detail, then the output format. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description fully covers what an agent needs: what is returned (bids/asks), the limit constraint, and the exact format of each level. No missing information that would cause an incorrect call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameter coverage, so the description must compensate. It adds the limit range (1-1000) beyond the schema's default, which is valuable. For 'symbol', the description does not need extra detail as the name and type are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the order book (bids and asks) for a symbol, using a specific verb and resource. It differentiates from siblings like get_book_ticker and get_price by specifying the depth levels, so an agent can select it appropriately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the limit range and default but does not explicitly mention when to use this over alternative tools. It implies usage for order book depth, but lacks explicit exclusions or references to siblings that serve similar purposes (e.g., get_book_ticker).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Excellent disclosure of behavioral specifics: exact allowed interval strings, limits range, default behavior, and response time format. Since no annotations are provided, the description carries the full burden, and it delivers concrete operational details beyond what the schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Compact, efficient description with critical constraints front-loaded (interval mandatory, limits). Could be slightly more structured, but the key information is dense and immediately useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple market data tool with no output schema, it covers the core requirements: intervals, limits, end time, and response time format. The absence of explicit return-structure details is acceptable given there's no output schema to reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so by explaining interval enumeration, limit range and default, plus end_time_ms semantics (0 = now). This adds real meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Candlesticks for a symbol' with a specific verb (get) and resource (klines/candlesticks). It distinguishes itself from siblings like get_klines_history and get_price by specifying the exact interval format and response detail (epoch milliseconds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by specifying mandatory interval and limit constraints, but does not explicitly state when to use this versus get_klines_history or other market data tools. The conditional context (recency, specific intervals) could be more explicit for agent routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable behavioral detail: mid-price calculation, fallback behavior for illiquid pairs, and authoritative sourcing. It does not mention error cases or market_type-specific behavior, but the output schema covers return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler. The formula and normal-case behavior are front-loaded, followed by an authoritative usage directive. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple price-query tool, the description is largely complete: purpose, formula, fallback behavior, and usage guidance are all present, and the output schema handles return values. The only notable gap is the undocumented market_type parameter, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation. It only generically references 'symbol' and says nothing about market_type, its allowed values, or its effect on the price. This is a meaningful gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a live mid-price for a symbol, includes the exact formula, and notes a fallback to last traded price. It further positions itself as the ONLY valid source for a current price, which distinguishes it from price-adjacent sibling tools even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: whenever a current price is needed. It also strongly forbids quoting prices from memory, effectively ruling out alternatives as invalid sources for current pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does a good job: it discloses the exchange-faithful spelling, BASE_QUOTE format, market_type domain, and case-insensitive substring filtering. It does not mention pagination, result ordering, or response shape, but the core behavior is clearly communicated for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and every sentence adds useful information: what is listed, the exact naming format, the valid market_type values, the search behavior, and the intended usage. Nothing is wasted, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters and no output schema, this description provides enough selective an agent to call the tool correctly: symbol format, filter semantics, and market type are all clear. It still doesn't describe the exact return structure, pagination, or what happens when no symbols match, so it is near-complete but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must make up for the missing parameter docs. It does: it defines market_type as 'SPOT' or 'PERP' and describes search as an optional, case-insensitive substring filter. It leaves the default values to the schema, which is reasonable because the defaults are already visible there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List real trading symbols on Pionex,' and further pins down the exact symbol format as 'BASE_QUOTE, e.g. BTC_USDT.' This makes it distinct from symbol-related sibling tools and clearly communicates what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly tells an agent when to use this tool: 'Use this instead of guessing symbol names,' and it gives the market_type and search context. It also says exactly how the filter works, but it does not explicitly contrast against sibling tools like get_symbol_info or list_dual_symbols, so it stops short of a full when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool is step 1 of 2, returns a confirmation token (implying it does not complete the subscription), and requires a live 'profit' value. This transparently sets expectations about the staged nature and output, though it could mention side effects or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no wasted words. It front-loads the most important information ('STEP 1 of 2') and includes only actionable guidance (exactly one amount, profit source, return token).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description covers the critical aspects: the step sequence, the key parameter constraints, and the return value. It could be more explicit about the base and product_id parameters, but the overall context is sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds crucial meaning for the profit parameter ('must be the live value from get_dual_prices') and the mutual exclusivity of base_amount and currency_amount ('Provide EXACTLY ONE'). It does not explain base, product_id, or client_dual_id, but these are either self-evident or optional, so the key ambiguities are addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's role as 'STEP 1 of 2 to subscribe to a dual-investment product,' specifying both the action (prepare) and the resource (dual-investment subscription). It also differentiates from siblings by mentioning the two-step process and the confirmation token, making it distinct from other prepare_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to initiate a dual-investment subscription) and gives a specific instruction to use the live value from get_dual_prices for the profit parameter. However, it does not explicitly state when not to use it or name alternative tools (e.g., confirm_action), though the two-step framing implies the next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the key non-obvious behavior: this step only returns a confirmation token, and nothing is cancelled until confirm_action. It does not cover token expiry or permissions, but the essential two-phase behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence conveys the step sequence, scope, return value, and deferred cancellation. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter prepare action with no output schema, the description covers the input scope, the return value, and the required follow-up action via confirm_action. Nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It identifies the symbol as the scope of the cancellation, mapping directly to the only required parameter. For a single obvious string parameter, this is sufficient context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'cancel EVERY open order on a symbol.' It also clarifies it is only STEP 1 of 2, distinguishing it from siblings like cancel_order and confirm_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly frames when to use the tool ('STEP 1 of 2') and explains that the actual cancellation is deferred until confirm_action. It does not explicitly contrast with single-order cancellation or other cancel alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the tool only validates (no order is sent) and returns a confirmation token, and it also conveys important behavior like requiring the agent to present the summary and await approval. It does not detail failure modes, auth requirements, or rate limits, but the core behavior of validation-only is clearly conveyed, which is more than many tool descriptions do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured: it starts with the step indicator and core behavior, then provides parameter-specific guidance in a clear, bullet-like format. Every sentence adds value—there is no fluff. It is slightly longer than average but appropriate given the complexity of order types, and the information is front-loaded with the safety-critical note that no order is sent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the existence of an output schema, the description covers the essential context comprehensively: it defines the two-step flow, specifies validation behavior, details parameter conditions, and instructs the agent on the follow-up action (calling confirm_action after user approval). It does not mention prerequisites like prior balance checks, but those are part of validation, and with an output schema present, return-value details are not required. Overall, the description is sufficient for an agent to call this tool correctly in the intended flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema coverage by explaining the key parameters: side, order_type, and the conditional requirements for price, size, and amount across LIMIT, MARKET BUY, and MARKET SELL. It also clarifies that all numeric values should be provided as strings exactly as they should reach the exchange. While it does not explain symbol, ioc, or client_order_id, the most complex and interdependent parameters are well described, and the string-format warning is particularly valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is 'STEP 1 of 2 to place a spot order' and clarifies that it validates against live exchange data and returns a confirmation token, with the crucial note that 'NO order is sent.' This clearly differentiates it from sibling prepare tools (e.g., prepare_dual_invest for dual products) and from confirm_action, so an agent understands exactly what this tool accomplishes versus other preparation steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it is step 1 of 2 for placing a spot order, and it directs the agent to 'show the summary to the user and only call confirm_action with the token once they explicitly approve.' This establishes the when-to-use context and the sequential relationship with confirm_action, leaving little ambiguity about when this tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It clearly conveys that this is a mutating execution, controlled by a single-use token, and that the executed parameters were already fixed at prepare time. It does not explicitly describe failure modes or irreversible real-world effects, but the human-approval requirement and single-use constraint cover the most important safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly written, with the core action front-loaded and the critical approval condition immediately after. Every phrase adds value and nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter confirmation tool with an output schema, the description covers the main action, the prerequisite human approval, the scope of actions, the single-use token, and the immutability of the prepared parameters. This is complete enough for an agent to select and call confirm_action correctly alongside many prepare_* siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, confirmation_token, and schema description coverage is 0%. The description compensates by labeling it a 'single-use token' and by explaining that the executable parameters are stored at prepare time, so the token is the only thing this call accepts. It could have added where the token comes from, but the meaning is sufficiently clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('execute') and resource ('previously prepared action') and enumerates the action types: order, cancel-all, rebalance, bot, or investment. The 'STEP 2 of 2' framing and reference to prepare_* tools clearly distinguishes this tool from the prepare_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to only call after the human user has explicitly approved the summary shown by the prepare_* tool. It also clarifies that nothing can be changed at this stage, which tells the agent to return to the prepare_* step if any adjustment is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Server status' clearly implies a read-only diagnostic operation, and the guidance to call it first reinforces that it is safe and non-mutating. It does not explicitly state 'no side effects' or auth requirements, but the status semantics make the behavior sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences. The first front-loads the exact output contents, and the second provides the usage trigger. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with an output schema, the description is complete: it states what the tool returns, when to call it, and why it matters. The output schema handles return-value details, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. The baseline of 4 applies; no parameter documentation is needed and none is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('server status') and enumerates the specific contents returned: version, capability gates, active limits, and API credential configuration. This distinguishes it from all sibling trading tools, none of which are status/diagnostic calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit, actionable guidance: 'Call this first when a session starts or when a tool reports it is disabled.' This tells the agent exactly when to invoke the tool, which is especially valuable given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It explicitly states 'dry-run, nothing executed,' which is the critical non-destructive behavior. However, it does not mention other potential behaviors like what the plan contains, limits, or error conditions. The main safety aspect is covered, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key dry-run behavior, then parameter explanations, then the next-step pointer. No fluff, every sentence earns its place. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are not required. The description covers purpose, parameter semantics, behavioral safety, and the follow-up workflow. It is complete for an agent to correctly invoke the tool and understand its role among siblings, such as prepare_rebalance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and a default, with 0% coverage. The description fully compensates by explaining target_weights_json with an example and a constraint (fractions summing to ~1.0), and threshold as 'minimum weight drift before an order is generated.' This adds meaningful semantics beyond the schema, making parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a dry-run computation of MARKET orders to reach target portfolio weights. The verb 'Compute' and specific resource 'rebalance plan' are present, and the dry-run qualifier immediately distinguishes it from execution tools like prepare_rebalance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the intended workflow: 'Review the plan, then use prepare_rebalance to get a confirmation token.' This tells the agent exactly when to use this tool (before preparing a rebalance) and points to the next step. It implies this is for planning only, not execution, which is a clear usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alejandrorodm/MCP-Pionex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server