Bybit MCP Server

Server Quality Checklist

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

Latest release: v0.1.9
Disambiguation4/5
Most tools have distinct purposes targeting specific data types like account info, positions, orders, or market data, with clear boundaries. However, some overlap exists, such as get_closed_pnl and get_trade_history both relating to historical performance, which could cause minor confusion for agents.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'get_' prefix, ensuring predictability and readability. This uniformity helps agents easily understand and navigate the tool set without naming conflicts.
Tool Count4/5
With 22 tools, the count is slightly high but reasonable for a comprehensive cryptocurrency trading server covering account, market, and order data. It provides extensive coverage without being overly bloated, though some tools might be consolidated for efficiency.
Completeness4/5
The tool set offers strong coverage for monitoring and analysis in trading, including account, positions, orders, and market data. Minor gaps exist, such as missing tools for executing trades or managing orders (e.g., create_order, cancel_order), which could limit full trading workflows.
Average 3.1/5 across 22 of 22 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to describe any traits such as read-only status, potential side effects, authentication needs, rate limits, or return format. The description is too vague to inform the agent about how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence, but it is under-specified rather than efficiently informative. It lacks front-loaded detail that could clarify the tool's scope or usage, making it minimally structured but not effectively so.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data tools and the lack of annotations and output schema, the description is incomplete. It does not explain what 'insurance fund data' entails, how results are returned, or any behavioral aspects, leaving significant gaps for the agent to understand the tool's full context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'coin' well-documented in the schema. The description does not add any meaning beyond the schema, such as explaining why the coin parameter is optional or its impact on the query. Given the high schema coverage, a baseline score of 3 is appropriate as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get insurance fund data' restates the tool name 'get_insurance' with minimal elaboration, making it tautological. It specifies the resource ('insurance fund data') but lacks a clear verb beyond 'get' and does not differentiate from siblings like 'get_wallet_balance' or 'get_account_info' in terms of what specific data is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent without direction on its appropriate application among the many sibling tools for financial data retrieval.
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 offers minimal insight. It implies a read operation but does not cover aspects like rate limits, authentication needs, data freshness, or error handling. This is inadequate for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase, 'Get long/short ratio data,' which is front-loaded and wastes no words. It efficiently conveys the core function without unnecessary elaboration, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, and no annotations), the description is insufficient. It fails to explain return values, usage context, or behavioral traits, leaving significant gaps for an agent to understand and invoke the tool effectively in a financial data context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed documentation for all parameters, including enums and defaults. The description adds no additional meaning beyond the schema, but the high coverage justifies a baseline score of 3, as the schema adequately compensates for the lack of param details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get long/short ratio data' restates the tool name with minimal elaboration, making it tautological. It specifies the type of data but lacks a clear verb-resource pairing or differentiation from sibling tools like get_open_interest or get_position_info, which might relate to similar financial metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or comparisons to sibling tools, leaving the agent with no usage instructions beyond the basic function implied by the name.
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 for behavioral disclosure. 'Get open interest data' implies a read-only operation but doesn't specify authentication requirements, rate limits, pagination behavior (though cursor parameter hints at it), error conditions, or what format the data returns. For a financial data tool with 7 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at just three words with zero wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration. For its limited content, the structure is perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, financial data tool), lack of annotations, and absence of an output schema, the description is insufficiently complete. It doesn't explain what open interest data represents, what format it returns, or how to interpret results. The agent would need to infer much from parameter names alone, which is inadequate for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the input schema, which has 100% description coverage with clear parameter documentation including enums, defaults, and constraints. The baseline score of 3 reflects that the schema does all the work - the description doesn't compensate but doesn't need to given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get open interest data' is a tautology that essentially restates the tool name 'get_open_interest'. It specifies the resource ('open interest data') but lacks a clear verb beyond 'get' and doesn't distinguish this tool from its many siblings that also retrieve various types of financial data. The purpose is identifiable but overly generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 21 sibling tools on the server (including get_kline, get_tickers, get_position_info, etc.), there's no indication of what makes open interest data distinct or when an agent should prefer this tool over others for related financial metrics. No context, 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('get') without any details on permissions required, rate limits, response format, or whether it's a read-only operation. For a tool with no annotation coverage, this minimal description fails to provide necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Get risk limit information', which is front-loaded and wastes no words. However, this conciseness comes at the cost of completeness, but for this dimension alone, it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'risk limit information' entails (e.g., numerical limits, thresholds), how results are returned, or tie parameters to the output. With no output schema and minimal description, it leaves significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., 'category' as product type with enum values, 'symbol' as symbol name). The description adds no additional meaning beyond the schema, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get risk limit information' is a tautology that essentially restates the tool name 'get_risk_limit'. It specifies the verb 'get' and resource 'risk limit information', but lacks specificity about what risk limits are (e.g., trading limits, margin requirements) and doesn't distinguish from sibling tools like get_position_info or get_account_info that might provide related risk data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., for trading decisions, risk assessment), or how it differs from sibling tools like get_position_info or get_account_info that might include risk-related data. This leaves the agent with no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers no information beyond the basic action. It does not mention whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or the format of returned data. For a tool with 5 parameters and no output schema, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, front-loaded sentence that directly states the tool's purpose. There is no wasted verbiage or unnecessary elaboration, making it efficient and easy to parse, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It does not address behavioral aspects like data retrieval limits, error handling, or output format, nor does it provide usage context. For a historical data query tool, this leaves critical gaps in understanding how to effectively invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional meaning beyond what the schema provides (e.g., it does not explain relationships between parameters like 'startTime' and 'endTime' or clarify the 'category' enum). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description fails to compensate with any extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get funding rate history' is a tautology that restates the tool name with minimal elaboration. While it indicates the action ('Get') and resource ('funding rate history'), it lacks specificity about scope or differentiation from sibling tools like 'get_kline' or 'get_mark_price_kline' that might also retrieve historical data. This makes it vague and minimally informative beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions, and it fails to differentiate from sibling tools that might serve similar purposes (e.g., other historical data tools). This leaves the agent without clear direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation ('Get'), but doesn't disclose behavioral traits like whether it requires authentication, rate limits, pagination behavior (beyond the cursor parameter), error conditions, or response format. This is inadequate for a tool with 5 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a tool name that already hints at the function, though this conciseness comes at the cost of detail needed for other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema, many similar siblings), the description is incomplete. It doesn't explain what 'trading instruments information' includes, how results are structured, or when to use it over other tools. This leaves significant gaps for an agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters with descriptions, enums, and constraints. The description adds no meaning beyond the schema, not even clarifying relationships between parameters (e.g., if symbol and baseCoin are mutually exclusive). Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get trading instruments information' states a clear verb ('Get') and resource ('trading instruments information'), but it's vague about what specific information is retrieved. It doesn't distinguish this tool from siblings like 'get_tickers' or 'get_order_book' that also provide trading-related information, leaving ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to trading data (e.g., get_tickers, get_order_book, get_position_info), the description offers no context about use cases, prerequisites, or exclusions, leaving the agent to guess based on parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description explains what index price is and its purpose, but doesn't disclose key behavioral traits: whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what the output format looks like (e.g., array of candlesticks with OHLCV data). For a data retrieval tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence directly states the tool's purpose, and the second provides helpful context about index price. There's no wasted text, and the information is front-loaded. It could potentially be more structured with explicit usage guidance, but it's efficient as is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, financial data tool) and lack of both annotations and output schema, the description is incomplete. It explains what index price is but doesn't cover behavioral aspects like authentication needs, rate limits, error handling, or output format. For a tool that retrieves time-series financial data with multiple parameters, more context about how to interpret and use the results would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly with descriptions, enums, examples, and constraints. The description adds no parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get index price candlestick data for derivatives.' It specifies the resource (index price candlestick data) and domain (derivatives). However, it doesn't explicitly distinguish this from sibling tools like 'get_kline' or 'get_mark_price_kline', which likely retrieve different types of price data. The explanation of index price as 'fair value price based on major spot exchanges' is helpful but doesn't fully differentiate the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that index price is 'used as reference for mark price calculation,' which hints at a use case, but doesn't explicitly contrast with sibling tools like 'get_kline' (likely for spot prices) or 'get_mark_price_kline' (for mark prices). There are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage from 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 full burden. It states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, or what 'depth' entails (e.g., bid/ask levels). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'order book depth' returns (e.g., bid/ask arrays, timestamps) or behavioral aspects like pagination or error handling, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond implying 'symbol' is for trading, which is already clear from the schema. Baseline 3 is appropriate as the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get order book depth') and resource ('for a trading symbol'), making the purpose immediately understandable. However, it doesn't differentiate from siblings like 'get_recent_trades' or 'get_tickers' that also provide market data, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_recent_trades' and 'get_tickers' that offer different market data, the description lacks context for choosing this specific tool, leaving the agent to infer usage.
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. While it mentions the tool provides 'comprehensive order history' and is 'useful for trade analysis,' it lacks critical details such as whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (implied by 'cursor' parameter but not explained), or what happens with large datasets. For a tool with 11 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that efficiently state the tool's purpose and utility. There's no wasted language, and it avoids redundancy. However, it could be slightly more structured by explicitly separating purpose from usage context, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like safety, performance, or output format, which are crucial for a tool of this scope. Without annotations or an output schema, the description should provide more context on what to expect from the tool's operation and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no specific parameter semantics beyond the general scope of 'order history,' so it doesn't enhance understanding of individual parameters. This meets the baseline score of 3, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comprehensive order history with detailed information about past orders including execution details, timestamps, and status changes.' It specifies the verb ('Get') and resource ('order history') with some detail about what information is included. However, it doesn't explicitly differentiate this from sibling tools like 'get_open_closed_orders' or 'get_trade_history', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance with 'Useful for trade analysis and record keeping,' which gives some context but doesn't specify when to use this tool versus alternatives like 'get_open_closed_orders' or 'get_trade_history.' There's no explicit mention of when not to use it or clear alternatives, leaving significant gaps in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'recent trades' but doesn't specify time frames, pagination, rate limits, authentication needs, or what 'recent' means. This leaves significant behavioral gaps for a tool with 5 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits like time ranges for 'recent'. For a tool with 5 parameters and complex options, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no extra meaning beyond implying 'symbol' is required, which is already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('recent trades for a symbol'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_trade_history' or 'get_order_history', which might have overlapping functionality, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_trade_history' and 'get_order_history' available, the description offers no context on differences, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implying read-only behavior) but doesn't specify authentication requirements, rate limits, error conditions, or whether it returns real-time or cached data. For a financial tool with potential high-stakes use, this lack of detail is a significant gap, though it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds context in the second. Both sentences earn their place by clarifying the tool's function and use case without redundancy. It's appropriately sized for a tool with 6 parameters, though it could be slightly more concise by integrating the two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 6 parameters, no annotations, and no output schema, the description is moderately complete. It covers the purpose and high-level use but lacks details on behavioral traits, return format, or error handling. For a tool in a trading environment with siblings like get_closed_pnl, more guidance on differentiation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear documentation for all 6 parameters, including enums and examples. The description adds no parameter-specific semantics beyond implying filtering by category and symbol, which is already covered in the schema. This meets the baseline score of 3 for high schema coverage without additional value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get detailed position information') and resources ('trading positions'), listing key data points like size, value, PnL, and margin. It distinguishes itself from siblings like get_account_info or get_wallet_balance by focusing on active trading positions rather than account balances or historical data. However, it doesn't explicitly differentiate from get_closed_pnl, which might overlap in PnL reporting.
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 'portfolio monitoring and risk management,' suggesting when to use this tool in a trading context. It doesn't provide explicit alternatives or exclusions, such as when to use get_closed_pnl for historical PnL versus this tool for current positions. The guidance is contextual but lacks specificity on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is for 'real-time' data and mentions what information is included, but doesn't address important behavioral aspects like rate limits, authentication requirements, data freshness guarantees, error conditions, or response format. For a financial data tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that each serve a clear purpose: the first states what the tool does, the second provides usage guidance. There's no wasted language, though it could be slightly more specific about differentiation from sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial data tool with 4 parameters), no annotations, and no output schema, the description is moderately complete. It covers the basic purpose and provides some usage context, but lacks important behavioral information that would be crucial for an AI agent to use this tool effectively in production. The absence of output schema means the description should ideally mention what the return structure looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'trading symbols' which relates to the 'symbol' parameter, but provides no additional syntax, format, or usage guidance for parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get real-time ticker information including current prices, 24h volume, and price changes for trading symbols.' It specifies the verb ('Get') and resource ('ticker information') with concrete data fields. However, it doesn't explicitly differentiate from siblings like 'get_instruments_info' or 'get_recent_trades' which might provide overlapping market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Use this to get current market data for any cryptocurrency pair.' This implies when to use it (for real-time ticker data) but doesn't explicitly state when NOT to use it or mention alternatives among the many sibling tools. The guidance is helpful but incomplete for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves 'historical' data, implying it's a read-only operation, but doesn't specify authentication requirements, rate limits, error conditions, or the format/structure of returned data. For a tool with 6 parameters and no output schema, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the core purpose, and the second provides usage context. It's appropriately sized and front-loaded, with every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is minimally adequate. It clarifies the tool's purpose and usage context but lacks details on behavioral traits, output format, and differentiation from siblings. With no output schema, the description should ideally hint at return values, but it doesn't, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no specific parameter information beyond what's in the schema (e.g., it doesn't explain 'category' options or 'cursor' usage). However, it implicitly reinforces that parameters filter 'closed positions' data, which aligns with the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get historical profit and loss data for closed positions.' It specifies both the verb ('Get') and resource ('historical profit and loss data for closed positions'), making it unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_trade_history' or 'get_order_history' which might also involve historical 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 provides implied usage guidance by stating it's 'Useful for performance analysis and tax reporting,' which suggests appropriate contexts. However, it doesn't explicitly say when to use this tool versus alternatives (e.g., vs. 'get_trade_history' or 'get_order_history'), nor does it mention any prerequisites or exclusions. The guidance is helpful but incomplete.
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. While it mentions the tool's purpose and usage, it fails to disclose critical behavioral traits such as authentication requirements, rate limits, whether it's a read-only operation, what 'recently closed' means, or how results are structured. For a tool with 8 parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded with the core purpose. Every sentence earns its place by explaining what the tool does and when to use it, though the third sentence slightly repeats the first. There is minimal waste, but it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no annotations, no output schema), the description is incomplete. It lacks information on authentication, rate limits, pagination behavior, error handling, and the structure of returned data. For a tool with this many parameters and no output schema, the description should provide more context to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters or providing usage examples. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('both open (pending) and recently closed orders'), and distinguishes it from siblings by specifying its unique scope of monitoring order status and trading activity. It explicitly mentions checking if orders are filled, cancelled, or still pending, which sets it apart from tools like get_order_history or get_closed_pnl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Essential for monitoring order status and trading activity'), but does not explicitly state when not to use it or name alternatives. It implies usage for checking order statuses, but lacks explicit exclusions or comparisons to sibling tools like get_order_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. While it explains what premium index data represents (funding rate basis), it doesn't describe important behavioral aspects like whether this is a read-only operation, rate limits, authentication requirements, response format, or pagination behavior. For a data retrieval tool with 6 parameters, this leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states exactly what the tool does and for what instruments. The second sentence provides crucial context about what premium index data represents and its purpose. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, financial data tool) and absence of both annotations and output schema, the description is somewhat incomplete. While it explains what premium index data is and its purpose, it doesn't address behavioral aspects, response format, or error conditions. For a tool that retrieves time-series financial data with multiple filtering parameters, more context about what to expect would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly with descriptions, examples, enums, and constraints. The description adds minimal value beyond what's in the schema - it only reinforces that this is for 'linear perpetuals' (implied by the category parameter). No additional parameter semantics or usage context beyond the schema are provided.
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 specific action ('Get premium index price candlestick data'), resource ('for linear perpetuals'), and purpose ('shows the funding rate basis and is used to calculate funding payments'). It distinguishes from sibling tools like 'get_index_price_kline' and 'get_mark_price_kline' by specifying it's for premium index data related to funding calculations.
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 context by mentioning it's for linear perpetuals and funding calculations, but doesn't explicitly state when to use this tool versus alternatives like 'get_funding_rate_history' or 'get_index_price_kline'. No explicit exclusions or prerequisites are provided, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what data is returned but does not mention critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or pagination behavior (implied by the cursor parameter but not explained). The description adds some context about data utility but misses key operational details.
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 and highly concise, consisting of only two sentences that efficiently convey the tool's purpose and primary use cases without unnecessary elaboration. Every sentence earns its place by providing essential information, making it easy for an agent to quickly understand the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 10 parameters and no output schema, the description is moderately complete but has gaps. It explains the tool's purpose and data focus well, but without annotations or output schema, it lacks details on behavioral aspects like safety, performance, and return format. The description is adequate for basic understanding but insufficient for full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing detailed documentation for all 10 parameters. The description does not add any parameter-specific semantics beyond what the schema already explains, such as clarifying parameter interactions or usage nuances. Baseline score of 3 is appropriate since the schema does the heavy lifting, but the description offers no additional parameter insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get detailed execution history') and resources ('actual trades (fills)'), distinguishing it from siblings like get_order_history or get_closed_pnl by focusing on execution-level data. It explicitly mentions key data elements like execution prices, quantities, fees, and timestamps, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Essential for performance analysis and tax reporting') but does not explicitly state when to use this tool versus alternatives like get_order_history or get_closed_pnl. It provides a general purpose but lacks specific guidance on tool selection among siblings, leaving the agent to infer based on the described data focus.
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 provided, the description carries the full burden of behavioral disclosure. It effectively describes the return format (OHLCV data) and default time behavior, but doesn't mention rate limits, authentication requirements, data freshness, or potential errors. For a data retrieval tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose and return format, while the second explains the default time behavior. There's zero wasted language and it's front-loaded with the most important information.
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?
For a 6-parameter tool with no annotations and no output schema, the description provides adequate basic information about what the tool does and returns. However, it lacks details about authentication needs, rate limits, error conditions, and pagination behavior that would be helpful for a financial data retrieval tool. The schema handles parameter documentation well, but the description doesn't fully compensate for the missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions time range defaults but doesn't provide additional parameter semantics. This meets the baseline for high schema 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 specific action ('Get historical candlestick/OHLC data') and resource ('for technical analysis'), distinguishing it from sibling tools like get_tickers (current prices) or get_recent_trades (raw trades). It explicitly mentions the return data structure (open, high, low, close prices and volume), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context by mentioning 'technical analysis' and the default behavior when no time range is specified. However, it doesn't explicitly state when to use this tool versus alternatives like get_mark_price_kline or get_index_price_kline, nor does it mention any prerequisites or exclusions for usage.
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. While it mentions the tool provides 'additional details like transferable amounts and account relationships', it doesn't disclose important behavioral aspects such as whether this is a read-only operation, authentication requirements, rate limits, error conditions, or what format the balance information returns. The description adds some value but leaves significant gaps for a tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with just two sentences that each earn their place. The first sentence states the core purpose and key differentiators, while the second sentence provides important comparative context. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description provides adequate but incomplete context. It explains the tool's purpose and differentiators well, but doesn't address behavioral aspects, return format, or error handling. For a balance query tool with multiple optional parameters affecting institutional accounts and bonus calculations, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly with descriptions, enums, examples, and required status. The description doesn't add any parameter-specific information beyond what's in the schema, but with complete schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get balance information') and resources ('specific coin'), and explicitly differentiates it from sibling tools by mentioning it's 'More detailed than wallet balance for single coin queries' and listing additional details like 'transferable amounts and account relationships'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('for single coin queries' and 'more detailed than wallet balance'), but doesn't explicitly state when NOT to use it or name specific alternatives beyond the general comparison to 'wallet balance'. It implies usage scenarios without providing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the purpose of mark price (liquidation and PnL calculations) and contract availability, but it does not cover other behavioral traits such as rate limits, authentication needs, error conditions, or the format of returned data. This leaves gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences that immediately convey the tool's purpose and key constraints. Every sentence earns its place by providing essential information without redundancy or unnecessary details, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It explains the tool's purpose and contract limitations well, but without annotations or an output schema, it lacks details on behavioral aspects like data format, error handling, or usage limits. This makes it adequate but not fully comprehensive for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing detailed documentation for all 6 parameters (e.g., category, symbol, interval). The description does not add any parameter-specific semantics beyond what the schema already explains, so it meets the baseline of 3 without compensating further. No parameters are explicitly mentioned in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get mark price candlestick data') and resource ('for derivatives trading'), distinguishing it from siblings like 'get_kline' (likely regular price data) and 'get_index_price_kline' by specifying 'mark price' used for liquidation and PnL calculations. It explicitly mentions the contract types it supports ('linear and inverse perpetual contracts only'), making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by explaining that mark price is for liquidation and PnL calculations, and it specifies the available contract types ('linear and inverse perpetual contracts only'). However, it does not explicitly state when not to use it or name alternatives (e.g., 'get_kline' for regular price data or 'get_index_price_kline'), which prevents a perfect score.
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 full burden. It states the tool's function but lacks details on behavioral traits such as rate limits, authentication requirements, response format, or error handling. However, for a simple, parameterless tool, the description is minimally adequate, though it could benefit from additional 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized for a simple tool, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. However, it lacks details on output format or behavioral context, which could be helpful for an AI agent. It meets the minimum viable standard but has clear gaps in providing full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add parameter details beyond the schema, but this is appropriate given the lack of parameters, warranting a baseline score of 4 as per the rules.
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 specific action ('Get') and resource ('current Bybit server time'), making the purpose immediately understandable. It distinguishes itself from sibling tools like get_account_info or get_tickers by focusing exclusively on server time rather than account data, market data, or other metrics.
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 retrieving server time, but does not explicitly state when to use this tool versus alternatives (e.g., for timestamp synchronization vs. using local time). No guidance is provided on prerequisites, exclusions, or specific contexts where this tool is preferred over others in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively indicates this is a read operation ('Get') and describes the scope of returned data, but doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, or whether the data is real-time vs cached. The description adds value by specifying what balance components are included, but leaves gaps in operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence clearly states the tool's purpose and scope, while the second provides valuable context about its importance. There's zero wasted language or redundancy, and the information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 2 parameters and no output schema, the description provides adequate purpose and context but lacks completeness. Without annotations covering behavioral aspects and no output schema to describe return values, the description should ideally address more operational details like response format, authentication needs, or data freshness. The current description is functional but leaves the agent to infer important implementation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters with descriptions, enums, examples, and requirements. The description doesn't add any parameter-specific information beyond what's in the schema, nor does it explain parameter interactions or provide usage examples. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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 specific action ('Get detailed wallet balance information') and resource ('wallet'), with explicit details about what information is included ('available balance, locked balance, and total equity across different account types'). It distinguishes from siblings like 'get_single_coin_balance' by emphasizing comprehensive balance data across account types rather than single-coin focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Essential for portfolio monitoring and risk management'), which helps identify appropriate scenarios. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_single_coin_balance' or 'get_account_info', nor does it mention any exclusions or prerequisites for usage.
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 full burden. It implies this is a read-only operation ('Get'), which is consistent with the tool name, but does not disclose behavioral traits like authentication requirements, rate limits, or response format. The description adds some context about the tool's purpose in risk monitoring, but lacks details on how it behaves beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a brief usage note. Every sentence earns its place by providing essential information without redundancy. It is appropriately sized for a tool with no parameters and clear functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input parameters and no output schema, the description provides a clear purpose and usage context. However, it lacks details on what the output includes beyond high-level categories, and with no annotations, it does not cover behavioral aspects like error handling or data freshness. This is adequate but has gaps in completeness for a tool that returns account health metrics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add parameter details, which is appropriate. A baseline score of 4 is given because the tool has no parameters, and the description adequately explains what the tool does without unnecessary parameter elaboration.
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 ('comprehensive account information'), with specific details about what information is included (margin ratios, account status, upgrade status, overall account health metrics). It distinguishes this tool from siblings by focusing on account-level data rather than market data, positions, orders, or balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Essential for risk monitoring'), which implicitly suggests it's for assessing account health rather than trading or market analysis. However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as get_position_info or get_wallet_balance for more specific data.
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-py-mcp MCP server](https://glama.ai/mcp/servers/BCusack/bybit-py-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BCusack/bybit-py-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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