QuantXData MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Multiple tools overlap significantly: get_orderbooks, get_ob_l1_top, and get_ob_l2_snapshot all provide order book data, while get_ohlcv, get_histoday, get_histohour, and get_histominute all return OHLCV data at different intervals. get_trades and get_multi_trades also overlap, making it unclear which tool to select without reading detailed descriptions.
Naming Consistency3/5
All tools use the get_ prefix, which is consistent, but the object naming is inconsistent: get_ohlcv versus get_histoday/hour/minute, get_orderbooks versus get_ob_l1_top, and get_trades versus get_multi_trades. The abbreviations (ob, l1, l2) and inconsistent use of 'multi_' create mixed conventions that are readable but not uniform.
Tool Count4/5
With 12 tools, the count is within the typical well-scoped range for a market data server. However, several tools duplicate functionality (e.g., order book variants, OHLCV variants), which makes the count feel slightly inflated—a leaner set of 8-9 tools would be more appropriate.
Completeness4/5
The surface covers the major data types: instruments, trades, order books, OHLCV, options quotes, and real-time streaming. There are no obvious dead ends for historical or real-time market data, though the duplication of OHLCV and order book tools suggests the API is not optimally organized.
Average 3.4/5 across 12 of 12 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, the description provides minimal behavioral context. It implies a read operation but does not disclose return format, default time ranges, pagination, or any limitations. This is insufficient for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that efficiently conveys the primary function. No unnecessary words or 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?
The description is too sparse for a tool with 6 parameters, no output schema, and similar sibling tools. It lacks usage context, comparison with alternatives, and return value details, making it insufficient for confident selection.
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?
All six parameters have descriptions in the schema, so the baseline is 3. The tool description only reiterates the aggregation intervals and adds no additional parameter context beyond the schema.
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 retrieves aggregated OHLCV candlestick data and lists supported intervals. It identifies a distinct resource (candlesticks) that differs from trades/orderbooks, though it doesn't explicitly contrast with sibling historical-data tools like get_histoday.
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 given on when to use this tool instead of get_histoday, get_histohour, or other historical data tools. The description lacks any contextual or comparative usage information.
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 'historical' and 'snapshots' but fails to describe return format, pagination, ordering, or any side effects. The L1/L2 distinction is vague and does not clarify how it impacts results.
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 sentence that is concise and to the point. It communicates the core purpose without any unnecessary words or 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?
The tool is relatively simple with 4 parameters and no output schema, but the description omits critical details such as the response structure, default limit behavior, and how L1 vs L2 depth is determined. This is inadequate for an AI agent to understand the full behavior without exploring further.
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 schemas for all 4 parameters have descriptions with 100% coverage, so the schema already explains the parameters. The description adds context about the data type (historical snapshots) but does not enhance parameter understanding beyond what is already in the schema.
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 retrieves historical order book snapshots with L1 or L2 depth, but it doesn't explicitly differentiate from sibling tools like get_ob_l1_top or get_ob_l2_snapshot. The verb 'Get' and resource are clear, but the scope could be more distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It merely states it gets historical data, which implies a contrast with real-time tools, but this is not explicit. There is no mention of when to prefer this over get_ob_l1_top or get_ob_l2_snapshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it gets historical trades, but does not mention pagination behavior, response format, or any read-only guarantees. This leaves significant ambiguity for an agent selecting this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is concise and front-loaded. It earns its place by stating the essential purpose, though it is perhaps too terse to compensate for lack of other details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema or annotations, the description is thin. It lacks information about return values, time-range behavior, or how it differs from similar sibling tools, making it incomplete for an agent to fully understand 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 schema description coverage is 100%, so all parameters are already well-described in the schema. The description adds no additional semantic information about parameters, so the baseline score of 3 applies.
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 specifies the action 'Get' and the resource 'historical trade executions' from an exchange, which is clear and non-tautological. However, it does not differentiate from sibling tools like get_multi_trades or get_ohlcv, so the uniqueness is limited.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_multi_trades or stream_realtime. The description simply states what it does without any context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It reveals that the tool is 'polling-based' and returns 'recent data', which are useful but minimal. It fails to disclose what data fields or structure the response contains, whether there are any side effects (like opening a persistent connection), rate limits, or authentication requirements. The agent is left with significant uncertainty about how to handle the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys both the purpose and a key behavioral trait (polling-based, recent data). It contains no filler or redundant information. Every word contributes to the agent's understanding, 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?
The tool has no output schema and no annotations, so the description must compensate by explaining what the stream returns and how it fits with the sibling tools. It does not specify whether the stream returns trades, quotes, order books, or a combination, nor does it clarify the relationship to the get_* snapshot tools. With 11 siblings, the lack of differentiation and response format makes the description incomplete.
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 covers all parameters (exchange, instrument, stream_time) with descriptions, achieving 100% coverage. The description adds no extra semantic detail about these parameters, so the baseline of 3 is appropriate. The schema already provides the necessary meaning for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('real-time market data stream'), and adds the qualifiers 'polling-based' and 'returns recent data'. However, it does not specify what type of data (e.g., trades, order books) the stream contains, which would help distinguish it from the sibling get_* tools. The phrase 'market data stream' is broad but still conveys a distinct purpose compared to snapshot or historical data endpoints.
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 real-time or recent data via 'polling-based' and 'returns recent data', suggesting this tool is for repeated polling rather than historical queries. It does not explicitly mention when to use this instead of sibling tools like get_trades or get_orderbooks, nor does it mention any exclusions or alternatives. The guidance is embedded but not explicit.
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 'snapshot' (which is also in the name) but adds nothing about read-only implications, return shape, rate limits, or other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly conveys the core purpose and the one differentiating feature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema or annotations, but the description is minimally viable for a simple snapshot tool. However, it omits details about the return format and does not differentiate from sibling tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter descriptions, so the baseline is 3. The description's 'configurable depth' maps to the 'limit' parameter but does not add meaningful extra semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get L2 order book snapshot' with a specific verb and resource, and 'L2' distinguishes it from L1 and generic order book tools. The configurable depth aspect further clarifies its 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 like get_ob_l1_top or get_orderbooks. The usage is only implied by the name and the brief 'configurable depth' note, with no explicit exclusions or alternative recommendations.
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 exist, so the description is the only source. It adds minimal context such as 'CryptoCompare-compatible format' but doesn't disclose pagination, default limits, aggregation behavior, or response structure beyond that.
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?
One short sentence that is front-loaded and free of filler.
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 has 6 parameters, no output schema, and no annotations, the description is thin. It lacks information on return format details, default behavior for optional parameters, and how aggregate affects 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?
Schema covers all 6 parameters with descriptions (100% coverage), so the description doesn't need to add parameter details. It doesn't, but the schema suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'hourly OHLCV data', clearly distinguishing from sibling tools like get_histoday and get_histominute by granularity and from trade/orderbook tools by OHLCV.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned. The hourly granularity is implied by the name and description, but there's no guidance on choosing this over get_ohlcv or other granularities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function and does not explain historical data support (via toTs), the effect of the limit parameter, or the output format. This lacks context that would help an agent understand the tool's behavior beyond the definition.
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, concise sentence with no redundant words. It front-loads the core purpose and 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?
For a tool with 5 parameters and no output schema, the description is too minimal. It doesn't mention that it supports historical queries (toTs) or how limit works, nor does it clarify the relationship to sibling tools beyond the name. The lack of annotations and output schema means the description should have provided more context, but it only covers the surface-level function.
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 already provides descriptions for all five parameters, covering 100% of the schema, so the baseline is 3. The description adds no additional meaning about the parameters, such as how fsym/tsym/e interact or the role of optional toTs and limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('L1 order book top-of-book') and clarifies it provides the best bid/ask. This distinguishes it from siblings like get_orderbooks and get_ob_l2_snapshot, which likely provide broader order book 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 no explicit guidance on when to use this tool versus alternatives like get_orderbooks or get_ob_l2_snapshot. The intended use is only implied by the name and the mention of 'top-of-book', but no direct comparison or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'daily OHLCV data' and 'CryptoCompare-compatible format' but does not disclose whether the data is historical, any rate limits, or how the response is structured. This leaves gaps in understanding safety and side effects.
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 concise sentence that effectively communicates the tool's purpose without unnecessary detail. It is well-structured and front-loaded, 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?
With no output schema and no annotations, the description provides only minimal context. It does not clarify the exact output structure or any usage caveats. However, for a simple data retrieval tool with well-documented parameters, it reaches an adequate but not complete level of coverage.
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 coverage is 100%, with all parameters having descriptions. The description does not add any parameter-specific details beyond what the schema already provides, so the baseline score of 3 applies. The 'daily' qualifier helps contextualize but not at the parameter level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'daily OHLCV data', and the mention of 'CryptoCompare-compatible format' adds useful context. It distinguishes itself from sibling tools like get_histohour and get_histominute by specifying daily granularity.
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?
There is no explicit guidance on when to use this tool versus alternatives. The 'daily' qualifier implies it is for daily data, but it doesn't mention when to prefer get_histohour or get_histominute for intraday data, or get_ohlcv for general OHLCV. Usage is only implied.
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 disclosing behavioral traits. It only states what data is returned, but does not mention important aspects such as whether the data is real-time or historical, authentication requirements, rate limits, pagination, or default behaviors for the optional from/to parameters. This is a significant gap for a data-fetching 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, front-loaded sentence that directly states the core function and key outputs. It contains no redundant words, no filler, and is highly scannable for an agent. Every word earns 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 has no output schema, no annotations, and four parameters, the description provides only the minimum information: what it returns. It lacks usage guidance, behavioral details, and return structure. While the parameter schema covers inputs well, the missing behavioral and output context leaves enough gaps to warrant a mid-range score.
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 thoroughly documents all four parameters. The description adds no additional parameter-level detail beyond naming the output fields (Greeks, IV), which aligns with the tool's purpose but does not clarify parameter format, constraints, or relationships. Baseline of 3 is appropriate.
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 ('options market data') with specific included data fields (Greeks and implied volatility). This distinguishes it from sibling tools like get_trades, get_orderbooks, and get_ohlcv, which cover other market data types.
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 through its focus on options-specific data, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or when not to use it. There is no reference to sibling tools or alternative data sources.
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 only adds 'CryptoCompare-compatible format' as a behavioral trait, but does not disclose pagination behavior, defaults, authentication needs, or explicitly confirm read-only nature. The 'Get' verb hints at safety but leaves substantial 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 sentence, front-loaded with the action verb, and contains no redundant phrasing. It is appropriately concise for a straightforward data retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain return format, result structure, and usage constraints. It only mentions Cryptocompare compatibility without describing what that means, and it lacks details on limit, aggregation, or relationships to sibling tools.
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 provides descriptions for all six parameters (100% coverage), meeting the baseline. The tool description itself adds no additional parameter semantics beyond what the schema's minimal labels like 'From symbol' and 'Exchange name' already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'minute-level OHLCV data', clearly distinguishing it from sibling tools like get_histohour and get_histoday. The addition of 'CryptoCompare-compatible format' further clarifies the output style.
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 minute-level granularity is explicitly stated, making it obvious when this tool is appropriate compared to hourly or daily variants. However, it does not explicitly mention alternatives or exclusion conditions, though the sibling tool names provide enough implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the consolidating behavior and multi-exchange scope, but lacks detail on return format, ordering, approximation behavior, or potential errors. As a read-only 'Get' tool, the safety is implicit, but deeper behavioral context is missing.
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?
A single, front-loaded sentence that gets straight to the point with no filler. Every word contributes to understanding the tool's core function.
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?
While the description is clear, it lacks an explicit statement about return value structure (no output schema), how 'consolidated' is achieved, or how filters interact across exchanges. Combined with the schema, it is minimally adequate but leaves operational uncertainty.
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 already provides full descriptions for all six parameters (100% coverage), so the description does not need to repeat them. It adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a resource 'consolidated trade data' and explicitly scopes it 'across multiple exchanges', clearly distinguishing it from the sibling tool get_trades which likely handles single-exchange trades.
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 trade data from multiple exchanges at once, but does not explicitly state when to use it over get_trades or provide any exclusions. The differentiation is only implicit via the phrase 'across multiple exchanges'.
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 discloses that no authentication is required and that it lists all supported exchanges/pairs. However, it does not mention return format, pagination, or any other behavioral nuances. For a simple list endpoint, this is minimal but adequate.
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—two short sentences, no filler. It front-loads the main purpose and immediately provides the key behavioral detail about authentication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (0 parameters, no output schema), the description is sufficiently complete for a simple listing tool. It explains what it returns and the auth requirement. Slightly more context (e.g., read-only implication) could be added, but it is not strictly necessary.
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 zero parameters, so the description does not need to add parameter semantics. The baseline for 0 params is 4, and the description correctly avoids mentioning nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('supported exchanges and trading pairs'), clearly distinguishing it from sibling tools that focus on trades, orderbooks, or OHLCV data. It unambiguously states what the tool does.
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 when to use this tool (when you need to know supported exchanges/trading pairs) but does not explicitly mention alternatives or exclusion criteria. It provides clear context but lacks explicit guidance on when not to use it, which is a minor gap.
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:

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

Score Badge

Copy to your README.md:

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

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