TickDB Market Data
Server Details
Real-time & historical market data: forex, stocks, crypto, indices, metals, K-line, quotes
- 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 3.2/5 across 13 of 13 tools scored. Lowest: 2.6/5.
Each tool serves a distinct data retrieval purpose (symbols, capital flow, intraday, kline, order book, trades, metrics, info, ticker, calendar, sessions). There is no functional overlap; agents can clearly distinguish which tool to use for a specific need.
All tool names follow a consistent 'get_' prefix with snake_case descriptors (e.g., get_available_symbols, get_kline_intervals). The pattern is uniform across all 13 tools, making it predictable for agents.
13 tools is well-scoped for a market data server. The number covers essential data types (reference, real-time, historical, depth, fundamentals, calendar) without being excessive or sparse.
The tool set provides comprehensive coverage for stock market data: symbol discovery, intraday and historical prices, order book, trades, fundamentals, capital flow, market metrics, and trading calendar. No critical gaps are evident for typical usage.
Available Tools
13 toolsget_available_symbolsAInspect
Query all tradable symbols on TickDB (37,527+ products).
Use this to discover and verify correct symbol codes before other calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| market | No | ||
| offset | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It correctly implies a read-only operation (query), but does not explicitly state that it is non-destructive or safe. Additional details like rate limits or authentication needs are absent, but for a simple discovery tool, this is minimally adequate.
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 concise: two sentences in a clear, front-loaded format. The first sentence states the primary action, and the second provides usage context. Every word earns its place without unnecessary elaboration.
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 0% parameter coverage, the description fails to explain return format, pagination behavior, or the effect of parameters. For a tool that lists over 37k symbols, details on output structure and pagination (via limit/offset) are essential for proper usage, and these are missing.
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 no information about the four parameters (type, limit, market, offset). With 0% schema description coverage, the description should explain how these parameters filter the symbol list, but it does not. The agent must rely solely on parameter names, which may be insufficient.
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's purpose: 'Query all tradable symbols on TickDB (37,527+ products).' It specifies the verb (Query) and resource (tradable symbols), and the mention of 'discover and verify correct symbol codes' distinguishes it from sibling tools that retrieve market data for existing symbols.
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 explicitly guides usage: 'Use this to discover and verify correct symbol codes before other calls.' This clearly indicates when to use the tool (before other data retrieval calls). While it doesn't list alternatives or when not to use, the context is sufficient for an experienced agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_capital_flowBInspect
Get capital flow (money flow) analysis for a stock.
Returns intraday flow timeline and breakdown of capital inflows/outflows
by order size: large, medium, and small.
Supported: US stocks, Hong Kong stocks, A-shares.
| Name | Required | Description | Default |
|---|---|---|---|
| type | 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 fully disclose behavioral traits. It mentions the output format but does not state whether the operation is read-only, requires authentication, has rate limits, or any side effects. The minimal disclosure falls short.
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 three sentences, all substantive. It starts with the main action, then details output, then supported markets. No superfluous content.
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 two parameters and no output schema, the description covers the core output and supported markets reasonably well. However, the lack of parameter documentation and behavioral details leaves gaps, making it minimally adequate.
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%, yet the description adds no explanation for the two parameters (symbol, type). It does not clarify what the 'type' field accepts or how to use it, leaving the agent without critical information to invoke the tool correctly.
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 capital flow analysis for a stock, specifies the output includes intraday timeline and breakdown by order size, and lists supported markets. This distinguishes it well from sibling tools like get_kline or get_intraday, which focus on price data.
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 implicitly guides usage by listing supported markets (US, HK, A-shares), but does not explicitly state when to use this over alternatives (e.g., get_market_metrics) or when not to use it. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_intradayAInspect
Get today's intraday minute-level price data for stocks.
Returns timestamp, price, volume, turnover, and average price per minute.
Supported: US stocks, Hong Kong stocks, A-shares.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| symbols | 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 indicates a read operation ('get') and lists return fields, which is adequate for basic understanding. However, it lacks details on rate limits, data freshness, or any potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load key information: purpose, output fields, and supported markets. No superfluous text.
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 the return format and supported markets but omits parameter explanations, error handling, and data scope limitations. For a tool with no output schema and 0% schema coverage, more detail is needed.
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% (no parameter descriptions). The description does not explain the 'symbols' or 'type' parameters, leaving the agent to infer them from the schema. It only describes the output, not the input semantics.
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 identifies the tool as getting today's intraday minute-level price data for stocks, listing specific fields and supported markets. It effectively distinguishes from sibling tools like get_kline which handles daily/candlestick data.
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 intraday data (today's minute-level) but does not explicitly state when to use versus alternatives like get_ticker or get_recent_trades, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_klineCInspect
Get historical K-line (OHLCV candlestick) data for a symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| symbol | Yes | ||
| end_time | No | ||
| interval | Yes | ||
| start_time | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description must disclose behavioral traits. It only mentions 'historical' data but omits details on rate limits, data range limits, pagination, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but its brevity sacrifices necessary detail. It is front-loaded and efficient, but not earningly informative given the tool's complexity.
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 6 parameters, no output schema, no annotations, and many sibling tools, the description is far too sparse. It fails to provide enough context for an agent to correctly invoke the tool or choose it over alternatives.
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%, yet the description does not explain any parameters. It only refers to 'symbol' implicitly but fails to describe 'interval', time bounds, 'limit', or 'type', leaving the agent without essential context.
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 historical K-line (OHLCV candlestick) data for a specific symbol. It uses a specific verb-resource pair and distinguishes itself from siblings like 'get_kline_intervals' and 'get_kline_latest'.
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_intraday' or 'get_ticker'. No context on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_kline_intervalsAInspect
List all supported K-line candlestick interval strings.
| 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, but description adequately discloses behavior: returns a list of interval strings. No hidden side effects or constraints evident.
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 wasted words, front-loads the action and object. Optimal conciseness.
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 zero-parameter, no-output-schema tool, the description fully captures its purpose and output type. Nothing essential missing.
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; description adds meaning by specifying what the tool returns (supported interval strings), which is the core semantic value.
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 verb 'list' and resource 'K-line candlestick interval strings', distinguishing it from siblings like get_kline which fetches data.
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_kline. Implicitly serves as a precursor to get_kline, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_kline_latestCInspect
Get the most recent (live/incomplete) K-line candle for one or more symbols.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| symbols | Yes | ||
| interval | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It notes 'live/incomplete' but fails to disclose details like rate limits, authentication needs, error handling, or what happens with missing data.
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 with no superfluous words. However, missing critical details slightly reduces efficiency.
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 and no output schema or annotations, the description is too sparse. It does not explain return value structure, symbol input format, or interval constraints. Expected more context to ensure correct invocation.
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%—no parameter descriptions in the schema. The description only clarifies that 'symbols' can be one or more, but does not specify format (e.g., comma-separated) or allowed values for 'interval'. 'type' is not explained.
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 verb 'Get', the resource 'K-line candle', and specifies the scope as 'most recent (live/incomplete)' and 'one or more symbols'. It effectively distinguishes from siblings like get_kline and get_kline_intervals.
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 alternatives such as get_kline or get_intraday. The description implies it's for live data, but does not explicitly state when-not or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_metricsBInspect
Get comprehensive market metrics and valuation data for stocks.
Returns: price, change, volume, turnover, YTD change, turnover rate, market cap,
capital flow, PE (TTM), PB ratio, dividend yield, 5/10/180-day price change rates.
Supported: US stocks, Hong Kong stocks, A-shares.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| symbols | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It lists return fields but omits critical info like data freshness, authentication requirements, rate limits, or whether the operation is read-only. The description is insufficient for an agent to understand behavioral constraints.
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 very concise—three short lines conveying purpose, output, and supported markets. No unnecessary words or redundancy.
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 adequately lists return metrics and supported markets for a tool with no output schema, but it lacks parameter explanations and any behavioral context. This leaves moderate gaps for an agent to use the tool correctly.
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 two parameters (symbols required, type optional) with 0% schema description coverage. The description does not explain either parameter, leaving the agent without guidance on how to construct valid inputs.
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 'comprehensive market metrics and valuation data for stocks' and lists the returned metrics. It distinguishes from siblings like get_intraday, get_kline, and get_order_book, which focus on specific data types rather than broad metrics.
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 explicit guidance on when to use this tool vs alternatives like get_stock_info or get_ticker. The description only mentions supported markets, implying scope but not providing any when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_order_bookBInspect
Get order book (market depth) with bid and ask price levels.
Returns bids and asks as [price, quantity] arrays, best price first.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| symbol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (bids/asks as [price, quantity] arrays, best price first) but omits permissions, rate limits, or side effects; adequate for a simple read 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?
Two sentences, front-loaded with core purpose, no redundancy.
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?
With 3 parameters (1 required) and no output schema, the description is incomplete; fails to explain parameter effects or full return structure.
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 description provides no explanation for parameters like 'type' or 'limit', leaving their semantics unclear.
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?
Clearly states 'Get order book (market depth) with bid and ask price levels', specifying the resource and differentiating from siblings like get_ticker or get_recent_trades.
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 vs sibling tools; lacks context for when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recent_tradesBInspect
Get the most recent executed trades for a symbol.
Returns trade id, price, quantity, side (buy/sell), and timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| symbol | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits (e.g., data freshness limits, rate limits, or required permissions). Only states output fields.
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?
Two sentences with no redundancy. Each sentence adds value: purpose and return fields. Front-loaded with the action.
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 simple tool with no output schema, the description covers basic output but omits parameter usage and behavioral context. Adequate but could improve with parameter explanations.
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?
Input schema has no parameter descriptions (0% coverage), and the description does not explain what parameters like 'type' or 'limit' do. The required 'symbol' is mentioned in the first sentence but not explicitly linked.
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 'the most recent executed trades for a symbol' and lists the returned fields (id, price, quantity, side, timestamp). This distinguishes it from siblings like get_order_book or get_ticker.
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_intraday or get_kline). No mention of context or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_infoAInspect
Get fundamental stock information.
Returns company name (CN/EN), exchange, currency, lot size, total/circulating
shares, EPS, EPS TTM, BPS, and dividend yield.
Supported: US stocks, Hong Kong stocks, A-shares.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| symbols | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return fields and supported markets, but does not detail behavior like handling multiple symbols, error scenarios, data freshness, or any side effects. The description is adequate but lacks depth for a fully transparent view.
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 concise with two sentences and a bullet-like list. It could be slightly more structured (e.g., separate sections for parameters and returns), but no unnecessary words are present.
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 lack of output schema, the description lists return fields but not the structure (e.g., JSON object). With many siblings, the description is somewhat complete for a basic info tool, but missing parameter details and behavioral context leave gaps.
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%, so description must compensate. The 'symbols' parameter is explained only in terms of supported markets, but not format (e.g., comma-separated). The optional 'type' parameter is completely unexplained. The description adds minimal meaning beyond the 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?
The description clearly states it returns fundamental stock information with a detailed list of fields (company name, exchange, EPS, etc.) and explicitly lists supported markets (US, Hong Kong, A-shares). This distinguishes it from siblings like get_kline (price charts) or get_order_book (order book depth).
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 (when fundamental data is needed) but provides no explicit guidance on when not to use it or comparisons to alternatives such as get_market_metrics or get_ticker. The supported markets hint at context, but no direct exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tickerCInspect
Get real-time price snapshots for one or more symbols.
Returns last price, 24h volume, 24h high/low, price change and percent change.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| symbols | 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 states 'real-time' and lists output fields, but omits behavioral traits like rate limits, error handling (e.g., invalid symbols), or any side effects. The read-only nature is implied but not explicitly stated.
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 short (two sentences) and front-loaded with the main purpose. It could be slightly more efficient by integrating parameter hints, but it is not verbose.
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?
Despite being a simple tool, the lack of parameter documentation (0% coverage) and missing output schema make the description incomplete. An agent would need additional guidance on formatting symbols and interpreting results.
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 provides no information about the two parameters: 'symbols' (format required, e.g., comma-separated) and 'type' (purpose, allowed values). The description adds no value beyond the schema's minimal structure.
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 retrieves real-time price snapshots for symbols and lists return fields (last price, volume, high/low, change). However, it does not explicitly differentiate from sibling tools like get_intraday or get_kline, which have different timeframes.
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_intraday or get_order_book. The description implies its purpose but provides no context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trade_daysBInspect
Get the trading calendar (trading days and half-days) for a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| beg_day | Yes | ||
| end_day | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it only states what the tool does without disclosing behavioral traits such as return format, data range constraints, or any limitations.
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, clear sentence with no extraneous information, earning its place. It is front-loaded with the core 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 three required parameters and no output schema, the description is too sparse. It fails to explain what the tool returns (structure of trading days and half-days), parameter formats, or any edge cases.
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%, meaning the description must compensate. It mentions 'date range' but does not explain the market, beg_day, or end_day parameters beyond what the schema shows.
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 'Get the trading calendar (trading days and half-days) for a date range' uses a specific verb and resource, clearly distinguishing it from sibling tools that deal with prices, order books, or stock info.
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 when needing trading day information, but provides no explicit guidance on when to use this tool versus alternatives like get_trading_sessions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trading_sessionsBInspect
Get current trading session schedule for a stock market.
Returns session begin/end times and session type (pre-market, regular, after-hours, closed, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by stating the return structure (session begin/end times and type). However, it does not disclose data freshness, caching, or any side effects, leaving some behavioral traits unclear.
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 two concise sentences. The first states the purpose, and the second adds return details. Every word adds value with no redundancy.
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 adequately covers output fields but omits parameter semantics and does not specify if 'current' means today or a specific date. Given the tool's simplicity, these gaps make it incomplete 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?
Schema coverage is 0% and the description does not explain the 'market' parameter. It mentions 'stock market' but offers no guidance on accepted values (e.g., exchange codes, country codes). This lack of detail hampers correct invocation.
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 'Get current trading session schedule for a stock market,' specifying the verb 'get', the resource 'trading session schedule', and the scope 'current'. It distinguishes from siblings like 'get_trade_days' which deals with trading day calendars, not intraday sessions.
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 provides no guidance on when to use this tool versus siblings. For example, it does not contrast with 'get_trade_days' or explain that this tool is for intraday session timings rather than date-level trading calendars.
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!