Claude can use ENSEMBLE to research assets and build, test, and maintain allocation models when it has a compatible MCP connection. The model stays in ENSEMBLE after the conversation ends, with stored code, inputs, builds, and runs you can inspect in the browser or another supported interface.
Connect and check access
For Claude web, open ENSEMBLE in the Claude directory, choose Connect to Claude, and sign in to your intended ENSEMBLE account. Ask Claude to confirm that account before creating or changing a model. Verify your plan and workspace allow connector access; an administrator may control it. The MCP connection guide covers other supported clients and shares its setup instructions with the dashboard.
For Claude Code, the documented connection command is:
claude mcp add --transport http ensemble https://api.ensemble.markets/mcp
Use /mcp to inspect the connection and authenticate. Confirm the ENSEMBLE account before creating anything. Builds and runs are metered; reading stored work is free. Start with $100 in credit, valid for 7 days, with no card required. Builds and runs are metered. See pricing for current terms.
An illustrative research session
The requests below are examples, not a transcript or measured performance. They deliberately separate proposing a rule, executing it, and deciding whether to adopt a change.
First, check the assets.
Look up SPY and BIL. Show the available history and any missing fields that affect the research. Do not assume the backtest can start before the required inputs exist.
Claude can use list_assets and get_asset with optional include=["history"]. Compare the available dates with the intended test window. If you choose a backfill, record its source and assumptions and distinguish that synthetic period from actual fund history.
Then define and build the model.
Build a model that evaluates SPY against its 200-day simple moving average at month end, holds SPY when above the average, and BIL otherwise. Make the lookback a declared input. Explain the execution timing and what costs are included.
Claude discovers the model runtime contract and creates the model. Wait for completion, then ask it to inspect the actual source, inputs, and result. A successful build shows that code executed; it does not establish that the code implements your intention or that the strategy is suitable.
Inspect before interpreting.
Read the stored implementation and latest successful run. Confirm the universe, dates, lookback, evaluation cadence, fill timing, and whether transaction costs or taxes are modeled. Show the model link and explain any discrepancy.
Review the metrics and allocation history over the same window as the benchmark. Do not quote returns from this article; use the actual dated result.
Compare a parameter without changing the live model
Test a 150-day lookback using the same script and an isolated run. Keep the live defaults unchanged. Compare its inputs, dates, and results with the original run.
The agent should inspect inputs_schema, call run_model with intent=test, then use compare_runs on completed results. An isolated test can use default inputs too. It should not rebuild the strategy merely to change a declared parameter, or run an unbounded search for the best historical result.
If you choose to adopt a completed parameter test, ask the agent to promote it and verify the successful result and new defaults. Promotion can refresh dependent models and consume usage. For strategy-code changes, create a separate private model to preserve the approved implementation. Revision tools are not currently enabled in the plugin.
Keep the model useful after the chat
Enable scheduled refreshes if you want the model maintained. Runs depend on model and dependency readiness, data availability, available credit, and account spending limits. Ask for the latest successful run and its data date; an enabled schedule alone does not show that allocations are current.
You can return to the same work through another supported client or the web app. Visibility is an explicit model setting; creating a model does not require publishing it. Broker-format exports on Business help with a separate execution workflow and never place trades.
ENSEMBLE is research software. Backtests are hypothetical and past performance does not guarantee future results. The common mistakes guide covers overfitting, incomplete histories, and other reasons a plausible result can mislead.
Frequently asked questions
- Which Claude connection should I use?
- Use the current ENSEMBLE MCP connection guide for Claude or Claude Code. Check your client's plan, connector availability, and workspace permissions before starting.
- Why has a build returned before it is finished?
- Builds run in the background. Inspect the model's in-progress run, status, and any error before reading a result. A queued build is not proof of a successful backtest, and completion time varies.
Related
- AI agentsA finance MCP server for allocation models and research
Use ENSEMBLE's hosted MCP server to research available assets, build allocation models, inspect saved runs, and retrieve allocations. Understand connection requirements, data coverage, and metered execution before starting.
- BacktestingHow to backtest a portfolio without writing code
Research two assets, build an allocation model, inspect its saved results, and compare one change. A practical first workflow for DIY investors using ENSEMBLE.
- BacktestingCommon backtesting mistakes and how to avoid them
The ways a backtest lies: lookahead bias, survivorship bias, overfitting, ignored costs, short or regime-limited samples, and misread metrics. What each one looks like, how to detect it, and what a backtesting tool can and cannot protect you from.