A quant-factor brain for your AI — factor scores, similarity search, and risk-coherence analogues for 14,684 tickers across 6 asset classes
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.
Average 4.4/5 across 14 of 14 tools scored. Lowest: 3.9/5.
Most tools target distinct resources (features, embeddings, labels, market context, risk clusters), but minor overlap exists: get_market_context includes a regime reading that get_market_regime also provides, and get_report_card bundles features that get_features offers separately. Descriptions are clear enough to resolve these overlaps.
The predominant pattern is get_<noun> (get_features, get_labels, get_manifest, etc.), with two exceptions: find_similar (find_) and list_futures (list_). This is a small deviation but still follows a predictable verb-noun structure for retrieval, search, and enumeration actions.
14 tools is well within the ideal range for a quantitative data server. Each tool serves a distinct purpose, from basic data retrieval (features, labels) to advanced analytics (similarity, risk clusters) and user management (alerts, usage). No tool feels redundant or missing.
The toolset covers the core data access and analytics needs for factor-based market analysis: retrieval, search, market context, and backtesting labels. Minor gaps include no generic ticker search or list (beyond futures), and no direct way to browse available factors beyond documentation, but these can be worked around via get_top and get_manifest.
find_similarAFind historical (ticker, date) setups most similar to a query ticker today. Four similarity methods are available: cosine (default, all tiers) ranks by cosine similarity of 32-D regime-aware embeddings; label_aware (PRO+) restricts the backbook to dates in the same SPY volatility regime; supervised (QUANT) projects embeddings through a PLS regression fit on forward-return labels so neighbors are ones whose factor profile most-strongly-predicted realized returns; dtw (HOBBY+) cosine-shortlists then reranks by dynamic-time-warping distance over the rolling return window. Each returned neighbor row carries the analogue's factor row and forward-return labels at that historical (ticker, date) — pre-joined for honest backtests, no extra fetches needed. Use min_lookback_days=30 to filter out same-day correlated tickers. Pass conditioner=vx_term_structure (QUANT only) to additionally filter analogues to dates with a VIX-curve regime similar to today.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| method | No | Similarity method. Tier-gated: FREE=cosine; HOBBY=cosine+dtw; PRO=cosine+dtw+label_aware; QUANT=all four. | cosine |
| ticker | Yes | ||
| tolerance | No | Max |conditioner_query − conditioner_neighbor|. Only used when conditioner is set. | |
| conditioner | No | QUANT only. Filter analogues to dates with a similar regime conditioner value. Currently only vx_term_structure is supported. Limits: analogues older than 252 trading days are passed through unverified. | |
| min_lookback_days | No | Require neighbor_date to be at least this many days before query_date. Default 30 strips co-traded same-day ETFs. |
| Name | Required | Description |
|---|---|---|
| method | Yes | |
| neighbors | Yes | |
| tolerance | No | Echo of conditioner tolerance. |
| query_date | No | |
| conditioner | No | Present only when conditioner is requested (QUANT). |
| query_ticker | Yes | |
| conditioner_note | No | Notes about the conditioner filter — matched count, unverified count. |
| min_lookback_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses rich behavioral details: the inner workings of each method (e.g., PLS regression, dynamic-time-warping), tier restrictions, pre-joined return rows for honest backtests, and the 252-day pass-through limit for conditioner. These are substantial additions not present in annotations.
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 compact and every sentence earns its place: purpose, method distinctions, return contents, and usage tips. It is front-loaded with the core purpose and avoids any 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?
Given an output schema exists, the description needn't detail return structures. It comprehensively covers the tool's complexity: method selection, tier gates, output row contents, and parameter effects. The only omissions are pagination/error details, but these are minor and the description is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 6 parameters with 67% description coverage. The description adds significant meaning for method (explains all four variants), min_lookback_days (purpose of stripping co-traded ETFs), and conditioner (QUANT-only, filtering behavior). Ticker and limit remain intuitive but the description compensates well for the coverage gap.
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 opens with 'Find historical (ticker, date) setups most similar to a query ticker today,' a specific verb+resource+scope that clearly differentiates it from the sibling data-retrieval tools (e.g., get_embedding, get_features). The detailed method breakdown further reinforces its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear conditional guidance: 'Use min_lookback_days=30 to filter out same-day correlated tickers' and 'Pass conditioner=vx_term_structure (QUANT only) to additionally filter analogues...' It also implies a backtest use case. However, it does not explicitly state when to prefer this tool over alternatives 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_alertsAList active alert rules belonging to the current authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | |
| rules | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context about the 'current authenticated user' and 'active' filters, which goes beyond the annotations. However, it does not disclose pagination, limits, or other behavioral traits. With the annotations already declaring read-only, idempotent, and non-destructive behavior, the description adequately supplements but does not fully enrich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the verb and object. It contains no wasted words and is appropriately sized for the tool's simplicity.
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's simplicity (no parameters, output schema present, annotations covering safety), the description is complete. It captures the essential scope and filtering behavior, and the output schema handles return value details.
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 tool has zero parameters, so the baseline is 4. The description correctly implies there are no inputs to define, and the schema confirms this. No additional parameter context is needed.
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 uses a specific verb 'List' with a clear resource ('active alert rules') and a clear scope ('belonging to the current authenticated user'). It distinguishes itself from sibling tools by its unique resource focus.
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 clearly conveys that this tool is for the user's own alert rules, which implies when to use it. However, it does not explicitly define when not to use it or mention alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_embeddingAThe raw 32-D regime-aware factor-state embedding vector for a ticker — the representation the similarity search itself runs on. Build your own models / similarity on it. QUANT tier only.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| dim | No | Vector dimensionality (currently 32). |
| as_of | No | |
| ticker | Yes | |
| embedding | Yes | The raw factor-state embedding. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond that: the embedding's dimensionality (32-D), its regime-aware factor-state nature, and that it powers the similarity search. It also discloses the QUANT tier restriction, which is a form of access/authorization context.
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 sentences with no redundant wording. The first sentence front-loads the core output and its nature, while the second explains usage and access tier. Every word earns its place.
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 that the tool has a simple read-only operation with a single parameter and an output schema exists, the description covers the essential context: what the vector is, how it relates to similarity search, and who can use it. It does not mention rate limits or error handling, but annotations cover the safety profile, making the description sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'ticker', with no description (0% schema coverage). The description mentions 'for a ticker' which reinforces the parameter's role but adds no extra detail on format, validation, or accepted values. For a single, self-explanatory parameter, this is adequate but not exemplary.
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 what the tool does: it returns 'the raw 32-D regime-aware factor-state embedding vector for a ticker'. It distinguishes itself from siblings by noting it is the representation 'the similarity search itself runs on', differentiating it from find_similar and get_features. The intended use of building custom models/similarity is explicit.
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 clear context: this tool is for users who want to build their own models or similarity on the raw embedding. It also notes the access restriction 'QUANT tier only'. However, it does not explicitly state when to avoid this tool or mention alternatives like find_similar for pre-built similarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_featuresAGet factor row for a ticker. With no date arg, returns the most recent row. With date / start_date / end_date, returns the historical row(s) — useful for honest analogue-backtests (querying a setup as it was on a specific historical date, not as it looks today). History is the last 252 trading days. Stock/ETF = FREE+; futures = PRO+ (adds Open Interest features). PRO+ subscribers automatically get intraday-derived columns (overnight_ret, intraday_ret, or_high_30, or_low_30, or_breakout_pct, vwap, vwap_dev_close, intraday_rv, late_drift) on the stock row.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Single ISO date YYYY-MM-DD. Returns one row. | |
| ticker | Yes | Ticker symbol, e.g. AAPL or SPY | |
| end_date | No | Inclusive ISO end date for a range query. | |
| start_date | No | Inclusive ISO start date for a range query. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent and non-destructive, so the bar for extra credit is high. The description adds substantial beyond that: history window (252 trading days), pricing tiers (FREE+ vs PRO+), and exactly which intraday-derived columns appear for PRO+ subscribers. No contradictions with annotations.
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 front-loaded with the core purpose, then efficiently explains the date variants, access tiers, and PRO+ column additions. Each sentence carries meaningful information with no filler or repetition.
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's moderate complexity (4 params, output schema present), the description covers all critical non-schema context: default behavior, date range semantics, time window, access-tier differences, and derived features. The presence of an output schema means return-format details need not be restated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all four parameters with full coverage, so the baseline is 3. The description goes further by clarifying the default when no date is supplied ('returns the most recent row') and how date/start_date/end_date collectively produce historical rows, adding value beyond the individual parameter docs.
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 opens with a specific verb+resource ('Get factor row for a ticker') and then explains the variant behaviors (most recent vs historical rows). It distinguishes the tool from siblings like get_market_context or get_labels by focusing on factor rows and the analogue-backtest use case.
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?
It gives clear context for when to use date arguments ('useful for honest analogue-backtests') and describes the default no-date behavior. However, it does not explicitly mention when to prefer an alternative sibling tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_labelsAForward-return labels (1d/5d/20d) and binary targets for backtesting. PRO tier or higher.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| labels | Yes | |
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds the PRO tier access requirement, which is a critical behavioral constraint not captured in annotations. This additional context goes beyond what annotations provide, enhancing transparency.
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 short sentences, immediately stating the tool's output and access requirement. It is front-loaded with the most critical information and contains no filler 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?
Given the tool's low complexity (one parameter, no nested objects) and the presence of an output schema, the description is largely complete. It specifies the data provided, the horizons, and the tier requirement. A minor gap is the lack of detail on what exactly the binary targets represent, but the output schema likely covers 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 description coverage is 0%, and the description does not mention the 'ticker' parameter at all. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema documentation, leaving the agent without additional semantics or format details.
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 provides forward-return labels (1d/5d/20d) and binary targets for backtesting. This is a specific, resource-focused purpose that distinguishes it from sibling tools like get_features or get_market_context, which serve different data needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for backtesting' provides clear context on when to use this tool, implying it is for obtaining target labels in backtesting workflows. It does not explicitly exclude alternatives, but the context is sufficiently clear to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_manifestABundle metadata: latest_date, ticker_count, regime distribution. Public — no auth needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| files | No | |
| latest_date | No | Most-recent trading-day for which factor data is available. |
| generated_at | No | |
| ticker_count | No | |
| schema_version | No | |
| labels_history_days | No | |
| neighbor_shard_count | No | |
| features_history_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by disclosing that no auth is required, which annotations do not mention. It also previews the response fields. Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered; the description provides additional operational context.
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, front-loaded sentence: 'Bundle metadata: latest_date, ticker_count, regime distribution. Public — no auth needed.' Every word earns its place, and the most important information appears first.
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 this is a simple, no-parameter tool with an output schema available, the description fully conveys the tool's purpose and access requirements. It is complete for an agent to select and invoke correctly without further clarification.
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?
There are zero parameters, so the baseline for parameter semantics is 4. The description has nothing to add about inputs; no omission occurs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns bundle metadata, listing specific fields (latest_date, ticker_count, regime distribution). This distinguishes it from sibling getters like get_market_context or get_market_regime by focusing on an aggregate manifest rather than a specific data slice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Public — no auth needed' gives clear context on when this tool can be invoked without credentials, and listing the exact metadata fields implies use cases (e.g., checking bundle freshness or composition). However, it doesn't explicitly contrast with alternative tools or state exclusions, so a 4 fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_contextAWhole-universe derived market analytics: factor dispersion (10-90 percentile spreads of momentum / composite / RSI), breadth (% of the universe positive / overbought / oversold), and the current SPY-volatility regime with empirical next-day transition odds. FREE gets today's reading; HOBBY+ can also get the 252-day history (pass history=true).
| Name | Required | Description | Default |
|---|---|---|---|
| history | No | Include the 252-day history (HOBBY tier or higher). |
| Name | Required | Description |
|---|---|---|
| date | No | |
| regime | No | |
| breadth | No | Per-factor % positive / overbought / oversold. |
| history | No | 252-day history (HOBBY+ only). Each row carries the per-day cross-asset z-scores + vx_term_structure for charting. |
| dispersion | No | Per-factor 10–90 percentile spread. |
| cross_asset | No | DXY / VIX / VVIX / VIX9D / TNX / XAU / VX-continuous closes + 20d log-return z-scores, plus vx_term_structure = (VX_continuous − VIX_cash) / VIX_cash. |
| regime_transition_odds | No | Empirical next-day regime-transition probabilities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds valuable context beyond that: the FREE vs HOBBY+ tier restriction, the history boolean parameter behavior, and the 'empirical next-day transition odds' detail. This gives a richer picture of what the tool returns and under what conditions, without contradicting annotations.
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 compact and well-organized: one sentence catalogs the analytics, and a second sentence explains tiered access. No wasted words; every phrase earns its place. The structure is front-loaded with the defining purpose before procedural details.
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 tool has a single simple parameter, an output schema, and no nested objects. The description covers what data is returned, the tier constraints, and the history option. For a read-only analytics tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the history parameter already described. The description adds the contrast between FREE (today's reading) and HOBBY+ (history) and explicitly mentions 'pass history=true', which clarifies the parameter's effect in context. This goes slightly beyond the schema by tying the parameter to the tier system.
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 provides whole-universe derived market analytics, enumerating the specific metrics (factor dispersion, breadth, SPY-volatility regime). This differentiates it from siblings like get_market_regime and get_vx_term_structure, which focus on other aspects. The scope and content are explicit.
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 gives clear context on what the tool does and includes tier-based guidance: FREE gets today's reading, HOBBY+ can also get history. It doesn't explicitly compare to alternatives, but the unique metrics make the intended use clear. No exclusions or alternative tools are named, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_regimeACurrent SPY-realized-volatility regime classification (low/mid/high) and recent regime history for context.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
| Name | Required | Description |
|---|---|---|
| today | No | |
| history | No | |
| distribution | No | low/mid/high → count in the window |
| history_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about the output (current regime and history) but no additional behavioral traits such as data source or computation method, so it adds only minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the primary output ('current SPY-realized-volatility regime classification') and adding the history note.
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 read-only tool with an output schema and strong annotations, the description is mostly adequate, but it lacks explicit parameter documentation and does not differentiate from sibling tools. The absence of any reference to the 'days' parameter in the description leaves a small but real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains a single 'days' parameter with no description (0% coverage). The description mentions 'recent regime history' which hints that 'days' controls the history length, but does not explicitly state its meaning, use, or constraints, leaving the agent to infer the link.
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 identifies the tool's function: producing a SPY realized-volatility regime classification (low/mid/high) plus recent history. This differentiates it from sibling tools like get_market_context or get_vx_term_structure by focusing specifically on SPY volatility regimes.
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 gives a clear sense of when to use the tool (when you need SPY volatility regime and recent history), but it does not mention alternatives or exclusions, so it falls short of explicitly guiding selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_report_cardAPer-ticker derived digest: factor snapshot, cross-sectional percentile ranks, risk-cluster tag, current market regime, and an unusualness score (z-score of today's factor state vs the ticker's own 252-day history). HOBBY tier or higher; the risk-cluster block requires PRO.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| as_of | No | |
| ranks | No | Cross-sectional percentile ranks per factor. |
| regime | No | |
| ticker | Yes | |
| snapshot | No | |
| risk_cluster | No | |
| unusualness_score | No | Z-score of today's factor state vs the ticker's own 252-day history. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds the derivation methodology (z-score vs 252-day history) and access tier restrictions for specific blocks, which is useful context beyond annotations.
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?
One dense sentence that packs all key components plus a second sentence for tier limits. Efficient, but the first sentence is a long list; still, each element adds specificity.
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?
Covers what the digest contains, the unusualness score formula, and access constraints. Output schema exists, so return format is handled elsewhere. Missing discussion of interpretation or edge cases, but sufficient for selection.
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 only has 'ticker' as a required string with no description. The description clarifies that the parameter is the ticker symbol ('per-ticker', 'today's factor state vs the ticker's own history'), adding meaning despite zero schema coverage.
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 this as a per-ticker digest with specific components (factor snapshot, percentile ranks, risk-cluster, market regime, unusualness score). It distinguishes from sibling tools like get_market_regime or get_risk_cluster by presenting this as a combined derived digest.
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?
Provides concrete tier requirements (HOBBY tier or higher; risk-cluster block requires PRO) but doesn't compare explicitly to sibling tools or state when to prefer this over them. Context implies usage for a quick per-ticker summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_risk_clusterAThe volatility regime a ticker's factor analogues historically landed in — calm / normal / stressed — derived from the realized forward volatility of its cosine neighbours. A risk-coherence / screening signal, NOT a volatility forecast. PRO tier or higher.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| as_of | No | |
| ticker | Yes | |
| cluster | Yes | |
| confidence | No | 0–1 confidence. |
| realized_vol_fwd_20d | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context: it is historical, derived from realized forward volatility of cosine neighbours, and yields discrete regime labels. This explains what the tool computes and its limitations without contradicting annotations.
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: three sentences covering definition, derivation, categories, usage positioning, and tier requirement. Every sentence adds value and there is no filler 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?
With an output schema present and annotations covering safety, the description sufficiently explains the tool's purpose, methodology, and non-forecast nature. It also notes the PRO tier access requirement. Minor omissions like edge cases or return envelope details are likely covered by the output schema, so the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'ticker' with no description (0% schema coverage). The description mentions 'a ticker's factor analogues,' which clarifies the parameter's purpose, but it doesn't specify ticker format, accepted values, or case sensitivity. It partially compensates for the schema gap but could be more explicit.
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 precisely identifies the output as a volatility regime (calm/normal/stressed) for a ticker's factor analogues, including the derivation method. It explicitly distinguishes itself from a volatility forecast, which separates it from sibling tools like get_market_regime.
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 positions the tool as a risk-coherence/screening signal and explicitly states what it is not ('NOT a volatility forecast'), providing some usage context. However, it doesn't name alternative tools or give explicit when-to-use vs when-not-to-use guidance, so usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topATop-N tickers ranked by a factor on the latest available date. Common factors: mom (momentum), meanrev, comp_score, rsi, z_52w, beta_spy.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| factor | No | mom | |
| direction | No | desc |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| factor | Yes | |
| direction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the 'latest available date' constraint, which is useful behavioral context. However, it does not discuss edge cases like invalid factors or data availability, but with annotations covering safety, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the core purpose, and the second lists factor values. No fluff or redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return format is defined elsewhere. The description covers the tool's core behavior and the most ambiguous parameter (factor). It's complete for a simple query tool, though it could mention what happens if fewer than N tickers exist, but that's a minor gap.
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 the description must compensate. It does for the 'factor' parameter by listing common examples (mom, meanrev, etc.). The 'n' and 'direction' parameters are self-explanatory from their types and defaults, so no extra description needed. This is a solid improvement over the bare 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 the tool returns Top-N tickers ranked by a factor on the latest available date, which is a specific verb+resource+scope. It distinguishes from siblings like get_alerts or get_features by focusing on ranking by factor. The list of common factors adds specificity.
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: use when you want a ranked list of top tickers by a factor. It clarifies context without explicit exclusions or naming alternative tools. No sibling directly competes, so the guidance is adequate but lacks an explicit 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageACurrent daily/monthly API usage and tier limits for the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| mtd | No | Month-to-date usage. |
| tier | No | |
| today | No | |
| daily_quota | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context: the data is scoped to the authenticated user, and it covers daily/monthly periods and tier limits. This goes beyond the annotations and clarifies the snapshot nature of the resource.
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 that front-loads the key information. Every word contributes meaning; there is no redundancy or filler. It is appropriately sized for the tool's simplicity.
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 no parameters, strong annotations, and an output schema (which defines return values), the description is complete enough. It tells the user what the tool provides without needing to explain return formats or parameter handling. The scope and granularity are clearly stated.
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 tool has zero parameters, and the schema coverage is 100% (no parameters to document). Baseline for 0 params is 4. The description adds no parameter-specific semantics, which is appropriate since there are none to explain.
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's resource: 'Current daily/monthly API usage and tier limits for the authenticated user.' It distinguishes from sibling tools, none of which mention usage or quota, and implies the 'get' action through the tool name. This is a specific, unambiguous statement of what the tool returns.
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 you need the authenticated user's API usage and tier limits, this is the tool. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The context is clear but 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.
get_vx_term_structureAVIX futures contango/backwardation read: (VX_continuous − VIX_cash) / VIX_cash. Negative = backwardation (near-term realized vol > expected forward vol — classic stress / vol-panic signal). Positive = contango (term structure normal, calm regime). Pass history=true (HOBBY+) for the 252-day series for charting. Single-number version of the vol-curve regime that traders watch every day.
| Name | Required | Description | Default |
|---|---|---|---|
| history | No | Include the 252-day history (HOBBY tier or higher). |
| Name | Required | Description |
|---|---|---|
| as_of | No | |
| regime | Yes | |
| history | No | 252-day history (HOBBY+ only). |
| vx_close | No | |
| vix_close | No | |
| vix9d_close | No | |
| vx_term_structure | Yes | (VX_continuous − VIX_cash) / VIX_cash. Negative = backwardation; positive = contango. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context: the formula, the sign interpretation, and the tier requirement (HOBBY+) for history. It also clarifies that the default returns a single number, aligning with the histogram parameter.
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 and well-structured: it opens with the core formula, then explains the two states (negative/positive) with their market implications, and ends with the optional parameter. Every sentence contributes value, and the formatting makes it easy to parse.
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 existence of an output schema, the description does not need to detail return types. It sufficiently covers what the tool computes, how to interpret the result, and the parameter behavior. The tier limitation is also disclosed, making the context complete for agent 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 100% for the single 'history' parameter, which already includes its description. The description adds extra usefulness by specifying that history is for charting and uses 'HOBBY+' shorthand, which complements the schema's 'HOBBY tier or higher' phrasing. This gives slightly more contextual meaning.
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 defines the tool's purpose as providing a VIX futures contango/backwardation read, with the exact formula and interpretation. It distinguishes itself from siblings like get_market_regime or get_market_context by specifically targeting the VIX term structure.
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 gives clear context on when the metric is meaningful (positive=calm, negative=stress/vol-panic) and how to request history for charting. It does not explicitly mention alternative tools or when not to use it, but the context is strong enough for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_futuresAList the top-30 futures contracts that have per-ticker factor decomposition available. Returns ticker, the asset family (equity-index / energy / metals / rates / fx / crypto), and the latest snapshot (close, mom, rsi, oi_z20, oi_vol_ratio, comp_score). PRO tier or higher for the snapshot block; ticker list itself is FREE. Use the returned tickers with get_features to pull the full factor row (e.g. get_features(ticker="VX") for the VIX futures continuous contract).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| tickers | Yes | |
| snapshot_locked | No | true for non-PRO tiers — snapshot fields are absent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive traits. The description adds valuable context about tier-based data availability (PRO for snapshot, free for tickers) and the exact output fields. This goes beyond the annotations without contradicting them, though it could mention sorting or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core functionality and output, the second provides usage guidance and an example. Every sentence earns its place, and the purpose is front-loaded in the first sentence. No fluff 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?
For a zero-parameter tool with an output schema and annotations, the description is exceptionally complete. It covers purpose, output fields, access tiers, and downstream usage with get_features. The example with VX clarifies the intent. There are no significant gaps given the tool's simplicity.
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 tool has zero parameters, so the description correctly provides no parameter details. The schema is empty and needs no additional explanation. The baseline for 0 params is 4, and the description appropriately avoids superfluous parameter information.
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 lists the top-30 futures contracts with per-ticker factor decomposition, specifies the returned fields (ticker, asset family, snapshot), and distinguishes from siblings by explicitly linking to get_features. The verb 'List' and resource 'futures contracts' are specific and unambiguous.
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 gives explicit usage guidance by telling users to use the returned tickers with get_features, including a concrete example. It also notes the PRO tier requirement for the snapshot, implying when a user might only need the free ticker list. While it doesn't mention every alternative sibling, the guidance is clear and actionable.
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.
No comments yet. Be the first to start the discussion!
