crashtestyourstrategy
Server Details
Portfolio and strategy stress diagnostics with hedge-break detection and regime outlook. Free tier.
- 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.3/5 across 15 of 15 tools scored. Lowest: 3.7/5.
Most tools have clearly distinct purposes, but there is some overlap among stress-related tools (e.g., portfolio_stress_test, run_stress_test, long_horizon_stress) that could cause confusion despite descriptive details.
The majority of tools follow a verb_noun pattern with underscores (e.g., backtest_integrity, find_similar_regime), but a few deviate such as 'ips_gate' (noun_noun) and 'long_horizon_stress' (adjective_noun_noun).
15 tools is well-scoped for the domain of investment strategy analysis, covering backtest integrity, regime analysis, stress testing, and portfolio comparison without being excessive.
The tool set lacks support for custom strategies and portfolios beyond the fixed universe (only 'buy_and_hold' is supported), and there are no create/update/delete operations for theses or portfolios, leaving notable gaps.
Available Tools
15 toolsbacktest_integrityBacktest integrity check (deflated Sharpe + regime coverage)AInspect
Confront a backtest claim with its over-optimism failure modes before trusting it. Given an annualized Sharpe + the number of configurations tried + the backtest window (YYYY-MM-DD), returns: the DEFLATED Sharpe — the expected MAXIMUM Sharpe achievable by chance grows with the trial count, so a high in-sample Sharpe is a selection artifact (Bailey & López de Prado); which CRISIS REGIMES were ABSENT from the backtest window (untested, from the historical-anchor catalogue); and a base-rate caveat. If the trial count is unknown — the usual case for an agent reasoning from a backtest — the Sharpe is flagged as not-deflatable / UNPROVEN. All inputs optional; supply as many as known. Descriptive, not advisory.
| Name | Required | Description | Default |
|---|---|---|---|
| kurt | No | ||
| skew | No | ||
| asset | No | ||
| n_trials | No | ||
| frequency | No | ||
| backtest_end | No | ||
| backtest_start | No | ||
| annualized_sharpe | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the methodology (Bailey & López de Prado), the outputs, and the behavior when inputs are missing (flagging as 'not-deflatable'). It does not mention any destructive actions or side effects, which is appropriate for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences) and front-loads the main purpose. It could be slightly more structured (e.g., separating input vs. output descriptions), but it remains efficient and informative.
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 and 8 optional parameters, the description explains the core functionality and outputs well. It mentions the deflated Sharpe, regime coverage, and base-rate caveat. The output schema exists, reducing the need to detail return values, but the description still gives a good overview. Minor gap: missing explanation for kurt, skew, asset, frequency.
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 covers the four key inputs (annualized_sharpe, n_trials, backtest_start, backtest_end) and states that all inputs are optional. However, it does not explain the remaining four parameters (kurt, skew, asset, frequency) from the schema. With 0% schema description coverage, the description should provide more detail on these 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's purpose: to confront a backtest claim with over-optimism failure modes. It specifies the outputs (deflated Sharpe, crisis regimes absent, base-rate caveat) and distinguishes itself from sibling tools like challenge_strategy or portfolio_stress_test by focusing on backtest integrity.
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 explains the required inputs (annualized Sharpe, trial count, backtest window) and notes the case when trial count is unknown. It states the tool is 'descriptive, not advisory.' However, it does not explicitly compare to sibling tools or state when not to use it, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
challenge_strategyChallenge a strategy: find what breaks it (3-layer output)AInspect
Adversarial-evaluation primitive — the semantic integration layer of the platform. Given a strategy identifier, returns a 3-layer analysis: (1) outcome metrics in the worst regimes the strategy was evaluated against, (2) vulnerability profile in the 8-dimension strategy vulnerability ontology with severity classification, (3) descriptor attribution showing which regime descriptors most strongly couple to the strategy's failure. v1 supports only 'buy_and_hold' (the outcome matrix is built once per strategy); future versions will support arbitrary strategy specs once the parser-driven strategy backtest pipeline is wired in. Read ontology://strategy-vulnerabilities for the vulnerability vocabulary.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_id | No | buy_and_hold |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is read-only (no destructive hints) and that the outcome matrix is built once per strategy (hinting at caching). Without annotations, it covers key behavioral traits but could be more explicit about statefulness or side effects. The three-layer output structure is well described, but parameter behavior beyond the default value is not detailed.
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 front-loaded with the core purpose. The two sentences efficiently convey the main functionality, output structure, and current limitations, with no wasted words. The reference to an ontology is appropriately placed as a footnote.
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 single-parameter input and the existence of an output schema (which covers return values), the description is fairly complete. It explains the tool's purpose, output layers, and current version constraints. Minor gaps include lack of error handling information for unsupported strategy IDs.
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 0% coverage, so the description carries the full burden. It clarifies that the parameter is a 'strategy identifier' and explicitly states that v1 only supports 'buy_and_hold', adding significant meaning beyond the bare schema. However, it does not specify the format or validation rules for the identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an 'adversarial-evaluation primitive' with a specific verb-verb structure ('challenge a strategy'). It explicitly lists the three layers of output (outcome metrics, vulnerability profile, descriptor attribution), distinguishing it from sibling analysis tools that focus on other aspects like regime description or factor decomposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adversarial evaluation of strategies but does not provide explicit guidance on when to use this tool versus alternatives like 'backtest_integrity' or 'factor_decomposition'. It mentions the current limitation to 'buy_and_hold' and refers to an ontology for vocabulary, but lacks direct 'when-not' or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_regimeDescribe one regime — self-portraitAInspect
Single-regime introspection: returns the median behavioural descriptors of a known regime, the z-scores vs the catalogue population (so you can see what makes THIS regime distinct from the average), an English characterisation generated from the most extreme descriptors, and the top 2 nearest neighbours as a preview. Complements find_similar_regime: that tool ranks neighbours of a target, this tool tells you what a single regime IS. Read this before searching if you want to reason about one regime first.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_hint | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lists all returned items: median descriptors, z-scores, English characterisation, top 2 nearest neighbours. Implies read-only introspection. No annotations provided, so description covers behavioral traits adequately. Minor gap: doesn't mention what happens if regime not found.
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, front-loaded with purpose. Each sentence adds distinct value: outputs, comparison to sibling, usage advice. Slightly verbose in first sentence 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?
Given the complexity of the tool (multiple return types), the description provides a good overview. Output schema exists, so details of return structure are not necessary. Usage context is clear. Missing parameter explanation reduces completeness slightly.
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?
Description does not explain the single required parameter 'profile_hint'. Schema has 0% description coverage, so the description should clarify what profile_hint represents (e.g., regime identifier). Without this, the agent may not know how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs single-regime introspection, returning median descriptors, z-scores, English characterisation, and nearest neighbours. It distinguishes itself from find_similar_regime, which ranks neighbours, by focusing on what a single regime 'is'.
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?
Explicitly tells when to use this tool vs find_similar_regime: 'Read this before searching if you want to reason about one regime first.' Advises to use this before the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
factor_decompositionFactor / concentration decomposition (capital weight vs risk)AInspect
Reveal HIDDEN risk concentration: a portfolio can be capital-diversified while its RISK is dominated by one factor. Returns the Euler risk-contribution decomposition (RC_i = w_i*(Sigmaw)_i / w'Sigmaw, summing to 1) alongside the capital weights, using the empirical covariance of real returns. For this universe each asset proxies a factor (SPY=equity-beta, TLT=duration, GOLD=real-asset, BTC=crypto). E.g. a 60/40 is ~83% equity risk; a 50/50 SPY/BTC is ~86% BTC risk despite 50/50 capital. Descriptive, not advisory.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that it uses empirical covariance, proxies factors, and includes the mathematical formula. It clearly states limitations ('descriptive, not advisory').
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 purpose and value, followed by technical details and examples. Each sentence adds value, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain returns. It covers the concept, formula, and examples thoroughly, making it complete for a moderately complex 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?
Schema coverage is 0%, and the description does not explicitly detail the 'holdings' parameter format. However, examples imply it expects asset symbols and weights. This partially compensates but leaves ambiguity.
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 explicitly states the tool reveals hidden risk concentration using Euler decomposition, with clear examples distinguishing it from capital weights. It effectively differentiates 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 provides explicit use cases (e.g., 60/40 portfolio) and states it's descriptive, not advisory. However, it lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_regimeFind similar regime via behavioural descriptorsAInspect
Nearest-neighbour retrieval over the cached regime catalogue. Provide EITHER a reference_profile_hint (use that bundle's median descriptors as target) OR a descriptor_target dict (partial spec, missing dimensions are ignored — only the provided ones contribute to distance). Optional asset_filter restricts to one asset. Returns top_n matches with similarity_score (0..1), euclidean distance in z-score space, and per-descriptor signed deltas so the agent can see WHY a regime matched. Read ontology://regime-descriptors for the descriptor definitions, and regimes://descriptors for the full catalogue.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| asset_filter | No | ||
| descriptor_target | No | ||
| reference_profile_hint | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool performs retrieval, returns top_n matches with similarity_score, euclidean distance, and per-descriptor signed deltas, and explains that missing dimensions are ignored. No behavioral surprises are left.
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 four concise sentences, with the main action front-loaded. Every sentence adds value, and there is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two input modes, filters, rich output), the description covers essential aspects: retrieval method, input options, output fields, and references for further definitions. It implicitly assumes mutual exclusivity of the two input parameters, which is acceptable.
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?
Despite 0% schema description coverage, the description adds significant meaning: it clarifies that descriptor_target accepts a partial spec with ignored missing dimensions, reference_profile_hint uses median descriptors, and asset_filter restricts to one asset. This compensates well for the schema's lack of description.
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 performs 'nearest-neighbour retrieval over the cached regime catalogue', specifying the verb 'find similar regime' and the resource 'regime catalogue'. This effectively distinguishes it from sibling tools like describe_regime or regime_outlook.
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 explains two mutually exclusive input modes (reference_profile_hint or descriptor_target) and an optional asset_filter, guiding the agent on how to use the tool. It does not explicitly list when not to use it or suggest alternatives, but the guidance is clear for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dossierGet dossier (audit trail of past diagnostics)AInspect
Compile recorded diagnostic responses into ONE citable record — a proper process documents itself. Every envelope response (MCP and REST) is recorded automatically, keyed by its request_id. Provide explicit request_ids (compiled chronologically) or last_n for the most recent entries. Returns the entries with their gate signals (revision_required + grounding_summary each) plus a ready-to-cite markdown document; revision_required on the dossier itself flags workflows containing unaddressed gate signals. Single verbatim entries: GET /api/v1/dossier/{request_id} on the REST surface. A factual record, not an assessment — descriptive, never advisory.
| Name | Required | Description | Default |
|---|---|---|---|
| last_n | No | ||
| request_ids | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full burden. It discloses return components (gate signals, markdown document) and states the tool is 'descriptive, never advisory', implying read-only behavior. Could mention permissions or side effects, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. Each sentence adds value, though it could be slightly more concise without losing clarity.
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 presence of an output schema (indicating return structure), the description covers usage, parameter options, output components, and the tool's factual nature. No gaps identified for a tool with 2 optional parameters.
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?
With 0% schema description coverage, the description compensates fully by explaining both parameters: request_ids (explicit IDs, compiled chronologically) and last_n (most recent entries). It adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compiles diagnostic responses into a single citable record and mentions automatic recording by request_id. However, it does not explicitly differentiate from sibling tools like 'get_investment_thesis' or 'describe_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 explains how to use the tool by providing request_ids or last_n, and references the REST API for single entries. It lacks explicit exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_investment_thesisGet one investment thesis (full case study)AInspect
Return the complete thesis for slug: the economic framework (pillars with [E]/[M]/[K] evidence grades, falsifiers and a deep-dive), the rule-based portfolio (asset blocks × conservative/balanced/offensive weights + sizing rationale), and the stress evidence (per-tier backtest, per-regime median drawdown, real historical episodes, pre-registered claim verdicts, and the hedge hold/break behaviour). This is the 'instant portfolio with all tested attributes'. Discover slugs with list_investment_theses(). Descriptive, not advisory — the agent decides suitability.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. While it describes the returned data comprehensively, it does not explicitly state that the operation is read-only or idempotent, nor does it mention any side effects, auth requirements, or error behavior. The lack of such details leaves uncertainty for agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first details what is returned, the second summarizes it as an 'instant portfolio', and the third provides a usage guidelines. It is efficient and front-loaded, though the first sentence is slightly dense. No unnecessary words, and the structure is logical.
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 presence of an output schema (though not shown), the description does not need to explain return values in detail. It covers the main components of the thesis: economic framework, portfolio, and stress evidence. However, it omits aspects like error handling, parameter validation, or response size limits. Overall, it provides sufficient context for an agent to understand what the tool delivers.
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?
With 0% schema description coverage, the description must add meaning to the 'slug' parameter. It mentions that slugs can be discovered via list_investment_theses, which provides a practical source. However, it does not define the slug format, provide examples, or specify constraints (e.g., required length, allowed characters). The link to another tool is helpful but insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the complete thesis for `slug`' and lists the components (economic framework, rule-based portfolio, stress evidence). It distinguishes the tool from its sibling list_investment_theses by noting that slugs are discovered via that function. The title 'Get one investment thesis (full case study)' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to discover slugs using list_investment_theses, providing clear context for when to use this tool versus that sibling. It also includes the guideline 'Descriptive, not advisory — the agent decides suitability,' which frames the tool as informational. However, it does not mention other sibling tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ips_gateIPS gate — planning-step constraint check (hard gate)AInspect
Check a portfolio against an Investment Policy Statement BEFORE accepting it — the planning step a proper process does FIRST (CFA). Provide holdings + IPS constraints (max_drawdown_tolerance as a fraction e.g. 0.15, time_horizon_years, liquidity_need 'low'|'medium'|'high'). Runs the stress test internally and flags where the proposal VIOLATES the stated policy: worst stress drawdown exceeds tolerance; a short horizon cannot absorb a deep drawdown; material holdings are less liquid than the stated need. A HARD GATE, not a score. Descriptive, not advisory.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| liquidity_need | No | ||
| time_horizon_years | No | ||
| max_drawdown_tolerance | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it runs an internal stress test, flags specific violations (drawdown, horizon, liquidity), and is deterministic (hard gate). It also clarifies it outputs violations, not a score, and is descriptive only. This goes well beyond minimal expectations.
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 moderately long (4 sentences) but every sentence earns its place by adding either purpose, usage, or parameter details. It is front-loaded with the primary action and structure is logical. Minor redundancy ('hard gate' appears twice) 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?
Given zero annotations and no schema descriptions, the description is remarkably complete: it specifies all inputs with examples, explains internal logic, and describes outputs (violation flags and conditions). It also mentions that it's a gate, not a score. The presence of an output schema (not shown) further reduces burden.
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, but the description explains the meaning and expected format of each parameter: holdings as portfolio, max_drawdown_tolerance as a fraction (e.g., 0.15), liquidity_need as low/medium/high, time_horizon_years as a number. This adds significant value beyond the raw 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?
Clearly states it checks a portfolio against an IPS before acceptance, explicitly calling it a 'hard gate' and distinguishing itself as a screening step, not a score. The verb 'check' combined with the specific resource 'portfolio against an IPS' provides high clarity, and sibling tools like portfolio_stress_test are implicitly differentiated.
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 advises using the tool 'BEFORE accepting' a portfolio and frames it as 'the planning step a proper process does FIRST (CFA)', which gives clear context. While it does not explicitly list when not to use it or compare to siblings, the 'hard gate' and 'descriptive, not advisory' phrases help guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_investment_thesesList investment theses (catalog discovery)AInspect
Discover the investment-thesis catalog. Each entry is a descriptive case study that pairs an economic framework with a rule-based portfolio and the synthetic + historical stress evidence for that allocation. Returns one compact summary per thesis (slug, title, one-liner, tags, risk tiers, framework summary, headline finding). Call get_investment_thesis(slug) for the full framework / portfolio / stress evidence, or read the thesis://{slug} resource. Descriptive, not advisory — the agent decides what is suitable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavioral traits: returns compact summaries, lists included fields, and states it is non-advisory. 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 focused sentences, front-loaded with purpose. Each sentence adds value 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?
Output schema exists, but description already provides expected fields. Given zero parameters and clear purpose, description is fully 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?
No parameters (0), so schema coverage is 100%. Baseline 4 applies. No additional parameter info 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?
Clearly states it discovers the investment-thesis catalog and describes the content. Distinguishes from sibling tools by mentioning get_investment_thesis(slug) and the resource for full details.
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?
Explicitly states when to use this tool for catalog discovery versus get_investment_thesis(slug) or the resource. Also clarifies that it is descriptive, not advisory, leaving suitability decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
long_horizon_stressLong-horizon wealth-path stress (savings / withdrawal plans)AInspect
Distribution of multi-year wealth paths for a savings plan (monthly_contribution) or a withdrawal plan (monthly_withdrawal, inflation-indexed by default) on a portfolio from the substrate universe. Multi-year paths chain ~2y model blocks (block-bootstrap, disclosed); long-run drift is RE-ANCHORED to stated capital-market assumptions (overridable via long_run_drift; the substrate's raw stress drift would compound a structural bear universe — both are echoed in the output) while the model's path shape (vol, clustering, correlations, hedge-breaks) is kept. Costs are ON by default. Returns terminal-wealth quantiles (nominal + real), ruin/shortfall probabilities, a sequence-of-returns diagnosis (same plan, bad vs good first two years), and a drift-sensitivity block (assumptions − 2pp). Amounts in the caller's currency unit. Descriptive, not advisory — no rate, allocation, or product is recommended.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| rebalance | No | monthly | |
| horizon_years | Yes | ||
| target_amount | No | ||
| long_run_drift | No | ||
| annual_inflation | No | ||
| initial_investment | No | ||
| monthly_withdrawal | No | ||
| monthly_contribution | No | ||
| withdrawal_inflation_indexed | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: block-bootstrap construction, drift re-anchoring, costs enabled by default, and that amounts are in caller's currency. It also notes the tool is descriptive, not advisory, which adds transparency. However, it does not mention authorization requirements or error conditions.
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 moderately lengthy but each sentence provides substantive information about functionality, methodology, or outputs. It is front-loaded with the main purpose. While dense, it avoids redundancy and earns its length given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, output schema exists), the description covers the core purpose, method, and outputs, but lacks parameter details and usage constraints. The output schema compensates for return format, but the description does not fully address when to invoke this tool over siblings.
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 beyond the schema by explaining that monthly_contribution and monthly_withdrawal define savings vs. withdrawal plans (implying they are not used together), and that long_run_drift overrides assumptions. However, with 0% schema description coverage, many parameters (e.g., holdings, rebalance, target_amount) are not explained, missing an opportunity to clarify 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 it simulates multi-year wealth paths for savings (monthly_contribution) or withdrawal (monthly_withdrawal) plans, and lists specific outputs like terminal-wealth quantiles and ruin probabilities. This specific verb+resource combination distinguishes it from sibling tools like portfolio_stress_test or run_stress_test, which likely cover other stress scenarios.
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 long-horizon planning with savings or withdrawal plans, but does not explicitly state when to use this tool versus alternatives like portfolio_stress_test or run_stress_test. No exclusions or prerequisites are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
portfolio_comparePortfolio compare (paired Revise-step comparison)AInspect
Compare two portfolios (A = reference, B = candidate revision) on IDENTICAL simulated substrate paths — a paired design, so every delta is attributable to the weights, not seed noise. Returns drawdown-distribution deltas (median/worst/quantiles), probability-weighted scenario summaries, per-scenario outcome deltas, risk-concentration shift (Euler decomposition), and which diversification failures the candidate introduces or resolves. revision_required flags a candidate that deepens the worst-path drawdown or introduces a new diversification failure — the case where a revision made robustness worse. Provide holdings_a / holdings_b as lists of {asset, weight}. Descriptive, not advisory; neither portfolio is recommended or ranked.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings_a | Yes | ||
| holdings_b | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the paired design (identical substrate paths), the meaning of the revision_required flag, and the range of outputs. It is transparent about the tool's behavior and limitations, such as being descriptive not advisory.
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 comprehensive but somewhat long. It is well-structured with key points upfront (purpose, inputs, output flag) and additional details following. Every sentence earns its place, though slight trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the presence of an output schema (not shown), and no annotations, the description covers all essential aspects: purpose, inputs, output details (delta distributions, scenario summaries, diversification shifts, flag), and caveats. It is complete for effective 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 description coverage is 0%, but the description adds that holdings_a and holdings_b are lists of {asset, weight}, providing essential structure beyond the generic schema. However, it could specify the exact required fields (e.g., 'asset' and 'weight') more explicitly.
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 compares two portfolios (reference vs candidate revision) on identical simulated paths, specifies what is returned (drawdown deltas, scenario summaries, risk-concentration shift, etc.), and distinguishes it from sibling tools by emphasizing the paired design and focus on delta attribution.
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 explains inputs (holdings_a and holdings_b as lists of {asset, weight}) and notes the tool is descriptive, not advisory. However, it does not explicitly state when to use this tool versus alternatives like portfolio_stress_test or factor_decomposition, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
portfolio_stress_testPortfolio stress (multi-asset, Tier-1)AInspect
Stress a multi-asset portfolio across cross-asset regimes (baseline / risk_off_crisis / rate_shock). Provide holdings as a list of {asset, weight}; weights are normalised. Returns, per regime: portfolio return, worst-episode drawdown, a per-leg decomposition, and a cross_asset_finding (diversification_intact / hedge_holds / hedge_breaks / shared_drawdown) describing how the holdings behaved TOGETHER. The joint correlation structure (incl. the bond hedge that can break under rate shocks) is baked into a pre-computed substrate, so Tier-1 is instant over a fixed universe (read portfolio://universe). Optional costs ({rebalance: none|daily|monthly|quarterly|band, annual_costs: {asset: fraction}, transaction_cost_bps}) adds a cost_impact block: frictionless vs the stated rebalancing policy + costs via a path-loop engine with real unit accounting, paired on identical paths. The substrate is a fixed 4-asset universe (SPY, TLT, GOLD, BTC; read portfolio://universe). For ANY other ticker or a custom multi-asset book, use build_portfolio in assess mode (portfolios={name:{ticker:weight}}), which calibrates and stresses an arbitrary universe live. Descriptive, not advisory.
| Name | Required | Description | Default |
|---|---|---|---|
| costs | No | ||
| holdings | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: instant over fixed universe, tier-1, pre-computed substrate, results per regime including drawdown and cross-asset findings, cost impact via path-loop engine, and disclaimer 'Descriptive, not advisory'.
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 thorough but slightly verbose; it front-loads purpose and then provides necessary details. Every sentence adds value, but could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema (though context indicates it exists) and no annotations, the description is fully self-contained: explains inputs, outputs per regime, cost behavior, universe scope, and sibling guidance.
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%, but the description explains holdings as list of {asset, weight} with normalized weights, and costs as optional object with rebalancing policy and annual costs, adding critical meaning beyond the raw 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 stresses a multi-asset portfolio across regimes, with specific verb 'Stress' and resource 'multi-asset portfolio'. It distinguishes itself from siblings by mentioning the fixed universe and referencing build_portfolio for custom universes.
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?
Explicit guidance is provided: the tool is for the fixed 4-asset universe, and for any other ticker or custom book, use build_portfolio in assess mode. This clearly answers when to use this tool vs alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regime_outlookRegime-probability outlook (validated assets, h=5/21)AInspect
Model-conditional probabilities that an asset is in each market regime (BULL / SIDEWAYS / BEAR / CRISIS, operational trailing-vol/drift labels) after a 5- or 21-trading-day horizon — the probability complement to the conditional stress tools: stress tools answer 'what happens GIVEN regime X', this answers 'how likely is regime X from today's observable state'. Ships only the preregistered, out-of-sample-validated tier (covariate logit; seasonality was tested and falsified); the persistence and unconditional baselines are reported alongside so an agent can see how much the model adds. Validated assets: SPY, QQQ, GLD, TLT. Optional as_of (YYYY-MM-DD) computes the outlook at a historical date. Probabilities describe membership in operationally defined regime classes — descriptive, not a market prediction, not advisory.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| asset | No | SPY | |
| horizon_days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the model type (covariate logit), that seasonality was falsified, that persistence and unconditional baselines are reported, and that outputs are descriptive, not a market prediction. It also mentions optional as_of for historical dates. This goes well beyond basic purpose to reveal behavioral traits and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 5-6 sentences. It front-loads the main purpose and then adds context about model details and limitations. It is concise but could be slightly more structured (e.g., separate sentences for parameters). Overall, every sentence 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?
Given that an output schema exists, the description does not need to detail return values. It mentions that persistence and unconditional baselines are reported alongside, giving some idea of output structure. For a tool with 3 parameters and a detailed description, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the three parameters: as_of (historical date), asset (validated assets: SPY, QQQ, GLD, TLT), and horizon_days (5 or 21 trading days, though default is 21). It adds meaning beyond the bare schema by listing valid assets and explaining what horizon means. However, it does not explicitly restrict horizon_days to 5 or 21, which could be misleading.
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 computes model-conditional probabilities for market regimes (BULL/SIDEWAYS/BEAR/CRISIS) over 5- or 21-day horizons. It specifies the verb (computes probabilities), resource (asset), and distinguishes it from sibling stress tools, indicating it answers 'how likely is regime X' rather than 'what happens given regime X'.
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 explains this tool is the probability complement to stress tools and gives explicit context on when to use it versus them. It also notes validated assets and that probabilities are descriptive, not predictive. However, it does not explicitly mention when not to use it or name alternative tools for similar tasks among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_stress_testRun stress test (buy-and-hold, v1)AInspect
Run a buy-and-hold backtest against the synthetic stress regime identified by profile_hint. Returns a structured diagnostic: robustness score (0-100), per-FM-bucket failure-behavior classification with confidence + context, and the resolved regime parameters that were actually evaluated. v1 supports only buy-and-hold. To discover available regime profile_hints, read the regimes://available resource. Diagnostic is descriptive, not advisory.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_hint | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool runs a backtest and returns a diagnostic, but does not disclose side effects, mutability, rate limits, or safety profile. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the action and result. Every sentence adds value: purpose, output structure, limitation and resource pointer. 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?
With an output schema present, the description appropriately summarizes return values without over-specifying. It covers the v1 limitation and hints at regime parameters. The missing piece is a statement about side effects or idempotency, but the annotation gap is compensated by the clear output description.
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 parameter `profile_hint` has 0% schema description coverage. The description adds meaning by explaining it identifies a synthetic stress regime and directing users to the resources endpoint for available hints, which significantly supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a buy-and-hold backtest against a synthetic stress regime identified by profile_hint, returning a structured diagnostic. It specifies the output components (robustness score, per-FM-bucket classification, regime parameters) and notes v1 supports only buy-and-hold. This distinguishes it from siblings like long_horizon_stress.
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 tells users to read the `regimes://available` resource to discover profile_hints, and notes the diagnostic is descriptive not advisory. However, it lacks explicit when-not-to-use guidance or comparison to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit structured feedbackAInspect
Persist structured improvement feedback about a previous tool response. Provide your agent identity, the request_id you are commenting on, and one or more feedback items each carrying category (from the FeedbackCategory ontology), severity, observation, optional suggested_action, and agent_confidence (0..1). Read feedback://insights to see aggregated cross-agent feedback.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | ||
| request_id | No | ||
| agent_vendor | No | ||
| feedback_items | Yes | ||
| session_context | No | ||
| overall_confidence | Yes | ||
| platform_version_evaluated | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses persistence and hints at a read resource, but does not elaborate on authorization, rate limits, or side effects beyond insertion. More detail would improve 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 sentences, front-loaded with purpose, and efficiently explains required structure without extraneous 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 7 parameters and existing output schema, description covers main inputs and hints at related resource. Optional parameters could be explained, but overall sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by detailing required fields (agent_name, request_id, feedback_items with nested fields, overall_confidence). It adds meaning (FeedbackCategory ontology, severity, etc.) but omits optional parameters like agent_vendor and session_context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool persists structured improvement feedback, with a specific verb 'persist' and resource 'feedback about a previous tool response'. It is distinct from sibling tools which are financial analysis 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 specifies required inputs (agent identity, request_id, feedback items with category, severity, etc.) and suggests reading aggregated feedback via 'feedback://insights'. It lacks explicit when-not-to-use but siblings are unrelated, so context is clear.
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!