tickscope-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct aspect of market data or analysis: price snapshots, trades, candles, order book, funding, indicators, patterns, structure, etc. Overlapping analysis tools (compute_indicators, detect_divergence, detect_cross, etc.) have clear, specialized purposes and are well-differentiated by their descriptions.
Naming Consistency4/5
Most tools follow a verb_noun pattern (get_, list_, detect_, analyze_, find_, watch_, compute_, screen_). The style is uniformly lowercase with underscores, but a few names like 'server_status' and 'deep_analyze' deviate from the strict verb-first structure, making the pattern slightly less consistent.
Tool Count4/5
With 19 tools, this server is on the heavier side, but the broad scope of real-time market data, technical analysis, screening, and diagnostics justifies the count. Each tool serves a distinct purpose without feeling redundant, though a few analysis tools could theoretically be merged.
Completeness5/5
The tool set comprehensively covers the read-only market data and technical analysis domain: data retrieval (ticker, trades, OHLCV, orderbook, funding), symbol/exchange discovery, indicator computation, pattern/structure/divergence detection, screening, multi-exchange aggregation, and deep analysis. No significant gaps are apparent for its stated purpose.
Average 4/5 across 19 of 19 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on June 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 carries the full burden of behavioral disclosure. It lists the output fields but does not explicitly state that the tool is read-only, has no side effects, or requires no special authorization. While the name suggests a status check, the description does not confirm safety or operational impact.
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 clearly categorizes the tool ('Health and diagnostics') then lists the specific diagnostic fields. Every word contributes value, with no redundancy or unrelated information.
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?
The tool is a simple 0-parameter status endpoint with an output schema. The description explicitly enumerates the return contents, which is sufficient given the low complexity and the existence of an output schema. It could potentially mention that no authentication is needed, but that is not critical for a status tool.
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 schema already supplies complete parameter information. According to the baseline for 0-parameter tools, a score of 4 is appropriate; the description adds no parameter details but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Health and diagnostics' and lists the specific diagnostic fields (uptime, exchanges, watch count, cache rows, ccxt version, WebSocket reconnect count). This distinguishes it from sibling tools, which are all market data or analysis functions. However, it lacks an explicit verb like 'get' or 'retrieve', making it slightly less directive than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any conditions, exclusions, or mention of sibling tools. The use case is implied by the name and content, but there is no explicit 'use this when...' or 'for market data, use other tools'.
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 of behavioral disclosure. It explains that the tool analyzes the most recent lookback candles and that each result includes bias and bars_ago. It does not explicitly state that the operation is read-only, nor does it mention error behavior or side effects, but the context is fairly clear for an analysis 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 fairly concise: two sentences with a clear first sentence and a detailed but compact list of recognized patterns. It front-loads the primary purpose and then adds pattern detail. Slightly denser than necessary, but every sentence 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 five parameters and no annotations, the description provides a good overview of the tool's capabilities and output fields, but leaves gaps about how to use the parameters (especially limit, exchange, timeframe). The output schema exists, which can cover return structure, so the description is moderately complete but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explains 'lookback' and references output fields 'bias' and 'bars_ago', but it does not clarify 'symbol', 'exchange', 'limit', or 'timeframe', nor does it explain the relationship between 'limit' and 'lookback'. This leaves significant parameter ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('detect') and resource ('candlestick patterns'), and it enumerates many specific recognized patterns. This distinguishes it from sibling tools like detect_divergence or detect_cross, which target different analysis 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: an agent should use this when it needs to identify candlestick patterns. However, it does not explicitly contrast with alternatives or state when not to use it (e.g., for divergence or indicator calculations). The guidance is present but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It transparently explains the algorithmic behavior—building alternating swings, labeling HH/HL/LH/LL, inferring trend, and reporting BOS/CHoCH—but does not disclose edge cases, data requirements, or explicit read-only semantics; still, 'analyze' and the computation-heavy description make side effects unlikely.
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?
Two short paragraphs, summary first, then implementation details. No filler sentences; the code-formatted mentions of trend and left/right add structure without bloat.
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 description covers the core algorithm and key parameters but lacks usage guidance and fuller parameter semantics. The existence of an output schema compensates for return-value documentation, but the low schema coverage and missing alternatives discussion leave gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only elaborates left/right as the pivot confirmation window. Other parameters (symbol, exchange, timeframe, limit) are left to inference or defaults; given the low coverage, more parameter-level explanation is needed.
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?
Clearly identifies the tool as market-structure analysis with a specific verb ('Analyze'), enumerates outputs (swing highs/lows, trend, BOS/CHoCH), and differentiates itself from sibling tools like compute_indicators or detect_patterns by focusing on alternating swing structure and breaks.
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 use for market-structure analysis but never explicitly states when to choose it over alternatives, nor any exclusions or prerequisites. For instance, it doesn't contrast with find_support_resistance or detect_patterns, leaving the selection criteria to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the clustering process (grouping pivots within tolerance_pct), zone strength (touches), and output selection (nearest support/resistance). This provides meaningful behavioral insight, though it omits details like network dependencies 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: introducing the tool, detailing the grouping mechanism, and specifying the output. It is front-loaded with the main purpose and contains no fluff.
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 description covers the core algorithm and output, and the presence of an output schema reduces the need to describe return values. However, with six parameters and zero schema descriptions, the tool would benefit from more context on how exchange, limit, and max_levels influence results. The description is adequate for a simple tool but leaves gaps for complex configurations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions tolerance_pct explicitly and implies the role of symbol/timeframe, but it does not explain limit, exchange, or max_levels. Since over half the parameters lack any explanation, the description adds limited value beyond the raw 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 clearly states the tool 'finds clustered support/resistance zones from swing pivots', using a specific verb and resource. It distinguishes itself from siblings like analyze_structure or detect_patterns by detailing the output: nearest support (below price) and resistance (above price) zones with distances.
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 technical analysis to locate key price levels, but does not explicitly state when to use this tool versus alternatives. It mentions the algorithm and output but lacks any exclusion or comparison to sibling tools, so guidance is only implicit.
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 behavioral transparency burden. It adds useful details beyond the schema, such as 'quote' filtering by quote currency and 'search' being a case-insensitive substring match. However, it omits behavior about the 'limit' parameter, 'exchange' null handling, pagination, or result ordering, leaving some transparency 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 three sentences: a clear purpose statement, a usage tip, and parameter details. It is front-loaded with the main action, uses bullet-like formatting for filters, and every sentence adds value without unnecessary fluff.
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 is relatively simple with an output schema, so return values need not be described. However, the description lacks coverage of 'limit' and 'exchange' semantics, and does not address potential ambiguities like what happens when 'exchange' is null. It is adequate for basic use but incomplete for a fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It explains only two of four parameters ('quote' and 'search') with concrete examples. 'limit' and 'exchange' are left entirely to the schema, which only provides names and types—no semantic guidance. This incompleteness fails to fully compensate for the zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List tradable symbols on an exchange, optionally filtered.' This is a specific verb+resource construction that immediately distinguishes it from siblings like list_exchanges or get_watched_symbols. The added note about discovering valid symbols before other calls reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'to discover valid symbols before other calls,' which provides clear context for when to invoke it. It does not explicitly name alternatives or exclusions, but the 'before other calls' phrasing implies it is a prerequisite rather than a replacement for other data-fetching tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a solid job. It discloses output behavior in detail: returns each indicator's latest value(s) plus derived signals like state, cross, direction, flip, and signal. It also explains the effect of include_series. It does not mention potential errors or rate limits, but these are less critical for a read-only compute tool. It adds substantial behavioral context beyond what structured fields would provide.
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 long but well-structured: a one-line purpose, a concrete example, categorized indicator lists, and a paragraph on returns. The length is justified by the need to enumerate 73 indicators and their aliases. It front-loads the key information and does not ramble, though the sheer volume may be slightly overwhelming. Overall it is efficient for the complexity.
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 tool's complexity, the description covers the essential aspects: input format, supported indicators, and return value semantics. It even notes special output flags (cross, state, direction). Since an output schema exists, the exact return structure need not be described. It does not mention error behavior or data requirements, but for a compute tool with rich output documentation, it is reasonably complete.
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 0%, so the description must compensate. It thoroughly explains the most complex parameter (indicators): format, examples, aliases, and the full supported list. It also explains include_series. However, it does not explicitly describe symbol, timeframe, exchange, or limit; these are only implied by the opening phrase and parameter names. Given the complexity of indicators, the description partially compensates for the lack of schema descriptions, but leaves gaps for other 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 opens with a clear, specific verb+resource: 'Compute technical indicators for a symbol/timeframe.' It distinguishes itself from sibling tools that do higher-level analysis (e.g., detect_cross, detect_divergence) by focusing on raw indicator calculation. The extensive list of supported indicators further reinforces its unique purpose.
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 clearly implies when to use this tool (when you need indicator values or derived signals) but does not explicitly exclude alternatives or refer to sibling tools. For example, it mentions returning 'cross' signals, which overlaps with detect_cross, but does not say 'use detect_cross for event detection' or provide any when-not guidance. Thus the usage is conveyed but not contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the input format handling and the output elements (latest values, relation, cross occurrence, bars since last cross), but omits explicit read-only confirmation and failure or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written, with every sentence contributing value. It leads with the core function, explains input syntax, gives an explicit example, and summarizes the return payload without redundancy.
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?
The description adequately covers the tool's purpose, key parameters, and return summary for a moderately complex technical analysis tool. Minor gaps remain in explaining limit semantics and how to integrate other parameters, but the overall context is sufficient.
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?
Given 0% schema description coverage, the description must compensate. It thoroughly explains series_a and series_b with formats ('ema:20') and an example, but does not describe parameters like limit, timeframe, symbol, or exchange, leaving them to inference from titles/defaults.
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 'Pine-style crossover analysis' with reference to ta.crossover/ta.crossunder, defining the tool's exact function. It distinguishes from sibling detection tools by specifying crossover detection, and provides a concrete golden cross example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for crossover/crossunder analysis) and gives an example use case. It does not explicitly list exclusion criteria or alternative tools, but the intended usage is evident from the explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 transparently describes the pivot-based algorithm, the flexible oscillator parameter, and the return content (pivot values and bar offsets), which goes beyond a vague statement. However, it omits potential edge cases like empty results or insufficient data, so it is not maximally transparent.
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 concise and well-structured, opening with the core purpose, then the method, then parameter specifics and return values. Each sentence earns its place without redundancy, making it easy to parse and act upon.
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 tool's complexity (7 parameters, no annotations) and the presence of an output schema, the description is fairly complete. It covers the detection logic, return content, and gives examples of oscillator specs. Minor omissions include the role of 'limit' and any prerequisites, but overall it provides sufficient context for an agent to select and invoke the tool correctly.
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 zero descriptions (0% coverage), so the description must compensate. It explains the semantics of oscillator and left/right, which are tool-specific and crucial. However, it leaves standard parameters like symbol, exchange, timeframe, and limit unexplained, meaning roughly half the parameters lack semantic detail beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects bullish and bearish divergence between price and an oscillator, which is a specific and distinct action. It explicitly distinguishes this from siblings like detect_cross (crossovers) and detect_patterns (patterns) by naming the exact concept of divergence.
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 by explaining its function, but it does not explicitly contrast it with alternatives or provide exclusions. The oscillator format and pivot window details hint at usage scenarios, yet there is no direct guidance on when to choose divergence detection over other analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool uses a live WebSocket buffer when warm and falls back to REST, plus a depth cap at 100 and freshness fields. It does not cover error cases or latency implications, but is fairly transparent for a read-only data retrieval.
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?
Two concise sentences: the first establishes purpose, the second details return fields and data source behavior. No filler or redundancy, and key information is front-loaded.
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?
An output schema exists, so return values are covered. The description adds depth cap and the WebSocket/REST fallback context. However, it lacks guidance on when to choose this tool over siblings and does not mention error handling or exchange requirements. Overall adequate for a straightforward snapshot tool, but not exhaustive.
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 0%, so the description must compensate. It explains the 'depth' parameter (top-N bids/asks capped at 100) but does not elaborate on 'symbol' or 'exchange' beyond their names. These are relatively self-explanatory, but the description only partially fills the gap.
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 the current order book snapshot with computed spread,' using a specific verb and resource. It distinguishes the tool from siblings like get_ticker and get_ohlcv, which address different 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 ('Get the current order book snapshot') but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or mention sibling tools. The context is clear but guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output components (channels, buffer size, last update, staleness) and labels the operation as diagnostic, which adds context. However, it does not mention prerequisites like an active WebSocket connection or explicitly confirm the operation is read-only, though 'list' implies it.
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 with a clear verb-first structure, including a parenthetical qualifier and specific data fields. Every word earns its place, with no redundant or vague phrasing.
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?
The description covers the core purpose and output details, and since an output schema exists, return values need not be explained. It could be enhanced by noting how this relates to watch_symbol or server_status, but for a zero-parameter diagnostic list, it is sufficiently complete.
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 baseline of 4 applies. The description does not need to elaborate on arguments, and the schema confirms no required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists currently active WebSocket subscriptions and their buffer state, naming the specific returned fields (channels, buffer size, last update, staleness). It includes a 'diagnostic' qualifier that distinguishes it from sibling data retrieval tools like get_ticker or get_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?
The description implies usage for checking subscription status and diagnostics, but does not explicitly state when to use this tool vs alternatives such as watch_symbol or server_status. It also does not mention any exclusions or alternative tools, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 concurrent fetching, the computed metrics (volume-weighted average, simple mean, best/worst venue, spread), and a key error-handling behavior: venues that fail or lack the symbol are skipped. It does not mention rate limits or caching, but for a read-only aggregation tool this is acceptable.
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?
Two short paragraphs: the first is a concise one-sentence summary, the second provides necessary detail on outputs and failure handling. Every sentence adds value with no redundancy.
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?
With only 2 parameters and no annotations, the description covers purpose, computation logic, and error behavior. It does not detail return structure, but an output schema exists, so that burden is already handled. It is sufficiently complete for an agent to select and call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints at the `exchanges` parameter with 'configured (or given) exchange', but does not explain symbol format, how to specify venues, or what happens when `exchanges` is null. The schema is minimal and the description adds only vague semantics, leaving significant gap.
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 'Aggregate' and identifies the exact resource ('a symbol's price across multiple exchanges'), explicitly framing it as an 'arbitrage view'. This clearly distinguishes it from siblings like get_ticker, which focuses on a single exchange.
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?
It states the use case as an 'arbitrage view' and 'the foundation for spotting arbitrage', making it clear when to use this tool over single-exchange alternatives. It does not explicitly name alternatives or exclusions, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It goes beyond the obvious by explaining the cold-call REST behavior and subsequent WebSocket freshness, plus the meaning of the 'source' field. It doesn't cover error handling or rate limits, but the provided context is valuable and not expected by default.
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 concise and front-loaded, opening with the main purpose in the first sentence. It then efficiently lists return fields and explains the freshness/WebSocket behavior without redundancy. Every sentence carries useful information, achieving maximum economy.
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 tool's moderate complexity and the presence of an output schema, the description covers key aspects: return fields, cold/warm behavior, and the freshness fields. It falls short only in not addressing the 'exchange' parameter, which is a small omission relative to the overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for parameter meaning. While 'symbol' is self-evident, the optional 'exchange' parameter is not elaborated at all—the description never mentions what 'exchange' is for or how it affects results. This leaves a significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a current price snapshot for a symbol and explicitly positions it as 'the primary quote tool.' It distinguishes itself from siblings like get_recent_trades and get_ohlcv by focusing on the quote/ticker use case with specific return fields (bid/ask, 24h data).
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 phrase 'primary quote tool' provides clear context for when to use it (for current price snapshots), but it does not explicitly mention when not to use it or name alternative tools for other data needs. It implies usage without exclusions, which fits the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses that the tool is read-only, is not financial advice, is heavier (reads multiple timeframes and runs an event study), and describes a 'strictly causal event study' to indicate methodological rigor. It lacks explicit mention of rate limits or error behavior, but for a read-only market-data tool, this is adequate and adds meaningful context beyond the raw schema.
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 well-structured: it opens with a clear purpose statement, uses a list to enumerate return contents, and follows with concise usage guidance and a default-behavior note. It is slightly verbose but every sentence adds useful information, and key details are front-loaded.
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 tool's complexity, the description covers its purpose, return contents, usage context, performance characteristics, and safety (read-only, not financial advice). The presence of an output schema means return values are already documented elsewhere. The main gap is parameter explanations, which are scored separately, so overall completeness is high for a heavy analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only explains the timeframes parameter default (1d/4h/1h ladder) and leaves horizon, exchange, and oscillator unexplained. An agent would not know what 'horizon' or 'oscillator' represent in this context, significantly hampering correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a thorough, evidence-backed read of one symbol across multiple timeframes, listing specific outputs such as per-timeframe trend, momentum, statistical context, forward-return distribution, and a synthesized verdict. It distinguishes itself from sibling tools by naming lighter alternatives (compute_indicators, analyze_structure, detect_divergence) and positioning itself as the heavy, comprehensive option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when the user wants a thorough judgement', 'asks whether a setup is worth taking', 'analyze X deeply') and when not to ('quick one-value questions', recommends single-shot tools). It also names the lighter alternatives directly, providing unambiguous guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It does this by stating the tool returns both current and predicted funding rates, requires a perpetual symbol, and returns a structured error if the exchange does not support funding rates. This goes beyond a simple 'get' and provides useful behavioral expectations, though it stops short of discussing authentication or rate limits.
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 concise, with three short sentences that front-load the main purpose. Every sentence adds value, and the example symbol format is integrated efficiently. No fluff or redundant information.
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 output schema exists, the return format is covered. The description adds key context about symbol requirements and error behavior. However, it does not clarify the behavior of the exchange parameter, nor what 'predicted' funding rate implies. For a tool with only two parameters and an output schema, this is adequately complete but has minor 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?
Schema coverage is 0%, so the description must compensate. It provides meaningful guidance for the 'symbol' parameter with an explicit perpetual format example (BTC/USDT:USDT), but the 'exchange' parameter is not explained. Since the exchange parameter is optional and nullable, the lack of documentation leaves some ambiguity. Overall, partial but not comprehensive compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves funding rates for perpetual futures, with a specific verb and resource. It distinguishes from sibling tools by focusing on funding rates and providing a symbol format example. The purpose is immediately obvious and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (perpetual futures) and even warns that the symbol should be a perpetual. While it does not explicitly name alternative tools or exclusion criteria, the context is specific enough to guide correct usage. It could be improved by saying 'for spot, use get_ticker' but is still strong.
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 partially carries the behavioral disclosure burden. It explains the return value (configured exchange ids and default exchange) but does not describe any side effects, permissions, or potential errors. Since this is a simple read-only list, the provided details are adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the verb 'List.' Every sentence contributes essential information without any fluff or repetition. It is highly concise and well-structured.
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 tool's simplicity (zero parameters, output schema provided), the description is largely complete. It states the output and a key behavioral detail about the default exchange. It does not discuss prerequisites or environmental context, but for a configuration listing, this is a minor gap.
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 baseline is 4. The description does not need to explain parameter details, and the reference to the 'exchange' argument is about other tools, not this one. The description adds no parameter-specific meaning beyond what the schema shows (an empty 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 'List' and clearly identifies the resource: 'the exchanges this server is configured to use.' It distinguishes this from all sibling tools, which focus on market data and analysis, not configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about the tool's purpose and even explains the relevance of the default exchange for other tool calls. It does not explicitly state when to use this tool versus alternatives, but the sibling tools are mostly unrelated, and the use case is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses bounded concurrency for rate limits, per-symbol failures in errors, and the default symbol universe (top_n by 24h volume). These are meaningful behavioral traits beyond the basic operation, though it does not detail response structure or edge-case handling.
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 compact and front-loaded with the purpose, followed by a concrete filter example and key behavioral notes. Every sentence earns its place with no filler or repetition.
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 7 parameters and no annotations, the description covers the essential invocation details: filter format, operator list, default symbol selection, and error reporting. An output schema exists, so return format is presumably handled there. Missing some parameter explanations (exchange, timeframe) but the core usage is clear enough for an agent to call the tool correctly.
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?
Schema description coverage is 0%, so the description must compensate. It provides a detailed example for 'filters' with valid 'op' values, clarifies the behavior of 'symbols' (omit to use top_n), and mentions 'quote' and 'top_n'. However, 'exchange', 'timeframe', and 'sort_by' are not semantically explained beyond their names/defaults, leaving some gaps.
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 opens with 'Screen many symbols by indicator and price conditions,' which is a specific verb+resource+scope statement. It clearly distinguishes this tool from siblings like get_ticker or compute_indicators by focusing on multi-symbol screening with conditions.
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 the tool is for screening symbols, but it does not explicitly state when to use it over alternatives or provide exclusions. The behavior when symbols are omitted is explained, yet no direct comparison with sibling tools is given. Usage context is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well: it discloses the DuckDB cache-first behavior, REST topping-up of the tail, the acceptable timeframe formats, and the limit cap of 1000. It omits details like error behavior or pagination, but for a read-only OHLCV tool, this is solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences plus a parenthetical. The main purpose is front-loaded, and each clause provides actionable detail (caching, formats, cap) without fluff. No wasted words.
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 presence of an output schema, no return-value explanation is needed. The description covers caching architecture, input formats, and limits, which is adequate for a data-fetching tool. It could mention exchange behavior or symbol validation, but these are minor gaps for the tool's complexity.
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?
Schema coverage is 0%, so the description compensates by explaining timeframe ('1m,5m,15m,1h,4h,1d'), since (ISO-8601 or epoch-ms), and limit (capped at 1000). It does not explain symbol or exchange, but those are self-explanatory. This adds meaningful semantics beyond the bare 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 opens with 'Get historical OHLCV candles,' which is a specific verb-resource pairing that clearly differentiates it from siblings like get_ticker (current price) and get_recent_trades (trades). The phrase 'basis for charts and indicators' further clarifies the domain and intended use.
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?
It provides context by mentioning it serves historical candles for charts/indicators, implying when to use it over ticker/trade tools. However, it does not explicitly state 'use this instead of X' or list when-not-to-use scenarios. This is clear context but not full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It goes beyond a simple 'get' by disclosing two key behaviors: fallback from a cold buffer to a REST snapshot, and the side effect of 'starts watching' when that fallback occurs. It also explicitly caps limit at 1000, which is not evident from the schema alone.
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 short and front-loaded with the essential purpose. The second sentence adds two high-value behavioral details without verbosity. Every word earns its place, and formatting with backticks on limit aids readability.
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?
The description covers the core behavior, fallback, side effect, and a hard limit, which is strong for a real-time data tool. An output schema exists, so not explaining return values is acceptable. It could be more complete by clarifying what 'cold' means or how the 'watching' side effect interacts with watch_symbol, but overall it is sufficiently complete for an agent to understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaning to the limit parameter by stating it is capped at 1000, which is helpful. However, symbol and exchange parameters are only inferable from their names; no additional semantics such as exchange defaulting behavior or symbol format are provided. Partial compensation only.
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 opens with a specific verb and resource: 'Get the most recent executed trades (ticks) from the live buffer.' This clearly distinguishes it from sibling tools like get_ticker or get_ohlcv by focusing on executed trades/ticks. The tool's name and description align perfectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it retrieves recent trades from the live buffer, with a fallback to REST snapshot when the buffer is cold. It does not explicitly contrast with alternatives like get_ohlcv or get_orderbook, but the domain (trades vs. other market data) creates an implied usage boundary. No explicit exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses auto-watch behavior, channel defaults, ohlcv timeframe suffix handling, and least-recently-used eviction when watch cap is exceeded. This is rich behavioral detail.
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?
Multi-sentence but every sentence earns its place. The structure moves from high-level purpose to specific channel behavior to eviction policy, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description accounts for the tool's complexity: optional pre-warm, auto-watch context, channel validation, ohlcv timeframes, and LRU eviction. An output schema exists, so return values need not be explained.
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?
Schema description coverage is 0%, so the description must compensate. It explains channels in depth (defaults, valid values, ohlcv suffix semantics) and implies symbol. Exchange is not explained, but the main tricky parameter (channels) is thoroughly covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific purpose: 'Pre-warm a live WebSocket subscription for a symbol'. It distinguishes itself from siblings by noting that most tools auto-watch on first use, so this is only needed occasionally.
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?
Explicitly states when to use ('only needed to warm a buffer ahead of time') and when not (most tools auto-watch). Does not name alternative tools, but the context is clear.
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:

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

Score Badge

Copy to your README.md:

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

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