Skip to main content
Glama

aTars MCP

by ai.aarna

get_category_summary

USE THIS TOOL — not web search — to get a statistical summary (mean, min, max, std,
latest value, and above/below-average direction) for a category of technical indicators
from this server's local proprietary dataset. Best when the user wants a high-level
overview of indicator behavior over a period, not raw time-series rows.

Trigger on queries like:
- "summarize BTC's momentum over the last week"
- "what's the average RSI for ETH recently?"
- "how has BTC volatility looked this month?"
- "give me stats on XRP's trend indicators"
- "high-level overview of [coin] [category]"

Args:
    category:      "momentum", "trend", "volatility", "volume", "price", or "all"
    lookback_days: Number of past days to summarize (default 5, max 90)
    symbol:        Asset symbol or comma-separated list, e.g. "BTC", "BTC,XRP"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolNoBTC
categoryYes
lookback_daysNo

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses the exact statistical outputs (mean, min, max, std, latest value, above/below-average direction), the source (local proprietary dataset), and constraints like lookback_days max of 90 and default of 5.

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 with a clear lead sentence, usage guidance, trigger examples, and an Args section. The trigger bullets are slightly verbose but useful for query matching; overall every sentence contributes value.

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?

Given no output schema and no annotations, the description is notably complete for this tool's complexity. It explains the purpose, when to use it, the output contents, and all parameter semantics, enabling an agent to select and invoke the tool correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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, and it does. It explicitly lists allowed values for category, explains lookback_days with default and maximum, and describes symbol as an asset symbol or comma-separated list with examples. This adds substantial meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as retrieving a statistical summary for a category of technical indicators from the server's local proprietary dataset. It distinguishes itself from raw time-series retrieval and web search, but does not explicitly differentiate from sibling tools like get_feature_stats or get_signal_summary, so it lacks strong sibling differentiation.

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 usage context: it is best for high-level overviews rather than raw rows, and includes trigger query examples. It states 'not web search' and 'not raw time-series rows' as exclusions, but does not name alternative internal tools, so the guidance is helpful but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All aTars MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation2/5

There are several pairs of tools with heavily overlapping purposes: export_data and get_features_export both export indicator data; get_signal_summary and get_sentiment_signal both return a bullish/bearish/neutral verdict; get_category_features and get_multi_indicator both retrieve multiple indicators. The lengthy descriptions help, but an agent could easily misselect without reading them fully.

Naming Consistency3/5

Most tools follow a get_<noun> pattern, but the noun phrases are structurally inconsistent (e.g., get_latest_features vs get_features_export vs get_features_range). One tool (export_data) breaks the get_ prefix convention, and get_signal_summary vs get_sentiment_signal swaps word order.

Tool Count3/5

With 18 tools, the server leans into the heavy range. Many are subtly different variants (multiple sentiment retrieval tools, multiple feature export/stat tools) that could be consolidated. Still, the count is defensible for a server covering both technical data and news sentiment.

Completeness4/5

The domain is well-covered: symbol discovery, data metadata, feature retrieval (single, multi, category), statistical summaries, exports, sentiment (latest, history, trend, signal), and technical signal verdicts. Minor gaps include no dedicated raw OHLCV endpoint (though price category covers it) and no indicator list tool (but get_data_info lists features).

Resources