Skip to main content
Glama
simoncoombes

tradefloor

by simoncoombes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Run strategies through a stress scenario

run_stress_scenario
Read-onlyIdempotent

Run trading strategies through a macro stress scenario beside an identical unshocked market, then compare both arms to detect how each strategy responds to the shock.

Instructions

Run strategies through a macro stress scenario, always beside the same market unshocked, and compare each strategy across the two. scenario is a shipped document by name (list_scenarios gives each one's first_event_day, and the run must be longer than that), a constructor by name (vix_shock, rate_ramp, timed with peak_day), or a document from build_scenario. A scenario whose events all fall after the run is refused. Pass fork_day to run both markets together first and start the scenario on that day, as a fork of one shared history. Use the result to detect a response, not to forecast its size. days 1 to 60 here, up to 252 through start_job. Takes preset and population as evaluate_strategies does, the same in both markets. Deterministic.

Input Schema

NameRequiredDescriptionDefault
daysNoTrading days to run: 1 to 60 in a direct call, up to 252 (the certified horizon) through start_job.
seedNoSimulation seed, an integer from 0 to 2**64 - 1. The same seed and arguments give the same result.
presetNoA shipped model preset to run, by name: pt-v1, pt-v2, pt-v3, pt-v4, pt-v5, pt-v6, pt-v7, pt-v8, pt-v9, pt-v10, pt-v11, pt-v12, pt-v13, pt-v14, pt-v15, pt-v16, pt-v18, pt-v19, pt-v20, pt-v21. Omit for the shipped default, pt-v21, the only preset the realism envelope certifies; a result under any other carries a caveat saying it is outside the certification, with that preset's own measured record. describe_simulator lists every preset's record.
fork_dayNoRun both markets together for this many days, then split them and start the scenario on the first day after the split: day `fork_day` of the run. The scenario's events keep their spacing, and every strategy trades the shared days identically in both arms. 0 to days - 1. Only for a scenario made of interventions (a shipped document, or build_scenario with `shocks`); a macro path or a constructor pins the macro from day 0, so it has no fork point.
peak_dayNoConstructors only. vix_shock: the day the VIX jumps to its peak (default 10). rate_ramp: the day the policy rate and corporate yield reach their end level (default 30). A vix_shock peak must fall inside the run.
scenarioYesA shipped document by name (list_scenarios lists them with the day each one's first event falls on, and the run must be longer than that), a constructor by name (vix_shock, rate_ramp, timed with peak_day), or a scenario document from build_scenario.
universeNoA roster document, usually the `universe` field of a build_universe result. Either {"size": n, "seed": s, "sectors": [...]} or {"instruments": [...]}. When given it replaces universe_size, universe_seed and universe_sectors.
populationNoA shipped population of background traders to run beside, by name: standard, crowded. They share each strategy's market and react to its trading (populated mode), so a result says whether an edge survives other traders, and strategies no longer meet identical markets. Omit for isolated mode, the default. describe_simulator lists each population's traders.
strategiesNoOptional strategies to run beside the baselines, in the evaluate_strategies form. The baseline names are taken.
universe_seedNoSeed that generates the roster, separate from the simulation seed. Ignored when `universe` is given.
universe_sizeNoNames in a generated roster, 2 to 120. Ignored when `universe` is given.
universe_sectorsNoLowercase sector ids to concentrate a generated roster on, for example ["technology", "energy"]. The ids: technology, financial_services, healthcare, energy, consumer_discretionary, consumer_staples, industrials, materials, real_estate, utilities, telecommunications, transportation. A concentrated roster is a named envelope gap, and the result says so.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.10.1
    • addedInput schema / properties / population
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A shipped population of background traders to run beside, by name: standard, crowded. They share each strategy's market and react to its trading (populated mode), so a result says whether an edge survives other traders, and strategies no longer meet identical markets. Omit for isolated mode, the default. describe_simulator lists each population's traders.",
+  "title": "Population"
+}
    • addedInput schema / properties / preset
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A shipped model preset to run, by name: pt-v1, pt-v2, pt-v3, pt-v4, pt-v5, pt-v6, pt-v7, pt-v8, pt-v9, pt-v10, pt-v11, pt-v12, pt-v13, pt-v14, pt-v15, pt-v16, pt-v18, pt-v19, pt-v20, pt-v21. Omit for the shipped default, pt-v21, the only preset the realism envelope certifies; a result under any other carries a caveat saying it is outside the certification, with that preset's own measured record. describe_simulator lists every preset's record.",
+  "title": "Preset"
+}
  2. Changed1 schema field changedv0.1.1
    • addedInput schema / properties / fork_day
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Run both markets together for this many days, then split them and start the scenario on the first day after the split: day `fork_day` of the run. The scenario's events keep their spacing, and every strategy trades the shared days identically in both arms. 0 to days - 1. Only for a scenario made of interventions (a shipped document, or build_scenario with `shocks`); a macro path or a constructor pins the macro from day 0, so it has no fork point.",
+  "title": "Fork Day"
+}
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds real behavioral context beyond them: determinism, the refusal of scenarios whose events all fall after the run, the fork_day shared-history mechanism, and populated mode breaking identical-market assumptions. It does not discuss output shape or cost, but with an output schema present and rich annotations this is solid.

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?

Front-loaded with the core purpose, then constraints and routing. Dense but nearly every sentence carries information; a couple of clauses (scenario form enumeration, days limits) restate what the schema fields already say, which is mild redundancy rather than padding.

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?

For a 12-parameter simulation tool with an output schema and full annotation coverage, the description supplies everything an agent needs to call it correctly: valid scenario forms, the length-versus-first-event rule, fork_day applicability, and the certification caveat on non-default presets. Return values are delegated to the output schema appropriately.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds relational semantics the schema does not: fork_day applies only to intervention scenarios (not macro paths or constructors), preset and population must be identical in both markets, and the scenario's three accepted forms. These cross-parameter constraints go beyond the per-field schema text.

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?

States a specific verb and resource (run strategies through a macro stress scenario) plus the defining scope: always beside the same market unshocked, comparing each strategy across the two arms. This distinguishes it from evaluate_strategies, which has no shock arm, and the sibling is named explicitly for parameter parity.

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

Usage Guidelines4/5

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

Gives clear routing: days 1-60 here versus up to 252 through start_job, and 'Use the result to detect a response, not to forecast its size' sets the interpretation boundary. It also names list_scenarios and build_scenario as sources for the scenario argument. It stops short of an explicit 'use this instead of X when...' rule, so 4 rather than 5.

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

Deploy Server

Other Tools