tradefloor

Overview Schema Source Related Servers Discussions Admin

Open a market session

open_session

Open a simulated market session to control each step manually and receive a session ID for orders, state checks, forking, or rewinding.

Instructions

Open a simulated market that this server keeps between calls, and get a session id back. Use a session when you want to decide each step yourself and see what happened before the next: send orders with session_step, read with session_state, try two actions from one state with session_fork, and go back with session_rewind. To score a strategy you can write as a spec, use evaluate_strategies or rank_strategies instead. agents names the traders: null for one you drive with orders, or a strategy spec for one that trades itself each step. preset and population choose the market as they do for evaluate_strategies. Opening runs no market. At most 8 sessions are open at once, in this server's memory only, and one idle for 30 minutes is closed.

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": "open_session"
  }
}

Input Schema

Name	Required	Description
`cash`	No	Starting cash for each entrant, in currency.
`seed`	No	Simulation seed, an integer from 0 to 2**64 - 1. The same seed and arguments give the same result.
`agents`	No	The traders in this market, keyed by a name you choose. null is one you drive with orders in session_step; a strategy spec, for example {"signal": {"kind": "momentum", "lookback_days": 1.0}, "portfolio": {"top_k": 5, "gross": 1.0}}, trades by itself each step. At most 8. All of them trade one market and move each other's prices. Omit for one agent called "me".
`preset`	No	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.
`universe`	No	A 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.
`population`	No	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.
`max_leverage`	No	Cap on gross exposure as a multiple of net worth. null removes the cap, and the result then warns that trading size alone can win.
`steps_per_day`	No	Decision points per trading day, 1 to 22. A step is 65 minutes, so 6 cover the trading session.
`universe_seed`	No	Seed that generates the roster, separate from the simulation seed. Ignored when `universe` is given.
`universe_size`	No	Names in a generated roster, 2 to 120. Ignored when `universe` is given.
`universe_sectors`	No	Lowercase 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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.10.1Oct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=false, non-idempotent) by disclosing behavior the schema cannot: 'Opening runs no market' (no simulation work until a step), a concurrency cap of 8 sessions, that sessions live only in server memory, and a 30-minute idle TTL. These are exactly the operational traits an agent needs to avoid losing state.

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 purpose, then usage, then parameter glosses, then limits and TTL. It is a dense single paragraph rather than strictly unscannable, and it mostly avoids restating schema text verbatim. Minor redundancy with the already-thorough parameter descriptions keeps it from a 5.

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?

With an output schema present, return values need not be explained, and the description compensates with everything else: purpose, alternatives, companion-tool roles, resource limits, and lifetime semantics. Nothing an agent needs to open and manage a session correctly is missing.

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 description coverage is 100%, so the baseline is 3, but the description still adds meaning: it glosses `agents` (null = one you drive; a spec = self-trading) and ties `preset`/`population` semantics to evaluate_strategies for consistency. It does not add much on cash/seed/steps_per_day beyond what the schema already says, keeping it just above baseline.

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 first sentence gives a specific verb+resource ('Open a simulated market that this server keeps between calls') and states the return value (a session id). It explicitly distinguishes this tool from siblings like evaluate_strategies and rank_strategies, which are for spec-based scoring. An agent can tell exactly what this does without opening the 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?

Explicit when-to-use: 'Use a session when you want to decide each step yourself and see what happened before the next,' plus a named alternative for the other case ('to score a strategy you can write as a spec, use evaluate_strategies or rank_strategies instead'). It also routes the agent to the companion tools session_step/session_state/session_fork/session_rewind by describing what each is for.

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