market-data
Server Details
Verified market data for AI trading agents: quality-flagged candles, funding, OI, order flow. x402.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 2.7/5 across 11 of 11 tools scored. Lowest: 1.3/5.
Each tool targets a distinct data product or function (bundle, catalog, bars, context, events, features, funding, open interest, orderflow, regime label, validation). No significant overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., build_bundle, describe_catalog, get_bars), making it predictable for agents.
With 11 tools, the set is well-scoped for a market data server, covering discovery, raw data, derivatives, quality checks, and bundles without being excessive.
The tool surface covers key market data needs: discovery, OHLCV, features, events, funding, open interest, order flow, regime labels, and backtest validation. No obvious gaps for the stated purpose.
Available Tools
11 toolsbuild_bundleCInspect
Signed URL for a dataset SKU. Packs: crypto|equities ($59 each), everything ($149: both packs + all token sequences, $730 list), tokens ($18/symbol), dataset (per-symbol OHLCV, crypto $14 / equity $5), mtf (aligned multi-timeframe bundle $9, crypto only), features (feature matrix, crypto $7 / equity $4). Priced as the SKU.
| Name | Required | Description | Default |
|---|---|---|---|
| tf | No | features only — crypto: 1h (default) or 15m; equity: 1d | |
| pack | Yes | ||
| symbol | No | required for tokens|dataset|mtf|features |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should clarify behavior (e.g., read-only, destructive, auth needs). It only mentions pricing and does not disclose that the tool likely generates a URL (a read operation) or if it charges the user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose with a dense pricing list that distracts from the core action. The first sentence is somewhat front-loaded but is followed by cluttered pricing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what the signed URL is used for, how to use it, or what the return value is (no output schema). It lacks completeness for a tool that presumably returns a URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds pricing details for pack options, providing context beyond the enum values. However, it does not explain the 'tf' or 'symbol' parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Signed URL for a dataset SKU' but fails to use a clear verb like 'generate' or 'create'. The bulk of the text is a pricing list, making the core action ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like get_bars or get_features. It does not state prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_catalogCInspect
Free discovery: symbols, timeframes, ranges, pricing, quality legend.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose behavioral traits such as read-only nature, required authentication, rate limits, or side effects. 'Free discovery' does not clarify whether results are cached or dynamic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence), but lacks structure and front-loads vague phrasing 'Free discovery.' Could be improved while maintaining brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description should explain return format and usage. It lists content types but not how they are organized or accessed, leaving an AI agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds minimal value by listing discoverable content (symbols, timeframes, etc.), but does not conflict with schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description is vague: 'Free discovery' lacks a clear verb and resource. It lists content types but does not state what the tool does (e.g., returns a list, or provides metadata). Distinction from siblings like get_bars is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_bars, get_features, etc. The description implies discovery but does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_barsCInspect
Quality-flagged OHLCV candles. Priced per 1,000 candles.
| Name | Required | Description | Default |
|---|---|---|---|
| tf | Yes | ||
| end | No | ||
| start | No | ||
| symbol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'quality-flagged' but does not explain what that entails or disclose behavior like rate limits, authentication needs, or any side effects. The pricing note is useful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, two short phrases. No redundant information. However, it may be too terse, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with no output schema and no annotations, the description is incomplete. It does not specify return structure, filtering logic, or how quality flags work. Agent cannot reliably understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the four parameters (tf, end, start, symbol) beyond the schema. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns quality-flagged OHLCV candles and mentions pricing. The verb 'get' and resource 'bars' are specific, but lacks clarity on what 'quality-flagged' means or how it differs from siblings like get_events or get_funding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention contexts, prerequisites, or cases where other tools (like get_features or get_context) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contextDInspect
Context series: fear_greed_1d, VIX_1d, DXY_1d, TNX_1d, DJI_1d.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| series | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only, destructive, rate limits). It does not even confirm this is a retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but achieves no clarity. It is under-specified to the point of being unhelpful, not genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only a list of series names, the description fails to provide a minimally complete specification. The agent cannot understand what the tool returns or how to use the parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning for the 3 parameters (series, start, end). It only lists sample values for 'series', ignoring start and end entirely. No formats, ranges, or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists specific series names (fear_greed_1d, VIX_1d, etc.) but lacks a verb or explicit purpose statement. It does not clearly state that this tool retrieves context data, leaving the agent to infer the purpose from the context of the tool name and siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like get_bars or get_events. No exclusions, prerequisites, or usage context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventsCInspect
Curated macro/crypto events (FOMC w/ surprise, halvings, incidents) in a range.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| type | No | ||
| start | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It mentions that events are curated and filtered by a range but fails to disclose if events are historical or future, what the output looks like, or any side effects. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is maximally concise with no redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description lacks essential details such as output structure, date format, type options, and behavior when parameters are omitted. Incomplete guidance for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 string parameters (end, type, start) with 0% schema description coverage. The description does not explain any parameter's format, allowed values, or purpose beyond the implied date range. It adds no value over parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as curated macro/crypto events and specifies examples (FOMC, halvings, incidents) and a range constraint. While the verb is implied by the name, the description effectively conveys what the tool returns and differentiates from siblings like get_bars or get_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when not to use it. An agent would have to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_featuresCInspect
Documented leakage-safe feature matrix rows. Priced per call.
| Name | Required | Description | Default |
|---|---|---|---|
| tf | Yes | ||
| end | No | ||
| start | No | ||
| symbol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'leakage-safe' (important for avoiding look-ahead bias) and 'Priced per call' (cost implication), which are useful beyond the empty annotations. However, it does not disclose failure modes, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, direct sentences with no superfluous information. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain return format, parameter constraints, or usage patterns, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (symbol, tf, start, end). The agent receives no guidance on what these mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'feature matrix rows' and 'Priced per call', but does not explicitly state that the tool retrieves features for a given symbol and timeframe. The purpose is implied but not clearly articulated as a specific verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 its siblings (e.g., get_bars, get_events). The description lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fundingBInspect
Perp funding-rate settlement history from listing date (checksummed archive).
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| symbol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It implies read-only retrieval and mentions 'checksummed archive' (data integrity), but does not specify required permissions, rate limits, or error behavior. Moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with key information. Concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema or annotations, the description omits parameter details, date format, and return structure. Not complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any parameter (symbol, start, end) beyond implying start date context. No format or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'perp funding-rate settlement history from listing date (checksummed archive)'. It specifies the resource (funding-rate history) and distinguishing context (archive-based, from listing date).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus siblings like get_open_interest or get_events. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_open_interestCInspect
Hourly open interest with per-row quality flags (verified archive + flagged bridge).
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| symbol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides minimal behavioral context. It mentions quality flags but does not specify read-only, destructive, or rate-limiting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that directly states the tool's function. Concise and front-loaded, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema, the description is insufficient. It does not explain return format, timezone handling, or the meaning of quality flags.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the parameters (symbol, start, end). The agent must guess their meaning and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves hourly open interest with quality flags. It distinguishes from siblings like get_bars or get_funding by its specific financial metric, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_bars, get_orderflow). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_orderflowBInspect
Taker buy/sell imbalance, trade counts, quote volume (1h/1d via API; denser tiers in packs). buy_ratio 0.5 = balanced.
| Name | Required | Description | Default |
|---|---|---|---|
| tf | No | ||
| end | No | ||
| start | No | ||
| symbol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions timeframes and data tiering but omits crucial details: whether the operation is read-only, authentication requirements, rate limits, or data freshness. The description offers limited transparency for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's output, key metric, and data tier options. Every word adds value, and it is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, pagination behavior, valid symbol formats, or how start/end parameters interact. Users are left with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the 'tf' parameter (1h/1d) and the semantic meaning of 'buy_ratio', but it fails to describe 'symbol' (required), 'start', and 'end' parameters. The mention of 'denser tiers in packs' does not map to any parameter, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns taker buy/sell imbalance, trade counts, and quote volume, distinguishing it from sibling tools like get_bars (price data) and get_open_interest (contracts outstanding). It mentions buy_ratio as a key metric, making the purpose specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at usage by mentioning available timeframes (1h/1d via API) and denser tiers in packs, implying when denser data is needed. However, it does not explicitly state when to use this tool over siblings or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_regime_labelBInspect
Descriptive market-state label (trend/range × calm/vol quadrant) for the most recent completed bar at or before a timestamp. Not a prediction.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| timestamp | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the tool is not a prediction and defines the output quadrant format. However, it does not mention read-only nature, rate limits, or authentication requirements, which would be helpful for behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence plus a short note, with no wasted words. It directly states purpose and key characteristics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains the return value as a label in quadrant form. However, it does not specify the data type (string? object?) or provide examples. For a simple tool with two parameters, this is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description does not explain 'symbol' (likely a ticker) or 'timestamp' (format and meaning). It only vaguely implies timestamp is used for bar selection. This is insufficient for an agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a descriptive market-state label based on trend/range and calm/vol quadrants for a specific bar. It distinguishes itself from siblings by specifying it's not a prediction and focuses on a completed bar at or before a timestamp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a non-predictive market-state label, but does not provide explicit guidance on when to use this tool over alternatives like get_context or get_features. No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_backtest_dataAInspect
Quality report for a dataset spec before you backtest on it: coverage, per-bar quality distribution, gaps, and concrete warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| tf | Yes | ||
| end | No | ||
| start | No | ||
| symbol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It describes the report content (coverage, distribution, gaps, warnings) but does not disclose behavioral traits like idempotency, side effects, or computational cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and lists key report components. No extraneous words, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers overall purpose but lacks details on parameter semantics, output format, and prerequisites. Given no output schema, more explanation of the return value would improve completeness for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but only hints at parameters via 'dataset spec' without explaining individual parameters like symbol, tf, start, end. This leaves the agent with minimal parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a 'quality report' for a dataset spec before backtesting, listing specific outputs like coverage and gaps. It differentiates from sibling data retrieval and bundle-building tools by its validation role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before you backtest on it' provides clear usage context, implying this is a preparatory step. However, it does not explicitly state when not to use or name alternatives among siblings, slightly reducing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!