bybit-mcp-server

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Each tool targets a distinct operation, with clear descriptions that prevent confusion. Overlaps like get_wallet_balance and get_coin_balance are differentiated by specific parameters and purposes.
Naming Consistency5/5
All tools use a consistent snake_case naming pattern with intuitive prefixes (get_, set_, place_, amend_, cancel_, etc.) that clearly indicate the action.
Tool Count4/5
28 tools cover a wide range of exchange operations without being excessive. The count is appropriate for the depth of functionality provided, though slightly on the higher side.
Completeness4/5
The tool surface covers the core trading lifecycle (market data, orders, positions, account, transfers) comprehensively. Minor gaps exist, such as the absence of direct deposit/withdraw tools and advanced position margin adjustments.
Average 3.9/5 across 28 of 28 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a safe, read-only operation. The description adds no further behavioral details (e.g., rate limits, data freshness). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action 'Get trading fee rate'. The parameter list is clear. However, it uses a Python docstring format which may not be ideal for all contexts, but it is concise with no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (which likely documents return values), the description is minimally adequate. However, it lacks details about fee rate specifics (e.g., maker/taker, percentage format) that would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description is the sole source of parameter meaning. It provides basic semantics (category: product type, symbol: name, baseCoin: coin) but lacks specifics like allowed values (despite mentioning 'spot, linear, inverse, option' as examples, not as full enumeration), format, or defaults. This is insufficient for precise invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get trading fee rate' which clearly indicates the tool's purpose. It lists relevant parameters (category, symbol, baseCoin). However, it does not differentiate from sibling tools like get_funding_rate_history, but the name itself is sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives, no context on prerequisites (e.g., specific permissions), and no examples. This is a significant gap for an AI agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the bar for additional behavioral context is low. The description adds only 'real-time' as a qualifier, but does not disclose authorization needs, rate limits, or side effects, nor does it contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one introductory sentence followed by a compact list of parameters with explanations. Every sentence is purposeful, and the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it lacks context on pagination behavior (how to use cursor), parameter interplay, and frequency of data updates. For a tool with 6 parameters and no schema descriptions, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It briefly explains each parameter (e.g., 'category: Product type - linear, inverse, option'), adding value over the schema. However, it does not detail valid combinations or constraints for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query real-time position data', which is a specific verb+resource combination. However, it does not explicitly distinguish this tool from sibling tools like get_account_info or get_coin_balance, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use get_positions versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where this tool is preferred, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, establishing read-only and live data behavior. The description adds 'recent' but does not specify the time window, ordering, or pagination beyond the limit parameter. Additional behavioral details would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-line summary, then lists parameters in a structured but verbose Python docstring format. It is mostly concise, though the 'Args:' header is unnecessary. Overall efficient with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be detailed. Parameters are well covered in the description. However, missing details about time window for 'recent', pagination support, and any rate limits or ordering order (e.g., newest first) leaves some gaps for a tool returning live trades.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well by explaining each parameter. It specifies valid values for category, explains baseCoin and optionType are for options only, and provides limit ranges per category. This adds significant value beyond the property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query recent public trading data', indicating a read operation on public trades. It distinguishes from sibling get_trade_history (private trades), but could be more explicit about how it differs from other public data tools like get_tickers or get_orderbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to prefer get_public_trades over other public data tools, nor any prerequisites or limitations. The description only lists parameters without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Query' is consistent and adds the parameter list. However, it does not disclose any additional behaviors beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short docstring with a clear 'Args:' list. It front-loads the main verb and then lists parameters efficiently, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count and 0% schema coverage, the description covers parameter meanings but lacks mention that 'category' is required, and does not help agents choose between this and similar tools like get_order_history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining all 7 parameters (e.g., 'category: Product type - spot, linear, inverse, option'). This adds meaning beyond the schema's type/name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query trade execution history', which is a specific verb and resource. It distinguishes from siblings like get_order_history and get_public_trades by focusing on execution history, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_order_history or get_public_trades. The description only lists parameters without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds little beyond parameter context. It does not contradict annotations and is consistent, but does not enrich behavioral understanding further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short docstring: a one-line purpose followed by a terse Args list. It is front-loaded and avoids unnecessary text, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters (1 required) and existence of an output schema, the description adequately covers each parameter's meaning and purpose. It lacks mention of pagination behavior (cursor/limit) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing each parameter and its semantics (e.g., category: 'Product type - spot, linear, inverse, option'). This adds meaning beyond the raw schema, though enum values are not formalized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query instrument specifications and trading rules', using a specific verb and resource. It distinguishes from siblings like get_tickers or get_orderbook, but does not explicitly differentiate, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters with brief descriptions (e.g., category as product type), implying required context, but provides no guidance on when to use this tool versus alternatives like get_tickers or get_coin_info.
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 annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's behavioral disclosure is not critical. The description does add some behavioral context by specifying limit constraints (max 50, default 20) and timestamp units (milliseconds), but does not discuss pagination behavior or output details. This provides moderate added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a focused docstring with a one-line summary followed by parameter definitions. Each parameter gets one concise line. However, the formatting as code-style Args could be more readable for an agent. It is efficient but slightly verbose due to the parameter enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 optional parameters, an output schema, and readOnlyHint, the description covers parameter semantics well. Since an output schema exists, the lack of return value explanation is acceptable. However, it does not mention pagination behavior beyond cursor/limit. Overall sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description bears full responsibility for parameter semantics. It lists all 7 parameters with brief type/format hints (e.g., 'UUID of transfer', 'Coin name', 'Transfer status - SUCCESS, PENDING, FAILED', 'Start timestamp in milliseconds'). While not exhaustive, it adds essential meaning that the schema lacks. A score of 5 would require more detailed formats or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource phrase 'Query internal transfer records', which states the tool's function. The parameter list further specifies what can be filtered. However, the description does not explicitly differentiate it from sibling tools like 'internal_transfer' or 'get_coin_balance', so it lacks full distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or when not to use it. The agent would have to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and openWorld hints; description adds no further behavioral context, such as pagination behavior or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a purpose sentence and a parameter list, but the list format is verbose and repeats information from the schema names. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately explains input parameters, but lacks contextual guidance such as typical use cases or data interpretation. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides parameter explanations and examples for category and intervalTime, adding value beyond schema. However, other parameters like startTime and endTime lack explanatory text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'open interest for each symbol', distinguishing it from sibling data retrieval tools like get_kline or get_orderbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided; does not indicate when to use this tool versus alternatives like get_kline or get_funding_rate_history.
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 adds some value beyond annotations (readOnlyHint, openWorldHint) by noting limit max 100 and default 50. However, it does not mention pagination behavior, response structure, data freshness, or any side effects. Given annotations already cover read-only and open-world, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for purpose and a compact parameter list. Every sentence adds value, and there is no extraneous text. It follows a clear, front-loaded structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, an output schema, and siblings like get_trade_history, the description is adequate but not complete. It lacks context on what 'closed P&L' means practically, typical use cases, or authentication needs. The presence of an output schema reduces the need to describe return values, but usage context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining all 6 parameters: category as product type, symbol as name, start/endTime as timestamps in ms, limit with max/default, and cursor for pagination. Some details like exact constraints on symbol format are missing, but overall it adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Query closed profit and loss records,' which is a specific verb+resource pair. It clearly distinguishes this tool from siblings like get_order_history or get_trade_history by focusing on closed P&L data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, when to use pagination, or how it relates to other account history tools. The sibling list is unhelpful without explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds parameter details but does not disclose pagination behavior, response size limits, or concurrency implications. With annotations, the bar is lower, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring list, front-loaded with the purpose. Every sentence adds value. Could be slightly more efficient but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 1 required, and an output schema (which means return values need not be described), the description is adequately detailed. It covers all parameters and their roles. Missing mention of default behavior or error handling, but that is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all 7 parameters with examples (e.g., category: 'spot, linear, inverse, option', orderStatus: 'New, PartiallyFilled, Filled, Cancelled, etc.'). This adds significant meaning beyond the bare schema. However, limit and cursor explanations are minimal ('Pagination cursor').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query order history' which is a specific verb-resource pair. This distinguishes it from sibling tools like 'get_open_orders' (current open orders) and 'get_trade_history' (executed trades).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. With many sibling tools like get_open_orders, get_trade_history, get_closed_pnl, the description does not differentiate use cases or provide when-not-to-use hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's burden is lower. It does not add behavioral context like pagination behavior or rate limits; thus a baseline 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with an Args section, making it easy to parse. It is informative without being overly verbose, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and an output schema, the description explains all parameters adequately. It does not discuss the output, but that is covered by the output schema. A small gap is the lack of usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed explanations for each parameter (e.g., category options, interval values, timestamps). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query kline/candlestick data', using a specific verb and resource. It distinguishes from sibling tools like get_tickers or get_orderbook, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context or exclusions, leaving the agent to infer usage from the tool name and parameters 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?
Annotations already indicate destructiveHint=true. The description adds that the operation is 'HIGH risk' and 'requires confirmation', which provides useful behavioral context beyond annotations. However, other traits like idempotency or effect on existing positions are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one header line and a structured parameter list. It is front-loaded with the risk warning and parameter details. However, the parameter list could be more tightly integrated into a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists but is not referenced. The description covers the basic action and parameters but lacks details on error scenarios, confirmation flow, or impact on existing positions. Given the destructive nature, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides meaning for all parameters: category type, symbol name, leverage ranges (0 to max for risk limit). This adds significant value beyond the raw schema fields, though it does not specify exact allowed values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Set leverage for a position' which clearly identifies the action and resource. It is distinct from sibling tools like set_trading_stop or set_auto_add_margin which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The warning 'HIGH risk - requires confirmation' implies careful use but does not explicitly state when to use or when to avoid this tool. No alternative tools are mentioned. The guidance is minimal but not misleading.
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 already indicate destructiveHint=true and readOnlyHint=false, so the mutation behavior is known. The description adds 'MEDIUM risk' but no additional behavioral details like side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and uses a structured Args block. It is slightly verbose but every sentence is informative. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and an output schema exists, the description covers all parameters and the tool's purpose. It lacks explanation of value differences for price trigger types, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description provides clear meanings for all 10 parameters, including types and examples like 'Product type - linear, inverse' for category, greatly enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets take profit, stop loss, or trailing stop for a position. It distinguishes from siblings like place_order and set_leverage by focusing on risk management stops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'MEDIUM risk' but does not explicitly guide when to use this tool versus alternatives like place_order or confirm_order. Usage context is implied but not stated.
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 annotations already provide readOnlyHint=true and openWorldHint=true, so the description does not need to repeat those. It adds parameter details but no additional behavioral context like data freshness or pagination behavior, making it adequate but not greater.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the one-line purpose and then structured as an Args list. It is concise and every sentence provides value, though the parameter list could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with clear descriptions, and since an output schema exists, the description does not need to cover return values. It is complete for a query tool, though it could mention typical usage constraints like date ranges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by explaining all five parameters: category (linear/inverse), symbol (e.g., BTCUSDT), startTime, endTime, and limit with max and default values. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query historical funding rate' using a specific verb and resource. This distinguishes it from sibling tools like get_fee_rate or get_tickers, as funding rate history is a unique concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying historical funding rate but does not explicitly state when to use it versus alternatives or mention any exclusions, such as not using it for current funding rates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, so the description's mention of 'MEDIUM risk' adds some context beyond annotations. However, it does not explain the consequences of enabling auto-add-margin (e.g., potential liquidation risk) or what happens on failure. While not contradictory, the description lacks depth for a destructive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence and a parameter list. Every word is useful, and the risk level is front-loaded. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple mutation operation and the presence of an output schema (not required to explain return values), the description covers the core functionality and parameter meanings. However, the lack of usage guidelines and behavioral depth prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema by listing each parameter with its allowed values (e.g., autoAddMargin: 0 to turn off, 1 to turn on; positionIdx: 0 for one-way, 1 for hedge buy, 2 for hedge sell). Schema coverage is 0%, so the description fully compensates by clarifying the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Turn on/off auto-add-margin for isolated margin position (MEDIUM risk).' It uses a specific verb (turn on/off), identifies the resource (auto-add-margin), and distinguishes itself from sibling tools like set_leverage or set_trading_stop by focusing on auto-add-margin functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, conditions for turning auto-add-margin on/off, or mention any related tools for comparison. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true; the description adds 'HIGH risk - requires confirmation', providing clear behavioral context of mutability and safety confirmation. It explains that it cancels all open orders, which is essential. Could detail side effects like irreversible loss of pending orders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences plus a minimal parameter list. Front-loaded with purpose and risk. Could be slightly more structured with bullet points, but it's efficient and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, reducing need to describe return values. However, for a high-risk destructive tool, additional context about system-wide effects, partial cancellation behavior, and confirmation mechanism would be helpful. The description is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description carries the burden. It lists parameters with brief meanings: category includes enum values 'spot, linear, inverse, option', and others are described as 'product type', 'symbol name', etc. This adds value over bare schema, though more detail on constraints (e.g., which params are required) would improve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel all open orders', specifying the action and scope. It distinguishes from sibling 'cancel_order' by targeting all orders, not just a single one. The HIGH risk warning adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns of HIGH risk and confirmation requirement, but does not explicitly state when to use vs. alternatives like 'cancel_order'. It lacks guidance on scenario selection or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and open-world. The description adds context about what data is returned (chain info, status) but does not disclose additional behaviors like rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a clearly formatted Args section, no wasted words or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema supplies return value details, the description adequately covers the tool's input and behavior for a simple parameter set, though it omits potential error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the 'coin' parameter and the effect of omission ('returns all coins'), adding meaning beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Query' and resource 'coin information' and specifies inclusions like 'chain info, deposit/withdraw status', which clearly distinguishes it from siblings like get_coin_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining the parameter behavior (returns all coins if omitted) but lacks explicit guidance on when to use this tool versus alternatives like get_coin_balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no new behavioral context beyond implying a read operation. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence that immediately conveys the tool's purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an output schema, the description is nearly complete. It does not specify the format of the returned time, but this is likely covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema description coverage is 100%. The description does not add parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current Bybit server time'. It is specific and distinguishes from sibling tools, which are mostly data retrieval or trading actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. However, given its unique purpose (server time), alternatives are unlikely. Minimal context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds parameter-specific behavioral details (limit ranges per category), but does not disclose other traits like rate limits, output format, or snapshot nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one summary line followed by parameter details. No extraneous text, front-loaded with purpose. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers input semantics. It could mention that it returns a snapshot of bids/asks, but standard terminology and annotations make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains all three parameters: category (lists values), symbol (example), and limit (with per-category ranges). This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query order book depth data', using a specific verb-resource combination that uniquely identifies the tool's function. It distinguishes from siblings like get_tickers and get_kline by focusing on depth data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for order book depth but lacks explicit guidance on when to use or not use this tool versus alternatives. No comparison to similar tools or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the tool includes 'account risk information' beyond a simple balance, but does not discuss authorization, rate limits, or any side effects. The annotations already declare readOnlyHint=true and openWorldHint=true, but the description does not elaborate on what openWorldHint entails. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences for purpose, then a clear arg list) and front-loaded with the main action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description need not detail return values. It covers the tool's scope and both parameters adequately. Minor gap: it does not mention that accountType is required, but that's clear from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the schema, which has 0% coverage. It enumerates valid values for accountType and explains the behavior of the coin parameter (returns all coins if omitted). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get wallet balance and account risk information' with a specific verb and resource. It distinguishes the tool from siblings like get_coin_balance (which gets a single coin balance) and get_account_info (which may provide broader account data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wallet balance or risk information is needed, but does not explicitly state when to use this tool over alternatives like get_coin_balance or get_account_info. No exclusion criteria or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds critical context: 'HIGH risk, requires full mode', disclosing permission/risk level beyond annotations. It does not detail failure modes or reversibility, but provides sufficient behavioral warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: a one-line summary with risk note, followed by a bulleted Args list. Every sentence adds information without redundancy. The risk warning is front-loaded, which is appropriate for a destructive operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 required params, high risk, and an output schema (not shown), the description covers essentials: purpose, risk, parameter meanings. It lacks explanation of return values (but output schema can handle that) and error cases. Slightly incomplete for a high-risk mutation tool, but adequate given the structured schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving the description to fully explain each parameter. It does so thoroughly: transferId (UUID generation), coin (example), amount (as string), and account types with explicit allowed values (UNIFIED, CONTRACT, SPOT, OPTION, FUND). This compensates completely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Transfer funds between account types under same UID', which is a specific verb and resource. It distinguishes from sibling tools like get_transfer_history (history vs. action) and place_order (different resource). However, it could be more explicit about the exclusive use case (only for same UID transfers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description warns 'HIGH risk, requires full mode', implying caution. However, it does not explain when to use this tool versus alternatives (e.g., for viewing history use get_transfer_history, for trading use place_order). No explicit 'use this when' or 'use that instead' 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?
The description mentions 'HIGH risk - requires confirmation', which aligns with annotations (destructiveHint: true, readOnlyHint: false). But it fails to specify what 'requires confirmation' means operationally (e.g., via a separate confirm_order tool) or what side effects occur (e.g., changes to order state, fees). Additional behavioral details beyond annotations are limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one sentence of purpose plus a bullet-style Args list. No filler sentences. Every line adds value (purpose, risk, parameter definitions). Structure is front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, 2 required, and an output schema exists, the description covers purpose, risk, and all parameters. However, it lacks guidance on when to amend vs. cancel/replace, error scenarios, or order state requirements. The risk warning hints at a confirmation workflow but doesn't detail it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides brief explanations for all 9 parameters: e.g., 'Product type - spot, linear, inverse, option' for category, 'New order price' for price. This adds meaning beyond parameter names, though format constraints and examples are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Amend an existing order' with a high-risk warning, which distinguishes it from siblings like place_order, cancel_order, and get_open_orders. The verb 'amend' and resource 'order' are specific, and the risk flag adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context via the risk warning and specifies required parameters (category, symbol) and the condition that either orderId or orderLinkId is needed. However, it does not explicitly discuss when to amend versus cancel and replace, nor does it mention prerequisites like order status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'MEDIUM risk - no confirmation required' which provides behavioral context beyond the destructiveHint annotation. However, does not describe side effects or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with one sentence plus bulleted parameter explanations. No superfluous text, all information is relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good coverage of purpose, risk, and parameters. Lacks mention of failure conditions or confirmation of cancellation. Output schema presence reduces need for return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains each parameter (category types, symbol name, order ID options) which adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Cancel an existing order' with specific verb and resource. Mentions risk level and distinguishes from siblings like cancel_all_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implies cancellation of active orders but does not specify prerequisites or scenarios where it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true (output may vary). The description adds detail about the specific data retrieved (margin mode and configuration), which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no unnecessary words. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema, the description sufficiently explains what the tool does. It could be slightly more detailed about the configuration info scope, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. The description sets expectations for output content, which is helpful. Baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account margin mode and configuration info, using a specific verb 'Get' and specifying the resource. It distinguishes from siblings like get_wallet_balance or get_coin_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Given many sibling tools, a brief note on context would help but the name and description imply its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to reaffirm safety. The description adds no extra behavioral details beyond the annotations, such as rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose followed by clear parameter explanations. No wasted words, and the most important information comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters and an existing output schema, the description covers inputs and purpose adequately. No further details about output are needed due to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining category as product type (spot, linear, inverse, option) and symbol with example and behavior when omitted. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get latest price ticker for a symbol' with specific verb and resource. It distinguishes from siblings like get_kline and get_orderbook, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that omitting symbol returns all tickers for the category, giving context for the optional parameter. However, it does not explicitly state when to use this tool over alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true. The description adds valuable transparency with 'HIGH risk - requires confirmation', which is beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-line summary and risk warning, followed by a clear, concise parameter list. No redundant information; every sentence is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters with 0% schema coverage, the description covers all parameters adequately. Output schema exists, so return value explanation is unnecessary. Could add more on confirmation process but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's meaning (e.g., 'reduceOnly: Reduce only (true means close position)'). Covers all 11 parameters with useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Place' and resource 'order', and distinguishes from sibling tools like confirm_order and cancel_order by explicitly noting 'HIGH risk - requires confirmation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for placing orders but does not provide explicit guidance on when not to use or alternatives (e.g., amend_order for modifications). No context on prerequisites like checking balance or position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. Description adds meaning for each parameter (e.g., memberId for sub UID, withTransferSafeAmount), which is valuable beyond annotations. Does not describe return format, but output schema covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured, front-loaded with purpose, and uses a clear Args list. Could be slightly more concise, but overall efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the detailed parameter explanations, the description is complete. It covers the tool's operation and input semantics without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains all four parameters: accountType (with allowed values), coin, memberId (when needed), and withTransferSafeAmount (meaning). Adds significant meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Query coin balance of a specific account type', using a specific verb and resource. It distinguishes from siblings like get_wallet_balance by focusing on coin balance per account type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides parameter guidance but does not explicitly state when to use this tool vs alternatives. The context is clear, but no exclusions or alternative tool names 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read and dynamic results. Description adds value by specifying it retrieves unfilled/partially filled orders and explains pagination parameters, but does not disclose other potential behaviors like sorting or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with one-sentence purpose followed by a clear, bullet-like parameter list. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema (not shown) and 7 parameters, the description covers purpose, parameters, and pagination. Could mention if results are sorted or if there are any rate limits, but overall adequate for a read-only query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description fully compensates by explaining each parameter: category values (spot, linear, inverse, option), baseCoin usage context, orderId vs orderLinkId, and limit/cursor pagination details. Adds constraints like max 50 limit and default 20.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Query unfilled or partially filled orders' with specific verb 'query' and resource 'orders'. Distinguishes from sibling tools like get_order_history (filled orders) and place_order (placing orders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies tool is for open orders but does not explicitly mention alternatives or when not to use it. No exclusion criteria or context about when to use other tools like get_order_history for filled orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds important context about the two-step confirmation flow: HIGH-risk tools return a summary instead of executing, and this tool actually executes. It aligns with annotations and provides behavioral detail beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear paragraphs and a list. Every sentence adds value: first describes the overall purpose, then explains the workflow, and finally defines the parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It adequately covers the confirmation flow and the role of this tool. Minor gap: no mention of error handling or invalid confirmation_id, but it is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description defines the only parameter 'confirmation_id' as 'The confirmation_id returned by the HIGH-risk tool.' This adds crucial meaning that the schema lacks, fully compensating for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a previously prepared HIGH-risk operation after review. It names specific tools that use this pattern (place_order, amend_order, etc.), distinguishing it from sibling tools like get_wallet_balance or get_server_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the tool: after a HIGH-risk tool returns a confirmation summary, and to call with the confirmation_id. It lists the tools that generate confirmations. However, it does not explicitly state when not to use it, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/workspace/bybit-mcp-server'

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