mcp-server-worldquantbrain

Overview Schema Source Related Servers Discussions Admin

Simulate an alpha

simulate_alpha

Backtests a FASTEXPR expression to return alpha statistics and validation checks, and resumes timed-out simulations by ID instead of rerunning them.

Instructions

Backtest one FASTEXPR expression and return its alpha with stats and checks.

A simulation usually takes 1 to 10 minutes. If it outlasts the timeout the result has status
PENDING and a simulation_id: call get_simulation_status to resume, never simulate again.
Identical expression and settings return the earlier result (from_ledger) without spending
quota. ERROR or FAIL results carry BRAIN's message, usually a syntax or field problem.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "expression": "<expression>"
    },
    "name": "simulate_alpha"
  }
}

Input Schema

Name	Required	Description
`wait`	No	True blocks until done or timeout; False returns the id at once.
`decay`	No	Smoothing window in days.
`delay`	No	Data delay, 0 or 1.
`force`	No	Run again even if the ledger has this exact alpha.
`region`	No	Market region, e.g. USA. Empty uses the default.
`universe`	No	Universe, e.g. TOP3000. Empty uses the default.
`max_trade`	No	ON or OFF.
`expression`	Yes	FASTEXPR expression.
`truncation`	No	Max weight.
`test_period`	No	ISO duration, e.g. P2Y.
`nan_handling`	No	ON or OFF.
`unit_handling`	No	VERIFY.
`neutralization`	No	NONE, MARKET, SECTOR, INDUSTRY or SUBINDUSTRY.
`pasteurization`	No	ON or OFF.
`instrument_type`	No	EQUITY.
`timeout_seconds`	No	Seconds to block. Empty uses WQB_SIMULATION_TIMEOUT.

Output Schema

Name	Required	Description	Default
`alpha`	No
`quota`	No
`status`	Yes
`message`	No
`alpha_id`	No
`children`	No
`progress`	No
`next_step`	No
`from_ledger`	No
`simulation_id`	Yes
`elapsed_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: expected duration of 1-10 minutes, the PENDING/timeout semantics, quota consumption, ledger deduplication behavior, and the meaning of ERROR/FAIL results (BRAIN's syntax/field message). This is exactly the kind of operational detail annotations cannot convey.

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

Conciseness5/5

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

Four sentences, each carrying distinct information, with the core operation and the critical timeout-recovery rule front-loaded. No redundant restatement of the title or schema.

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 16-parameter, long-running, quota-consuming simulation with an output schema, the description covers duration, timeout handling, caching, and error semantics. Return value structure is handled by the output schema, so nothing an agent needs to call it correctly 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 every parameter including wait, force, timeout_seconds and decay is already documented. The description adds no syntax or format detail beyond what the schema provides, so 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?

States a specific verb and resource ('Backtest one FASTEXPR expression and return its alpha with stats and checks'), and the word 'one' implicitly separates it from the batch sibling simulate_alphas_batch. An agent can identify the operation 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 Guidelines4/5

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

Gives explicit recovery guidance: if the result is PENDING with a simulation_id, call get_simulation_status to resume and 'never simulate again'. Also explains that identical expression/settings return the cached ledger result. It does not state when to prefer simulate_alphas_batch, which is the only real gap.

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