crashtestyourstrategy

Market regime map (18 category proxies, h=5/21)

market_regime_map

Read-onlyIdempotent

USE WHEN you want to know what the market is doing now across 18 category proxies. One call, 18 category proxies (US large-cap + tech, 9 SPDR sectors, developed ex-US, emerging markets, long Treasuries, high-yield credit, gold, oil, Bitcoin): the operational regime, model-conditional regime probabilities on trading day 5 or 21, stress probability vs its baseline, a descriptive forward-return distribution conditional on the regime label, and an equity-factor commonality flag (US sectors re-express one factor). Per cell, only the tier that passed the preregistered out-of-sample rule ships (raw p<0.05, see tier_pvalues; tier_correction shows which survive a multiple-testing correction). No directional forecast. For one asset with as_of support: regime_outlook. Descriptive, not advisory.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "market_regime_map"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	'full' (default) or 'summary': summary leaves out the per-row persistence and unconditional baselines and states the forward-return basis and data dates once (about a third smaller; the response lists what was left out).	full
`horizon_days`	No	The trading day the probabilities refer to, counted from the data date. Validated: 5 or 21.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedInput schema / properties / horizon_days / description

Previous value: -"Validated horizons only: 5 or 21 trading days."New value: +"The trading day the probabilities refer to, counted from the data date. Validated: 5 or 21."

Changed2 schema fields changedNov 8, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / detail

Added value: +{
+  "default": "full",
+  "description": "'full' (default) or 'summary': summary leaves out the per-row persistence and unconditional baselines and states the forward-return basis and data dates once (about a third smaller; the response lists what was left out).",
+  "title": "Detail",
+  "type": "string"
+}

Changed1 schema field changedAug 1, 2026
- addedInput schema / properties / horizon_days / description
```
Added value: +"Validated horizons only: 5 or 21 trading days."
```
AddedJul 22, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With readOnly/idempotent/non-destructive annotations already covering the safety profile, the description goes well beyond them: it explains the preregistered out-of-sample shipping rule (raw p<0.05), that tier_correction shows multiple-testing survivors, that responses can be shrunk roughly a third via summary detail, and that no directional forecast is produced. It stops short of stating latency, rate limits, or a concrete response shape, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The usage trigger is front-loaded and no sentence is pure filler, but the middle sentences are dense, stacking long parenthetical enumerations and jargon (tier_pvalues, tier_correction, equity-factor commonality) that require a second read. Slightly tighter phrasing would improve scannability without losing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite being a complex 18-proxy, multi-output tool, the definition supplies annotations, a full output schema, and 100%-covered parameters, and it still adds the interpretive guardrails an agent needs ('No directional forecast', 'Descriptive, not advisory') plus the tier-validation caveat. Nothing required to call or correctly frame the result is missing.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines both 'detail' and 'horizon_days' fully. The description only echoes the horizon ('trading day 5 or 21') and indirectly hints at the summary/detail trade-off via the response-size note, adding little semantic meaning beyond what the parameter descriptions already supply. Baseline 3 applies.

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

Purpose5/5

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

The definition opens with a concrete scope statement ('what the market is doing now across 18 category proxies') and then enumerates the exact outputs: operational regime, model-conditional regime probabilities at day 5/21, stress probability vs baseline, forward-return distribution, and an equity-factor commonality flag. It also explicitly distinguishes itself from the single-asset sibling by saying 'For one asset with as_of support: regime_outlook.' An agent can identify this tool without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'USE WHEN' clause gives an explicit triggering condition, and the closing sentence names the alternative tool (regime_outlook) plus the condition that selects it (one asset with as_of support). It also implicitly scopes the tool to broad cross-asset reads rather than single-asset queries, leaving little to inference.

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

All crashtestyourstrategy tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.