Portfolio and strategy stress diagnostics with hedge-break detection and regime outlook. Free tier.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 16 of 16 tools scored. Lowest: 3.9/5.
Most tools target distinct resources/actions (regime introspection vs. portfolio stress vs. thesis management), but a few names like run_stress_test vs. portfolio_stress_test could cause confusion. Descriptions help clarify boundaries, but there is enough overlap to mark one point off.
Names are mostly snake_case but mix verb_noun (get_dossier, run_stress_test) with noun phrases (factor_decomposition, market_regime_map). The verb style is inconsistent (get/list/run/describe/submit/challenge), though the pattern is readable. This falls between predictable and chaotic.
16 tools is slightly above the typical 3-15 range, but the domain is broad (regime analysis, portfolio stress testing, strategy evaluation, feedback). Most tools are distinct and necessary; only a couple could be merged without loss of functionality.
The surface covers core workflows: discovering theses, stress-testing portfolios, analyzing regimes, evaluating strategy robustness, and collecting feedback. Minor gaps exist (e.g., no custom strategy builder, challenge_strategy only supports buy-and-hold), but these are explicitly noted as future work.
backtest_integrityBacktest integrity check (deflated Sharpe + regime coverage)AConfront 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 | Kurtosis of the strategy's returns (3 = normal). | |
| skew | No | Skewness of the strategy's returns (0 = symmetric). | |
| asset | No | Asset context for the regime-coverage check (default: SPY as the equity-crisis reference). | |
| n_trials | No | Number of configurations tried before selecting this backtest — drives the deflated-Sharpe correction. Unknown → the claim is flagged UNPROVEN. | |
| frequency | No | Return observations per year (252 = daily bars). | |
| backtest_end | No | Backtest window end (YYYY-MM-DD). | |
| backtest_start | No | Backtest window start (YYYY-MM-DD) — used to detect crisis regimes the window never contained. | |
| annualized_sharpe | No | The claimed annualized Sharpe ratio of the backtest. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds important behavioral context: 'Descriptive, not advisory' clarifies it won't recommend actions, and the UNPROVEN flag for missing n_trials explains an edge-case behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, with the second long sentence using semicolons to list outputs efficiently. Every sentence contributes meaning, and the structure front-loads the purpose. It is dense but not overly 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?
The description covers the core functionality, the edge case of unknown trial counts, and the advisory nature. Given the output schema exists and the tool has 8 parameters, the description is sufficient without detailing the crisis-regime catalogue internals.
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 100%, so the baseline is 3. The description adds the relationship between n_trials and deflation, and backtest window to regime coverage, but most parameter-level semantic meaning is already in the schema. 'All inputs optional' is a usage note rather than semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('confront') and identifies the resource ('a backtest claim'). It explicitly lists the three outputs (deflated Sharpe, absent crisis regimes, base-rate caveat), making the tool's function distinct from siblings like challenge_strategy or run_stress_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before trusting it' establishes a clear context for use. The conditional about unknown trial counts gives additional guidance. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
challenge_strategyChallenge a strategy: find what breaks it (3-layer output)AAdversarial-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 | Strategy identifier; v1 supports only 'buy_and_hold'. | buy_and_hold |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context about the 3-layer output structure, the supported strategy limitation, and a reference to an ontology resource, enriching the behavioral profile without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with useful information and well-structured, starting with the core purpose and then elaborating with output layers and limitations. It could be slightly trimmed but remains efficient given the 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?
With an output schema present and annotations covering safety, the description fully covers the tool's behavior, including its unique 3-layer output, supported strategies, and vocabulary reference. No significant gaps remain for an agent to invoke or interpret results correctly.
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 fully documents the single parameter with description and default, including the v1 limitation. The tool description repeats that limitation but adds no further parameter semantics beyond what the schema already 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 identifies the tool as an adversarial-evaluation primitive that returns a 3-layer analysis for a given strategy identifier. It enumerates the specific outputs (outcome metrics, vulnerability profile, descriptor attribution), distinguishing it from sibling tools like run_stress_test or portfolio_stress_test.
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 but does not explicitly state when to use this tool versus alternatives. It mentions the v1 limitation to 'buy_and_hold' as a constraint, but lacks direct comparisons or exclusions relative to sibling tools.
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-portraitASingle-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 | Synthetic stress-regime identifier, e.g. 'whipsaw_synthetic_spy'. Discover valid values via the regimes://available resource. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds behavioral nuance beyond these annotations: it returns z-scores against a catalogue population, generates a characterisation from extreme descriptors, and outputs nearest neighbours. This explains the analytical nature of the tool without contradicting the safety hints.
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 lists outputs, the second contrasts with a sibling, the third gives usage timing. Every sentence carries essential information, and the core purpose is front-loaded. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (multiple output components) and the presence of an output schema, the description adequately covers purpose, usage, and output behavior. It also clarifies the relationship to sibling tools, so the agent has full context to decide when to invoke it.
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 parameter description includes a concrete example and tells how to discover valid values. The tool description itself doesn't add much beyond what the schema provides, but it doesn't need to since the schema is already explicit. Baseline 3 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 opens with 'Single-regime introspection' and enumerates concrete outputs (median behavioural descriptors, z-scores, English characterisation, nearest neighbours), making the tool's function unmistakable. It also explicitly contrasts with the sibling find_similar_regime, clarifying what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage guidance: 'Read this before searching if you want to reason about one regime first.' It explicitly names the alternative tool and explains the difference in behavior, so the agent knows when to choose this tool over find_similar_regime.
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)AReveal 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 | Portfolio legs: list of {asset, weight} objects, e.g. [{'asset': 'SPY', 'weight': 0.6}, {'asset': 'TLT', 'weight': 0.4}]. Weights are normalised to sum to 1; assets must be in the substrate universe. Each substrate asset proxies a factor (SPY=equity beta, TLT=duration, GOLD=real asset, BTC=crypto). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. The description adds significant behavioral context: it explains the method (empirical covariance of real returns), the asset-to-factor mapping, and the caveat that it's descriptive not advisory. This goes well beyond the minimal annotation coverage.
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?
Despite containing a formula, asset mappings, and two examples, every sentence contributes a distinct piece of information. It is front-loaded with the core insight and remains tightly structured without fluff.
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 output schema available and annotations covering safety, the description covers purpose, methodology, example outputs, and interpretive caveats. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of the 'holdings' parameter with format, example, and constraints. The description's repetitions of the asset-factor mapping and examples are helpful but do not add new semantics not already present in the schema, so a baseline 3 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 opens with a specific verb 'Reveal' and clearly identifies the resource: hidden risk concentration. It then precisely defines the output (Euler risk-contribution decomposition) with a formula, distinguishing it from sibling tools like stress tests and regime analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context through examples (60/40, 50/50 SPY/BTC) and the 'descriptive, not advisory' disclaimer, implying when to use it for risk analysis. However, it does not explicitly name alternative tools or exclusions, so it stops short of full comparative guidance.
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 descriptorsANearest-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 | Number of nearest regimes to return. | |
| asset_filter | No | Restrict matches to one asset (e.g. 'SPY', 'BTC'). | |
| descriptor_target | No | Partial target spec {descriptor_name: value}; only the provided dimensions contribute to the distance. Definitions: ontology://regime-descriptors. | |
| reference_profile_hint | No | Use this catalogue bundle's median descriptors as the search target (mutually exclusive with descriptor_target). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: missing dimensions in descriptor_target are ignored, distance is computed in z-score space, and per-descriptor signed deltas are returned so the agent can understand the match. It also points to ontology and catalogue references, going well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) yet covers the essential input modes, output fields, and references. It is front-loaded with the main purpose and every clause adds value. No redundant or 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?
Given the tool's moderate complexity (4 optional parameters, output schema present, annotations provided), the description is thorough. It covers the two mutually exclusive inputs, the optional filter, the return value (top_n matches with similarity and deltas), and where to get further definitions. It does not detail error cases for missing both inputs, but with an output schema and the description's explicit 'Provide EITHER' phrasing, the context is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds extra semantic clarity, especially for descriptor_target: 'missing dimensions are ignored — only the provided ones contribute to distance.' It also reinforces the mutual exclusivity of the two input modes, which is present in schema but emphasized in 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 opens with a specific verb+resource: 'Nearest-neighbour retrieval over the cached regime catalogue.' It clearly distinguishes this from sibling tools like describe_regime or market_regime_map by focusing on similarity search. The two input modes and the output (similarity_score, distance, deltas) are precisely stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states how to use the tool: provide EITHER a reference_profile_hint OR a descriptor_target, with an optional asset_filter. It does not explicitly name alternatives or exclusion conditions beyond what is inherent, but the usage context is clear. No explicit 'when not to use' guidance is given, which keeps it from a 5.
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)ACompile 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 | Alternatively: compile the N most recent recorded entries (ignored when request_ids is given). | |
| request_ids | No | Explicit request_ids to compile chronologically (take them from previous responses' request_id fields). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, lowering the bar. The description adds valuable context: automatic recording of every envelope response, the return payload including gate signals and a markdown document, and the semantic meaning of revision_required on the dossier. It also clarifies the tool's nature as 'factual record, not an assessment', which goes beyond the structured fields.
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, reasonably dense paragraph. It front-loads the primary purpose, and each sentence earns its place: purpose, recording behavior, parameter usage, return details, alternative endpoint, and nature of the output. The aphorism 'a proper process documents itself' is slightly stylistic but not wasteful.
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 and strong annotations, the description is quite complete. It covers purpose, parameter usage, return summary, and even a REST alternative. It does not discuss error handling or authorization, but those are not essential here given the read-only, idempotent nature and existing structured data.
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%, so baseline is 3. The description adds meaningful semantics by stating request_ids are compiled chronologically and last_n captures the most recent entries, and that last_n is ignored when request_ids is provided. This enriches the parameter understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+output: 'Compile recorded diagnostic responses into ONE citable record'. It clearly distinguishes itself from siblings by focusing on the audit trail of past diagnostics rather than performing new analysis or assessments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining the two parameter modes (explicit request_ids vs. last_n) and notes that last_n is ignored when request_ids are given. It also points to a REST alternative for single verbatim entries, giving a concrete 'when not to use'. However, it doesn't explicitly compare against sibling diagnostic tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_investment_thesisGet one investment thesis (full case study)AReturn 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 | Thesis slug — discover valid values via list_investment_theses(). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context by detailing the exact contents of the return and emphasizing that the tool is 'descriptive, not advisory,' which helps the agent understand how to interpret the output. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but well-structured, front-loading the core action and then enumerating the return contents. The final sentences provide usage guidance and a concise nickname. It is slightly long but every sentence contributes meaning.
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 description comprehensively covers what the tool returns, how to get a slug, and how to interpret the results (descriptive vs advisory). With an output schema present, the description need not detail return value types, making this quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'slug' with guidance to use list_investment_theses(). The description reinforces this and adds context about the output but does not offer additional parameter-level semantics 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 the tool returns the complete thesis for a given slug, enumerating the economic framework, portfolio construction, and stress evidence. It explicitly distinguishes itself from list_investment_theses (discovery) and describes itself as the 'instant portfolio with all tested attributes'.
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 a clear usage context: use this tool to retrieve a full case study for a known slug, and discover valid slugs via list_investment_theses(). It also clarifies that the output is descriptive and not advisory, leaving suitability to the agent. However, it does not explicitly state when not to use the 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.
ips_gateIPS gate — planning-step constraint check (hard gate)ACheck 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 | Portfolio legs: list of {asset, weight} objects, e.g. [{'asset': 'SPY', 'weight': 0.6}, {'asset': 'TLT', 'weight': 0.4}]. Weights are normalised to sum to 1; assets must be in the substrate universe. | |
| liquidity_need | No | 'low' | 'medium' | 'high' — violated when material holdings are less liquid than the stated need. | |
| time_horizon_years | No | Investment horizon stated in the IPS; short horizons cannot absorb deep drawdowns. | |
| max_drawdown_tolerance | No | IPS drawdown tolerance as a fraction, e.g. 0.15 = a -15% maximum acceptable drawdown. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing that the stress test is run internally and explicitly lists the violation conditions (worst stress drawdown, short horizon, liquidity). It also clarifies the output nature ('A HARD GATE, not a score; Descriptive, not advisory'), which aligns with readOnlyHint and idempotentHint and adds context about the result framing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—four sentences—and front-loaded with the core purpose. Each sentence contributes either the operation, input guidance, behavioral logic, or output characterization, with no redundancy or filler.
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 and annotations, the description fully covers the tool's behavior, including the internal stress test and the specific IPS violation checks. It also clarifies the hard-gate nature and the distinction from advisory tools, making it self-sufficient for an agent to select and invoke it correctly.
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 100%, so the baseline is 3. The description restates parameter examples and semantics already present in the schema (e.g., 'max_drawdown_tolerance as a fraction e.g. 0.15', liquidity_need values), and does not add meaningful new parameter-level detail 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 uses a specific verb phrase 'Check a portfolio against an Investment Policy Statement' and clearly states its role as a 'planning-step constraint check (hard gate)'. It distinguishes itself from siblings like run_stress_test and portfolio_stress_test by stating it is 'A HARD GATE, not a score' and by focusing on IPS compliance rather than general stress testing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides strong timing guidance ('BEFORE accepting it — the planning step a proper process does FIRST') and clarifies that it is 'Descriptive, not advisory', which implies it is not for generating recommendations. However, it does not explicitly name alternative tools or enumerate specific when-not-to-use scenarios, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_investment_thesesList investment theses (catalog discovery)ADiscover 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 | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it explains the output format ('Returns one compact summary per thesis...'), clarifies the nature of the content ('Descriptive, not advisory'), and points to the full resource. This goes beyond the readOnlyHint and idempotentHint, and there is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each packed with useful information: what the catalog is, what the summary contains, and how to get more detail. No filler or redundant 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?
With no parameters, an output schema, and clear sibling guidance, the description fully covers what an agent needs to invoke this tool correctly and interpret its results. It also places the tool within a larger information ecosystem.
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, so the schema is trivially complete. The description adds semantic richness by detailing what the returned summaries include, satisfying the 'baseline 4' plus additional informative content.
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: 'Discover the investment-thesis catalog' and describes what each returned summary includes. It also distinguishes from sibling tools by pointing to get_investment_thesis 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?
The description explicitly says 'Call get_investment_thesis(slug) for the full framework / portfolio / stress evidence, or read the thesis://{slug} resource,' giving clear guidance on when to use this tool vs. alternatives. It also frames the tool as a discovery endpoint with compact summaries.
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)ADistribution 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 | Portfolio legs: list of {asset, weight} objects, e.g. [{'asset': 'SPY', 'weight': 0.6}, {'asset': 'TLT', 'weight': 0.4}]. Weights are normalised to sum to 1; assets must be in the substrate universe. | |
| rebalance | No | Rebalancing frequency: 'daily' | 'monthly' | 'quarterly'. | monthly |
| horizon_years | Yes | Plan horizon in years (multi-year paths are chained from ~2-year model blocks). | |
| target_amount | No | Optional wealth target; the output reports the probability of reaching it. | |
| long_run_drift | No | Override the re-anchored long-run drift per asset: {ASSET: annual drift fraction}; omit for the stated capital-market assumptions. | |
| annual_inflation | No | Annual inflation assumption for indexing and real-value reporting (fraction, default 0.02). | |
| initial_investment | No | Starting capital (account currency). | |
| monthly_withdrawal | No | Monthly withdrawal (withdrawal-plan mode); inflation-indexed when withdrawal_inflation_indexed is true. | |
| monthly_contribution | No | Fixed monthly savings contribution (savings-plan mode). | |
| withdrawal_inflation_indexed | No | Index the monthly withdrawal to inflation. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive safety, but the description adds substantial behavioral detail: long-run drift is re-anchored to stated assumptions, costs are ON by default, the model preserves path shape from the substrate while overriding drift, and the tool is explicitly non-advisory. It also discloses the block-bootstrap chaining method and that both the raw stress drift and re-anchored drift are echoed in output — valuable 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 dense but well-structured: it opens with the core purpose, proceeds to methodological details (block chaining, drift re-anchoring), then outputs, and ends with a caveat. Every sentence conveys necessary information for a complex tool, with no filler or redundancy. It is appropriately sized given the tool's sophistication.
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) and the presence of an output schema, the description covers all critical context: input modes (savings/withdrawal), methodology (chained blocks, drift re-anchoring), default behaviors (costs on, inflation indexing), output types, and usage limits (descriptive, not advisory). It leaves no major gaps for an agent to misuse 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?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying how monthly_contribution and monthly_withdrawal define mutually exclusive plan modes, notes that monthly_withdrawal is inflation-indexed by default (reinforcing schema), and explains that long_run_drift overrides the re-anchored drift. It also mentions costs being ON, which relates to implicit parameters not in the schema, enriching parameter understanding.
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 the tool's function: it computes distributions of multi-year wealth paths for savings or withdrawal plans, and explicitly lists the outputs (quantiles, ruin probabilities, sequence-of-returns diagnosis, drift-sensitivity). It distinguishes itself from generic stress tests by focusing on long-horizon savings/withdrawal scenarios, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: for evaluating multi-year savings or withdrawal plans, particularly with inflation-indexed withdrawals and re-anchored drift. It does not explicitly name alternative tools like portfolio_stress_test, but the context ('savings plan', 'withdrawal plan') provides clear situational guidance. No exclusions are stated, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_regime_mapMarket regime map (18 category proxies, h=5/21)ACompressed cross-category map of the current market state in ONE call: for 18 category proxies (US large-cap + tech, the 9 SPDR sectors, developed ex-US, emerging markets, long Treasuries, high-yield credit, gold, oil, Bitcoin) the operational regime (BULL/SIDEWAYS/BEAR/CRISIS), model-conditional regime probabilities over a 5- or 21-trading-day horizon, stress probability vs its unconditional baseline, a descriptive historical forward-return distribution conditional on the current regime label, and an equity-factor commonality flag (US sectors largely re-express one factor — the map is fewer independent signals than rows). Per (asset, horizon) cell only the preregistered, out-of-sample-validated model tier ships (covariate logit / persistence / unconditional — see tier_pvalues). Deliberately ships NO directional up/down forecast: regime membership is the validated signal, not return direction. Use regime_outlook for single-asset depth with as_of support. Descriptive, not a market prediction, not advisory.
| Name | Required | Description | Default |
|---|---|---|---|
| horizon_days | No | Validated horizons only: 5 or 21 trading days. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it emphasizes that the tool is 'Descriptive, not a market prediction, not advisory,' that it ships no directional forecast, and that only preregistered, out-of-sample-validated model tiers are used. These disclosures enrich the read-only/idempotent hints already provided by annotations without contradiction.
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 dense and front-loaded with the core purpose, then details outputs, caveats, and an alternative. While long, every sentence contributes necessary information (proxies list, outputs, validation, non-forecast disclaimer, sibling pointer). Its structure is logical, moving from overview to specifics to exclusions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 18 proxies and multiple outputs, the description is highly complete: it lists all output categories, explains the model tier selection, explicitly states what the tool does NOT provide (directional forecast), and points to a sibling tool for alternative needs. The existence of an output schema means return-value details need not be spelled out, but the description still covers operational context thoroughly.
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% (horizon_days described as 'Validated horizons only: 5 or 21 trading days'). The description reinforces the 5/21 horizon and adds meaning by explaining that per (asset, horizon) cells select model tiers (covariate logit / persistence / unconditional) and that probabilities are model-conditional over the chosen horizon. This contextualizes the parameter beyond the schema's basic constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool's function: 'Compressed cross-category map of the current market state in ONE call' and enumerates the 18 category proxies and outputs (regime labels, probabilities, stress probability, forward-return distribution, commonality flag). It also distinguishes from the sibling tool regime_outlook by noting its single-asset depth with as_of support.
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 this tool versus alternatives: 'Use regime_outlook for single-asset depth with as_of support.' It also states a clear non-goal: 'Deliberately ships NO directional up/down forecast,' which sets expectations and helps the agent decide between this and other tools.
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)ACompare 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 | Reference portfolio A. Portfolio legs: list of {asset, weight} objects, e.g. [{'asset': 'SPY', 'weight': 0.6}, {'asset': 'TLT', 'weight': 0.4}]. Weights are normalised to sum to 1; assets must be in the substrate universe. | |
| holdings_b | Yes | Candidate revision B, same shape — evaluated on paths identical to A's, so every delta is attributable to the weights. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, the description adds rich behavioral context: it returns specific delta metrics (drawdown, scenarios, Euler decomposition, diversification failures), explains the paired design eliminates seed noise, and defines the revision_required flag. This goes well beyond the annotation hints.
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 appropriately sized and front-loaded with the primary purpose. Each sentence contributes meaningful information about outputs or interpretation, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description fully enumerates return values (drawdown deltas, scenario summaries, risk-concentration shift, diversification failures, revision_required semantics). With annotations and an output schema present, this is a complete and self-sufficient 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 input schema already provides 100% coverage with detailed descriptions, examples, and normalization notes for both holdings_a and holdings_b. The description's brief mention 'Provide holdings_a / holdings_b as lists of {asset, weight}' adds no new information, so it meets the baseline without exceeding it.
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 (A = reference, B = candidate revision) using identical simulated substrate paths. The verb 'Compare' and resource 'two portfolios' are specific, and the paired-design emphasis distinguishes it from sibling tools like portfolio_stress_test.
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 when to use: when comparing a reference to a candidate revision in a paired setup. It also notes 'Descriptive, not advisory' to clarify non-recommendation. However, it does not explicitly exclude alternatives or name specific sibling tools, stopping short of full guidance.
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)AStress 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 | Optional cost model: {'rebalance': 'monthly', 'transaction_cost_bps': float, 'annual_costs': {ASSET: annual fraction}}. Omit for the frictionless default. | |
| holdings | Yes | Portfolio legs: list of {asset, weight} objects, e.g. [{'asset': 'SPY', 'weight': 0.6}, {'asset': 'TLT', 'weight': 0.4}]. Weights are normalised to sum to 1; assets must be in the substrate universe. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true and destructiveHint=false, the description adds rich behavioral context: the joint correlation structure includes a bond hedge that can break under rate shocks, the cost_impact block uses a path-loop engine with real unit accounting, and the output is described per regime. It also notes the pre-computed substrate for near-instant execution, going well 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 dense paragraph, but every sentence contributes operational value: purpose, input format, output structure, internal mechanism, universe constraints, alternative tool, and disclaimer. No filler; appropriately sized for 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?
Despite having an output schema, the description further explains return values per regime and the cross_asset_finding enumeration. It covers prerequisites (read portfolio://universe), the fixed universe, optional costs, and alternatives. The description is self-contained for an agent to decide when and how to 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?
Schema descriptions cover both parameters at 100%, so baseline is 3. The prose adds semantic value by explaining that weights are normalised, assets must be in the substrate universe, and detailing the costs object structure (rebalance enum, annual_costs, transaction_cost_bps) and its effect on output (adds cost_impact block). This exceeds baseline but doesn't fully elaborate on the 'band' rebalancing policy, so 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 tool's action ('Stress a multi-asset portfolio') and scope (three named cross-asset regimes), and distinguishes itself from siblings by explicitly restricting to a fixed 4-asset universe and pointing to build_portfolio for any other ticker. This is a specific verb+resource+scope that differentiates it from tools like run_stress_test.
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 when-to-use guidance: use for the fixed universe (SPY, TLT, GOLD, BTC), and for any other ticker or custom book use build_portfolio in assess mode. Also mentions the tool is instant (Tier-1) and includes a disclaimer ('Descriptive, not advisory'), giving clear usage context and exclusions.
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)AModel-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 | Optional historical evaluation date (YYYY-MM-DD); empty = latest data. | |
| asset | No | One of the out-of-sample-validated assets: 'SPY', 'QQQ', 'GLD', 'TLT'. | SPY |
| horizon_days | No | Validated horizons only: 5 or 21 trading days. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/idempotentHint, description discloses that seasonality was tested and falsified, that only the preregistered out-of-sample-validated tier ships, and that baselines are included for comparison. It also includes a disclaimer that probabilities are descriptive, not a market prediction or advisory. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, with the core purpose in the first sentence. Each clause earns its place, though it could be split into shorter sentences for easier parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description is complete: it covers scope, assets, horizons, validation status, baseline reporting, and a clear disclaimer. Addresses complexity of model-conditional probabilities well.
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 each parameter already has a description. The description adds context: as_of computes a historical outlook, horizon days are validated only 5 or 21, and asset is restricted to the validated list. It enriches the semantic meaning of the output (probability complement) 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 opens with a specific verb phrase 'Model-conditional probabilities that an asset is in each market regime' and names the exact output (BULL/SIDEWAYS/BEAR/CRISIS probabilities) and horizon. It explicitly contrasts with sibling stress tools ('probability complement'), distinguishing it from run_stress_test/portfolio_stress_test.
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?
States when to use this vs stress tools: 'stress tools answer what happens GIVEN regime X, this answers how likely is regime X from today's observable state'. Also constrains usage to validated assets and horizons, and mentions baselines for calibration. No explicit when-not but the complement framing is clear.
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)ARun 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 | Synthetic stress-regime identifier, e.g. 'whipsaw_synthetic_spy'. Discover valid values via the regimes://available resource. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive behavior. The description adds value by disclosing the return structure, the fact that profile_hint is resolved into actual evaluated parameters, the v1 buy-and-hold limitation, and the non-advisory nature of the diagnostic—beyond what annotations provide.
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?
Four sentences, each earning its place: purpose, return contents, v1 scope, resource discovery, and caution about advisory nature. Highly front-loaded, no redundancy, and perfectly sized for the 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?
Despite having an output schema, the description compensates by detailing the return fields (robustness score, failure-behavior classification, resolved regime parameters). It also covers preconditions (resource for hints), limitations (v1 buy-and-hold), and interpretation (descriptive, not advisory). This is comprehensive for a read-only diagnostic 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 description coverage is 100%, so the parameter is already documented. The description enhances meaning by explaining that profile_hint is a 'hint' that gets resolved to concrete regime parameters, which adds the semantic nuance that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run a buy-and-hold backtest against the synthetic stress regime identified by profile_hint.' It clearly distinguishes from siblings by limiting to buy-and-hold and synthetic stress regimes, and it enumerates the return value 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 provides clear usage context: it is for buy-and-hold only, gives a prerequisite (discover profile_hint via regimes://available), and notes the diagnostic is descriptive not advisory. It names no explicit alternative tool, but the scope limitation implicitly differentiates it from other stress-test tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit structured feedbackAInspectPersist 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 | Your agent identity (model or product name). | |
| request_id | No | request_id of the response this feedback refers to. | |
| agent_vendor | No | Vendor of the submitting agent (e.g. 'Anthropic', 'OpenAI'). | |
| feedback_items | Yes | One or more items, each {category (FeedbackCategory ontology), severity, observation, suggested_action?, agent_confidence (0..1)}. | |
| session_context | No | Optional free-text context of the session/workflow the feedback arose in. | |
| overall_confidence | Yes | Overall confidence in this feedback, 0..1. | |
| platform_version_evaluated | No | Schema/platform version the feedback refers to (e.g. 'ctys-agent-v1'). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply some baseline (readOnlyHint=false, idempotentHint=false), and the description adds 'persist,' confirming a write operation. It does not discuss duplicate-handling, failure modes, or access/auth requirements, but for a straightforward persistence tool it provides acceptable disclosure 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 with the core purpose front-loaded. It packs necessary input structure into one sentence and the insight-reading hint into the second without verbosity. It earns its length given the tool's parameter richness.
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 available and annotations present, the description covers the submission flow, required/optional fields, and points to aggregate insights. It is complete enough for a simple persistence tool, though it could add examples or error expectations.
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 already fully documents all 7 parameters (100% coverage). The description mostly restates the schema (agent identity, request_id, feedback item structure) without adding new syntactic or semantic precision, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Persist structured improvement feedback about a previous tool response,' a clear verb+resource+object pairing. It distinguishes this meta-tool from the unrelated quantitative-finance siblings by its explicit feedback-persistence scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool (when providing improvement feedback about a prior response) and lists the required inputs. It lacks explicit exclusions or alternatives, but there are no sibling feedback tools, and the reference to `feedback://insights` gives practical context. This is clear context without formal when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.