FactorWeave
Server Details
A quant-factor brain for your AI — factor scores, similarity search, and risk-coherence analogues for 14,684 tickers across 6 asset classes
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 14 of 14 tools scored.
Each tool has a clearly distinct purpose. For example, get_features returns factor rows, get_labels returns forward-return labels, find_similar performs similarity search, and get_market_context provides broad market analytics. No two tools overlap; even get_report_card and get_risk_cluster are distinct (digest vs. standalone risk signal).
Most tools follow the 'get_' prefix pattern (e.g., get_features, get_alerts), which is consistent and clear. Two tools deviate: find_similar and list_futures, but they use different descriptive verbs. The naming is all lowercase snake_case and readable, with only minor inconsistencies.
14 tools are well-scoped for a financial factor analysis API. Each tool serves a specific function without redundancy, covering data retrieval, similarity search, market context, alerts, and usage. The count is neither too few nor excessive for the domain.
The tool surface covers the full lifecycle of factor-based analysis: raw data (get_features, get_labels, get_embedding), similarity search (find_similar), market context (get_market_context, get_market_regime, get_vx_term_structure), risk assessment (get_risk_cluster), top tickers (get_top), and user utilities (get_alerts, get_usage). There are no obvious gaps for the stated purpose.
Available Tools
14 toolsfind_similarARead-onlyIdempotentInspect
Find 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. |
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing that returned rows include factor row and forward-return labels pre-joined for honest backtests, and explains tier-gating for methods. Annotations already indicate readOnly, idempotent, and non-destructive behavior, which the description aligns with.
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, and every sentence adds value. However, it is somewhat lengthy due to detailed method explanations; a slightly more concise version could improve readability without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, multiple methods, tier gating) and the existence of an output schema, the description covers methods, tier access, parameter usage, and output content thoroughly. It leaves no major gaps for an agent to understand how to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to parameters by explaining methods, tier restrictions, and the conditioner parameter (e.g., 'QUANT only'). While schema description coverage is high, the description enriches understanding of how parameters interact and their use cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find historical (ticker, date) setups most similar to a query ticker today.' It specifies the action (find similar) and the resource (historical setups), and distinguishes from siblings by detailing four similarity methods.
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 explicit guidance on when to use each method (e.g., 'cosine (default, all tiers)', 'label_aware (PRO+)'), and advises on parameters like min_lookback_days and conditioner. It does not explicitly state when not to use the tool, but the context and method tier-gating offer clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_alertsARead-onlyIdempotentInspect
List active alert rules belonging to the current authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| rules | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds context: 'active' alerts and 'current user' scope, which are not 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?
A single clear sentence with no fluff. 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?
Tool is simple with zero params and an output schema (not shown but confirmed). Covers what, scope, and status. Could mention ordering, but output schema likely handles 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?
The input schema has no parameters, so the description doesn't need to add param info. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'active alert rules' with scope 'current authenticated user'. It distinguishes from siblings like get_features or get_labels.
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 is functional but provides no guidance on when to use vs alternatives or any prerequisites. For a zero-parameter list tool, it's adequate but could be improved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_embeddingARead-onlyIdempotentInspect
The 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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| dim | No | Vector dimensionality (currently 32). |
| as_of | No | |
| ticker | Yes | |
| embedding | Yes | The raw factor-state embedding. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds value by specifying the output is a raw 32-D vector and explaining its nature (regime-aware factor-state). It does not contradict 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?
Three sentences with no wasted words. Key information (dimensionality, type, purpose, tier restriction) is front-loaded. The structure is efficient and 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 simple interface (one parameter) and presence of annotations and output schema, the description adequately covers the embedding's purpose and usage. The 'QUANT tier only' note adds important context. Minor gaps remain about interpreting the vector, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter description), and the description only mentions 'for a ticker,' which adds little beyond the parameter name. It does not explain ticker format, required patterns, or any restrictions.
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 specifies that the tool returns a raw 32-D regime-aware factor-state embedding vector for a ticker, and distinguishes it from sibling tools by highlighting that it is the representation used in similarity search and intended for custom modeling. The phrase 'QUANT tier only' 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 provides usage guidance by stating 'Build your own models / similarity on it,' implying this tool is for custom similarity rather than using the pre-built find_similar. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_featuresARead-onlyIdempotentInspect
Get 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: data history limited to 252 trading days, subscription-dependent column availability. No contradictions.
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 main action and provides necessary details in a logical order. It is slightly lengthy but every sentence adds value; minor redundancy could be removed.
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 an output schema exists, the description appropriately focuses on usage context, date behavior, and subscription requirements. It covers key aspects but could mention typical columns returned for completeness.
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%, and the description enhances parameter understanding by explaining the effect of date parameters (single date vs. range, default behavior). This goes beyond the schema's basic type and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get factor row for a ticker,' specifying the verb and resource. It distinguishes this tool from siblings (e.g., get_market_context, get_top) by focusing on factor rows.
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 explicit usage scenarios: no date arg returns most recent row; with date args returns historical rows useful for backtests. Subscription tiers are also specified, though no explicit alternatives or when-not-to-use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_labelsARead-onlyIdempotentInspect
Forward-return labels (1d/5d/20d) and binary targets for backtesting. PRO tier or higher.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| labels | Yes | |
| ticker | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds that it returns forward-return labels and binary targets, consistent with annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. Could include parameter details but overall efficient.
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 values are covered. Description adequately states data type and tier, but lacks parameter description, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'ticker' has no schema description (coverage 0%). Description does not explain the ticker parameter or its expected format, despite low 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?
Description clearly states 'Forward-return labels (1d/5d/20d) and binary targets for backtesting.' Identifies specific resource (labels) and action (get). Distinct from sibling tools like get_features or 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?
Mentions 'PRO tier or higher,' providing a condition for use. However, no explicit guidance on when to use this 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_manifestARead-onlyIdempotentInspect
Bundle metadata: latest_date, ticker_count, regime distribution. Public — no auth needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that the tool is public and requires no auth, which provides useful behavioral context beyond annotations. No contradictions.
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?
Description is only two brief phrases, conveying essential information (what it returns and access requirements) with no unnecessary words.
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?
Description is adequate given the tool has no parameters and an output schema exists. It tells the agent what it gets and that it's public. Minor gap: could mention it returns an object or reference the output schema.
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?
Tool has zero parameters and schema coverage is 100% (empty object). Description adds no parameter info, but none is needed. Baseline for 0 params is 4, but here it's exceptionally well-handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides bundle metadata with specific fields (latest_date, ticker_count, regime distribution). It uses the verb 'Bundle metadata' implying retrieval, but doesn't explicitly state it's a read operation. The resource is clear.
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?
Description indicates the tool is public and requires no authentication, which provides basic usage context. However, it does not mention when to use this tool versus siblings like get_top or get_market_context, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_contextARead-onlyIdempotentInspect
Whole-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). |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral details like empirical next-day transition odds and tier restrictions, which go beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the most important information (what it provides), followed by tier details. No wasted words.
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 annotations, parameter schema coverage, and presence of an output schema, the description is complete. It explains what the tool returns, tier restrictions, and how to get history.
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 parameter 'history', and the description essentially repeats the schema's description. It adds tier context (HOBBY+), but no new semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides whole-universe derived market analytics including specific metrics like factor dispersion, breadth, and volatility regime. It distinguishes from siblings like get_market_regime by listing distinct outputs, though it does not explicitly contrast with alternatives.
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 explicit tier-based usage guidance (FREE vs HOBBY+ with history parameter). Does not include when not to use or direct alternatives, but the context is clear for a read-only analytics tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_regimeARead-onlyIdempotentInspect
Current SPY-realized-volatility regime classification (low/mid/high) and recent regime history for context.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| today | No | |
| history | No | |
| distribution | No | low/mid/high → count in the window |
| history_days | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds specific output format (low/mid/high) and history context, which is useful 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?
Single sentence with 16 words, front-loads the main purpose. No wasted words.
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 values are covered. However, parameter semantics are incomplete; tool is simple but missing explicit param explanation keeps it from perfect.
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 has 0% description coverage and description does not explain the 'days' parameter. Agent may not know that 'days' controls history length, as description only mentions 'recent regime history' vaguely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns SPY realized volatility regime classification (low/mid/high) and recent history. Differentiates from sibling tools like find_similar or get_features.
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?
Implied usage for obtaining market regime, but no explicit guidance on when to use vs alternatives or when not to use. No mention of complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_report_cardARead-onlyIdempotentInspect
Per-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 |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context by listing specific digest components and tier restrictions, providing useful transparency 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?
Two sentences: the first lists key outputs, the second states tier requirements. No waste, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and existing output schema, the description adequately covers purpose, components, and access tiers. Minor omission: no explicit mention that output is in JSON or similar.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'ticker' parameter. The description only implies ticker is a stock symbol via 'Per-ticker,' but does not define format or constraints, insufficiently compensating for the schema 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 clearly states it provides a per-ticker derived digest including factor snapshot, percentile ranks, risk-cluster tag, market regime, and unusualness score, distinguishing it from sibling tools that likely return individual components.
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 mentions tier requirements (HOBBY/PRO) but does not explicitly guide when to use this tool versus alternatives like get_market_regime or get_risk_cluster.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_risk_clusterARead-onlyIdempotentInspect
The 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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| as_of | No | |
| ticker | Yes | |
| cluster | Yes | |
| confidence | No | 0–1 confidence. |
| realized_vol_fwd_20d | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe and deterministic. The description adds derivation context (realized forward volatility of cosine neighbours), enhancing transparency 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 two sentences, front-loading purpose and adding relevant context. No superfluous information, though structure could be slightly improved with bullet points.
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 output schema exists (not shown) and the tool has one simple parameter, the description sufficiently explains the output categories and derivation methodology. It could be more exhaustive but meets needs.
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 single required parameter 'ticker' has 0% schema description coverage. The description refers to 'a ticker's factor analogues', implying it's a stock symbol, but does not provide format or examples. Baseline 3 is appropriate given the parameter's simplicity.
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 the volatility regime (calm/normal/stressed) for a ticker's factor analogues, using specific verbs like 'landed in'. It distinguishes itself from siblings by noting it's a risk-coherence/screening signal and not a volatility forecast.
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 specifies access level ('PRO tier or higher') and clarifies it is NOT a volatility forecast, guiding appropriate use. However, it does not explicitly compare to similar tools like get_market_regime.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topARead-onlyIdempotentInspect
Top-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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| factor | Yes | |
| direction | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that it uses the latest available date and lists common factors, providing 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?
The description is a single sentence followed by a list of common factors. It is efficient, front-loaded, and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. The description explains the ranking basis and provides factor examples. It is mostly complete, though it could clarify what 'latest available date' means and how the factor ranking works.
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 should compensate. It only gives examples for the factor parameter but does not explain the 'n' or 'direction' parameters, leaving the agent without full understanding of their roles.
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 date, with a list of common factors. This provides a specific verb and resource, distinguishing it from sibling tools.
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 use for ranking tickers by factor but does not explicitly state when to use versus alternatives, nor any exclusions. It provides factor examples but lacks guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageARead-onlyIdempotentInspect
Current daily/monthly API usage and tier limits for the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| mtd | No | Month-to-date usage. |
| tier | No | |
| today | No | |
| daily_quota | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds only that data is for the authenticated user, which is minor 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?
A single, 12-word sentence that is front-loaded and concise. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present) and annotation coverage, the description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. With zero params, the baseline is 4.
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 specifies 'current daily/monthly API usage and tier limits for the authenticated user,' which clearly identifies the resource (usage/quota) and action (get). It distinctly differs from siblings like 'get_alerts' or 'get_embedding'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vx_term_structureARead-onlyIdempotentInspect
VIX 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). |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds value by explaining the output interpretation and optional history series. No contradictions; behavioral traits are well-disclosed.
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?
Concise, front-loaded with formula, covers positive/negative cases, and parameter guidance in few sentences without 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 simple one-parameter tool with output schema, description fully explains purpose, parameter effect, output meaning, and interpretation. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for history. Description adds tier requirement (HOBBY+) and use case (charting), going beyond schema. Baseline 3 is exceeded due to added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly defines the metric formula (VX_continuous - VIX_cash)/VIX_cash, explains negative/positive values as backwardation/contango signals, and positions it as a single-number vol-curve regime indicator. It is specific with verb 'read' and resource 'VIX futures term structure', distinguishing it from siblings 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?
Provides clear context for when to use (e.g., for contango/backwardation signal) and explains parameter usage for history. Lacks explicit comparison to sibling tools or when-not-to-use, but the focus on VIX term structure implicitly guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_futuresARead-onlyIdempotentInspect
List 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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| tickers | Yes | |
| snapshot_locked | No | true for non-PRO tiers — snapshot fields are absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds details about the output fields and access tiers, providing context beyond annotations. No contradictions.
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, concise, and front-loaded with the core action. No unnecessary words.
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), the description fully covers what it does, the output, usage pattern, and access tiers. It is complete for its context.
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 no parameters (schema empty), so the baseline is 4. The description does not need to clarify parameters.
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 top-30 futures contracts with factor decomposition, specifies the output fields, and distinguishes it from sibling tools like get_features. The verb 'list' is specific and the resource is well-defined.
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 explicit guidance on using the returned tickers with get_features and mentions tier access restrictions (PRO for snapshot, FREE for ticker list). It lacks an explicit when-not-to-use, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!