MCP Bitget Trading Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose with clear boundaries: order management (cancelOrder, placeOrder, getOrders), account data (getBalance, getMarginInfo, getPositions), market data (getCandles, getOrderBook, getPrice, getTicker), and WebSocket operations (connectWebSocket, disconnectWebSocket, subscribeToOrderBook, subscribeToTicker, unsubscribeFromChannel, getWebSocketStatus). There is no overlap or ambiguity between tools.
Naming Consistency5/5
All tool names follow a consistent camelCase verbNoun pattern (e.g., cancelOrder, getBalance, subscribeToOrderBook). The naming is uniform across the entire set, making it predictable and easy to understand.
Tool Count5/5
With 17 tools, the count is well-suited for a trading server covering order execution, account management, market data, and real-time WebSocket functionality. Each tool serves a specific and necessary role without redundancy, fitting within the typical 3-15 range for such a domain.
Completeness5/5
The tool set provides comprehensive coverage for cryptocurrency trading: full CRUD for orders (place, cancel, get), account data (balance, margin, positions), market data (historical and real-time via WebSocket), and futures-specific operations (leverage setting). There are no obvious gaps, enabling agents to handle complete trading workflows.
Average 3/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get margin account information' implies a read-only operation, but it doesn't specify what information is returned, whether authentication is required, rate limits, error conditions, or data freshness. The description provides minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words: 'Get margin account information'. It's front-loaded with the core purpose and contains no unnecessary words or sentences. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial tool that presumably returns margin account data (which could include leverage, equity, margin requirements, etc.), the description is insufficient. With no annotations, no output schema, and minimal behavioral context, users cannot understand what information will be returned or how to interpret it. The description doesn't compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'symbol' documented as 'Filter by symbol'. The description doesn't add any parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get margin account information', which is a clear verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'getBalance' or 'getPositions' that might also provide account-related information. The purpose is understandable but lacks differentiation from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from sibling tools like 'getBalance' or 'getPositions'. Users must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing critical behavioral traits. It doesn't mention if cancellation is reversible, requires specific permissions, has rate limits, affects account balance, or returns confirmation details, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, making it easy to parse and front-loaded with the core purpose. It's appropriately sized for a simple tool, though this conciseness comes at the cost of completeness 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like side effects, error conditions, or return values, which are crucial for safe and effective use in a trading context with sibling tools like 'placeOrder' and 'getOrders'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('orderId' and 'symbol') adequately. The description adds no additional meaning beyond what the schema provides, such as explaining why both parameters are required or their interaction, but this is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel') and target resource ('an existing order'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'placeOrder' or 'getOrders' beyond the obvious verb difference, missing explicit distinction in scope or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or under what conditions it's appropriate. For example, it doesn't specify prerequisites like order status or timing constraints, nor does it mention sibling tools like 'getOrders' for verification before cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get account balance information' implies a read-only operation, but it doesn't specify if this requires authentication, rate limits, real-time vs. cached data, or error conditions. This is a significant gap for a financial tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly. Every word earns its place without redundancy.
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 tools and lack of annotations or output schema, the description is incomplete. It doesn't explain what balance information is returned (e.g., total, available, locked), how it's formatted, or any prerequisites. For a tool with no structured safety or output details, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'asset' documented as 'Specific asset to query'. The description doesn't add any meaning beyond this, such as examples of valid assets or default behavior if omitted. Since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get account balance information' clearly states the verb ('Get') and resource ('account balance information'), making the tool's purpose understandable. However, it doesn't differentiate from potential siblings like 'getMarginInfo' or 'getPositions', which might also provide financial account data, so it doesn't fully distinguish scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getMarginInfo' and 'getPositions' that might overlap in financial context, there's no indication of when this tool is appropriate or what specific balance information it retrieves compared to others.
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 implies a read-only operation ('Get') but doesn't specify whether this requires authentication, has rate limits, returns paginated data, or includes error handling. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly, and every part of the sentence contributes essential information.
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 (fetching historical financial data with three parameters) and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what the output looks like (e.g., array of candles with OHLCV fields), potential errors, or behavioral traits like data freshness or availability, leaving the agent with incomplete context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all parameters (symbol, interval, limit) with descriptions and an enum for interval. The description adds no additional parameter semantics beyond what the schema provides, such as explaining symbol formats or limit constraints, but this is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('historical candlestick/OHLCV data'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'getTicker' or 'getPrice' beyond specifying the type of financial data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getTicker' (current price) or 'getOrderBook' (market depth). It doesn't mention prerequisites, such as needing a valid trading symbol, or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' data, implying a read operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns historical vs real-time data, or what the output format looks like. For a financial data tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple data retrieval tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a trading tool. It doesn't cover authentication needs, rate limits, return format, or how it integrates with sibling tools like subscribeToOrderBook. For a tool in a financial context with multiple related siblings, more contextual information is needed.
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 both parameters (symbol and depth with default). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain symbol format conventions, depth limitations, or data structure implications. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('order book (market depth)') with the specific target ('for a trading pair'). It distinguishes from siblings like getPrice or getTicker by specifying market depth data, but doesn't explicitly differentiate from subscribeToOrderBook which provides real-time updates versus this one-time retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention when this static order book retrieval is preferred over subscribeToOrderBook for real-time updates, or how it differs from getTicker for price summaries. The description offers no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get current open orders' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns real-time or cached data, or provides pagination. For a financial/trading tool with no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the essential information with zero wasted words. Every word earns its place by specifying the action, temporal state, and resource type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trading/financial tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what constitutes an 'order' in this context, what data fields are returned, whether the response includes historical or only current data, or any error conditions. Given the complexity implied by the sibling tools and the lack of structured metadata, more context is needed.
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 both parameters are already documented in the schema. The description doesn't add any additional meaning about the parameters beyond what's in the schema. It doesn't explain the relationship between 'current open orders' and the optional status filter that includes non-open statuses, which creates a potential semantic inconsistency.
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 ('current open orders'), making the purpose immediately understandable. It distinguishes from siblings like getBalance or getPositions by focusing specifically on orders. However, it doesn't explicitly differentiate from getOrderBook which also deals with orders but in a different context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like getOrderBook or getPositions. It doesn't mention prerequisites, timing considerations, or any context that would help an agent decide between this and other order-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get current futures positions' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns real-time or cached data, or what happens on errors. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get current futures positions') that is front-loaded and wastes no words. It directly conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'current futures positions' entails (e.g., open positions, margin details, or historical data), the return format, or error handling. Given the complexity of trading data and lack of structured support, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'symbol' parameter documented as 'Filter by symbol'. The description doesn't add any parameter details beyond this, such as format examples or filtering behavior. Given the high schema coverage, the 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current futures positions' clearly states the verb ('Get') and resource ('current futures positions'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getOrders' or 'getBalance', which could also relate to trading positions, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or comparisons to siblings like 'getOrders' (which might show open orders) or 'getBalance' (which might show account balances), leaving the agent without contextual usage instructions.
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 automatic detection of spot vs futures, which is useful context, but fails to describe critical traits: whether this is a read/write operation (implied write but not stated), potential side effects (e.g., fund deduction, position changes), error conditions, or rate limits. For a financial transaction tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Place a new buy or sell order') and adds a key feature ('automatically detects spot vs futures'). There's no wasted verbiage, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial order placement tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., idempotency, error handling), usage context, and return values, leaving critical gaps for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It implies the tool handles both spot and futures orders, but doesn't explain how parameters like 'reduceOnly' or 'marginMode' apply differently. With high schema coverage, the baseline is 3, as the description doesn't compensate with additional semantic context.
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: 'Place a new buy or sell order' with the added detail of 'automatically detects spot vs futures'. This specifies the verb ('place'), resource ('order'), and a key capability (automatic detection). However, it doesn't explicitly differentiate from sibling tools like 'cancelOrder' or 'getOrders', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication, account funding), when to choose spot vs futures, or compare to other order-related tools like 'cancelOrder'. This leaves the agent without context for appropriate 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. 'Set leverage for futures trading' implies a mutation operation that could affect risk and margin requirements, but it doesn't disclose critical behaviors: whether changes apply immediately or at next trade, if there are rate limits, permission requirements, or confirmation of success. This leaves significant gaps for safe agent 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 a single, efficient sentence that states the core function without unnecessary words. It's front-loaded with the essential action and resource, making it easy to parse. Every word earns its place, with no redundant information or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial trading mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on success/failure responses, error conditions, side effects (e.g., margin calls), and operational constraints. For a tool that modifies risk parameters, this leaves the agent under-informed about critical execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (symbol and leverage) well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema—it doesn't explain format examples for 'symbol' or implications of leverage values. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('leverage for futures trading'), making the purpose immediately understandable. It distinguishes from siblings like placeOrder or getMarginInfo by focusing on leverage configuration rather than order execution or information retrieval. However, it doesn't specify if this applies to existing positions or new ones, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open futures position or account permissions), timing considerations, or relationships to other tools like getMarginInfo for checking current leverage. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose that this likely creates a persistent subscription, requires WebSocket connectivity, may have rate limits, or how updates are delivered. The description is minimal and lacks 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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a subscription tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a subscription tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after subscription (how updates are delivered), whether this requires WebSocket connection first, or what the subscription entails. Given the complexity of real-time data streaming, more context is needed.
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 both parameters. The description adds no additional parameter information beyond what's already in the schema. This meets the baseline expectation when schema coverage is complete.
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 ('Subscribe to') and resource ('real-time order book updates'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'subscribeToTicker' or explain what distinguishes order book updates from ticker updates.
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 about when to use this tool versus alternatives like 'getOrderBook' (for one-time retrieval) or 'subscribeToTicker' (for different data type). There's no mention of prerequisites, such as needing an active WebSocket connection via 'connectWebSocket' first.
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 real-time streaming operation but doesn't cover critical aspects like whether this requires authentication, how updates are delivered (e.g., via WebSocket events), potential rate limits, or how to stop subscriptions (e.g., using 'unsubscribeFromChannel'). This leaves significant gaps for agent decision-making.
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 function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a real-time subscription tool with no annotations or output schema, the description is insufficiently complete. It lacks details on behavioral traits (e.g., streaming mechanics, error handling), integration with sibling tools (e.g., WebSocket management), and expected outputs (e.g., how updates are received). This leaves the agent with inadequate context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('symbol' and 'instType') with details like enum values and defaults. The description adds no additional parameter semantics beyond what the schema provides, such as format examples for 'symbol' or implications of 'instType' choices. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe') and resource ('real-time ticker updates'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getTicker' (which likely retrieves static data) or 'subscribeToOrderBook' (which handles a different data stream), missing an opportunity for clearer distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active WebSocket connection via 'connectWebSocket'), exclusions, or comparisons to siblings like 'getTicker' (for one-time data) or 'unsubscribeFromChannel' (for stopping subscriptions), leaving usage context 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 full burden but only states the basic action. It doesn't disclose behavioral traits like whether this affects real-time data flow, requires specific permissions, has rate limits, or what happens on success/failure. For a WebSocket operation with mutation implications, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's appropriately sized for a straightforward tool and front-loads the core action 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?
For a WebSocket mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'unsubscribing' entails behaviorally, what happens to data streams, or what the user should expect after invocation. Given the complexity and lack of structured context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying 'channel' and 'symbol' are required (which the schema already states). Baseline 3 is appropriate when 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 ('Unsubscribe from') and resource ('a WebSocket channel'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'disconnectWebSocket' or specify what types of channels exist beyond what's implied in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'disconnectWebSocket' or when not to use it. There's no mention of prerequisites (e.g., must be subscribed first) or context for usage relative to sibling subscription 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool connects for real-time data but does not explain critical traits such as authentication requirements, connection persistence, error handling, or rate limits. This is inadequate for a tool that likely involves network operations and state management.
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 unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of WebSocket connections (stateful, real-time) and the lack of annotations and output schema, the description is insufficient. It does not cover behavioral aspects like how to handle disconnections, what data formats to expect, or integration with sibling tools, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could have mentioned implicit parameters (e.g., connection settings) if relevant. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Connect to WebSocket') and the purpose ('for real-time data'), which distinguishes it from siblings like getWebSocketStatus or disconnectWebSocket. However, it lacks specificity about the type of real-time data (e.g., order book, ticker) that siblings like subscribeToOrderBook or subscribeToTicker handle, making it slightly less precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing to connect before subscribing), exclusions, or how it relates to siblings like subscribeToOrderBook or getWebSocketStatus, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose effects like whether disconnection is immediate, if it affects other operations, error handling, or authentication needs, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly efficient and front-loaded. Every word contributes to stating the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (disconnecting implies change) with no annotations and no output schema, the description is incomplete. It lacks details on behavior, effects, or return values, failing to compensate for the missing structured information.
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 coverage, so no parameter documentation is needed. The description appropriately doesn't add parameter details, aligning with the baseline for zero-parameter tools.
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 ('Disconnect') and target resource ('from WebSocket'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getWebSocketStatus' or 'connectWebSocket' beyond the obvious verb difference, missing explicit scope or relationship context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or prerequisites. It doesn't mention if it should be used after 'connectWebSocket', in error scenarios, or as part of cleanup, leaving usage context entirely implicit.
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 'Get[s] full ticker information' but does not clarify what 'full' entails (e.g., includes volume, bid/ask prices), whether it's a read-only operation, or any rate limits or authentication needs. This leaves significant behavioral gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on output format, error handling, or behavioral traits. Without annotations or output schema, more context would improve completeness, but it's not entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'symbol' documented as 'Trading pair symbol'. The description adds no additional semantic context beyond this, such as format examples (e.g., 'BTC/USD') or validation rules. Thus, it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('full ticker information for a trading pair'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'getPrice' or 'subscribeToTicker', which limits its score to 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getPrice' (which might return simpler price data) or 'subscribeToTicker' (for real-time updates). It lacks explicit when/when-not instructions or named alternatives, resulting in minimal usage 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?
With no annotations, the description carries full burden but only states the basic action. It lacks behavioral details such as whether this is a read-only operation, what data is returned (e.g., boolean status, detailed metrics), error conditions, or performance implications. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. Every word earns its place by directly conveying the tool's purpose without redundancy or 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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'status' entails (e.g., connection state, error messages, timestamps), return format, or how it integrates with sibling tools like 'connectWebSocket'. For a tool in a WebSocket context with behavioral unknowns, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it also doesn't compensate for any gaps since there are none. A baseline of 4 is applied as it meets the requirement for a zero-parameter tool.
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 ('WebSocket connection status'), making the purpose immediately understandable. However, it doesn't differentiate from siblings like 'connectWebSocket' or 'disconnectWebSocket' by specifying what aspects of status are returned (e.g., connection state, latency, session details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires an established WebSocket connection), exclusions, or relationships to siblings like 'connectWebSocket' for initiating connections or 'disconnectWebSocket' for terminating them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a real-time or cached price, rate limits, authentication requirements, error conditions, or response format. 'Get current price' suggests a read operation but lacks 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?
Extremely concise single sentence with zero waste. Every word earns its place: 'Get' (action), 'current price' (what), 'for a trading pair' (scope), '(spot or futures)' (clarification). Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial data tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'current price' means (last trade? bid? ask?), latency, data sources, or return format. Given the complexity of trading systems and sibling tools, more context is needed.
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 the single parameter. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples beyond the schema's, no clarification on symbol conventions). Baseline 3 is appropriate when schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current price for a trading pair'), specifying both spot and futures markets. It distinguishes from some siblings like getTicker (which might return more data) and getOrderBook (which shows depth), but doesn't explicitly differentiate from all price-related tools.
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 price retrieval, but provides no explicit guidance on when to use this versus alternatives like getTicker or getCandles. No prerequisites, exclusions, or comparison to siblings are mentioned.
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:

[![MCP-bitget-trading MCP server](https://glama.ai/mcp/servers/gagarinyury/MCP-bitget-trading/badges/card.svg)](https://glama.ai/mcp/servers/gagarinyury/MCP-bitget-trading)

Score Badge

Copy to your README.md:

[![MCP-bitget-trading MCP server](https://glama.ai/mcp/servers/gagarinyury/MCP-bitget-trading/badges/score.svg)](https://glama.ai/mcp/servers/gagarinyury/MCP-bitget-trading)

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/gagarinyury/MCP-bitget-trading'

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