AI agents

What is a finance MCP server, and is there one for backtesting?

A finance MCP server gives an AI assistant tools for investment research. This guide explains how MCP works, what separates a data-lookup server from a backtesting server, hosted versus local servers, authentication, and the tools ENSEMBLE's server exposes.

By Updated Published 7 min read

A finance MCP server is a program that exposes investment-related capabilities, such as looking up an asset, computing a metric, or backtesting a strategy, as tools that an AI assistant can call through the Model Context Protocol. Most of the finance MCP servers you will find today are thin wrappers around a data vendor's API: they let an assistant fetch a price or a filing. A backtesting MCP server is a different category, because it has to execute code against historical data and return a result the assistant can reason about. ENSEMBLE runs one, and this guide explains what that means and how to use it.

What is MCP, in one paragraph?

The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, for connecting AI assistants to external tools and data. An MCP server publishes a list of tools with names, descriptions, and JSON schemas for their inputs. An MCP client, which is the assistant application, reads that list, shows it to the model, and when the model decides to call a tool, sends the call to the server and returns the result to the model. The protocol is the same regardless of what the tools do, which is why one server can work with Claude, Cursor, VS Code, Codex, Gemini CLI, Windsurf, and any other client that speaks it.

The consequence for finance is that an assistant no longer has to guess. Asked how a strategy would have performed, a model without tools produces a plausible-sounding paragraph. A model with a backtesting tool produces a call, gets back a tear sheet, and reasons from the numbers.

Two kinds of finance MCP server

It helps to separate finance MCP servers by what the tools actually do.

Data servers wrap a market-data or fundamentals API. Their tools are things like get_quote, get_historical_prices, get_income_statement, or search_filings. They are useful for research that ends in a fact: what is the dividend yield of this fund, when did this company last report. Most run locally, require you to bring your own vendor key, and return raw data for the assistant to interpret.

Computation servers run something. A backtesting server takes a strategy definition, executes it against a maintained dataset, and returns derived results: metrics, an equity curve, holdings over time. This is harder to build because it needs a sandbox to run code safely, a dataset with survivorship and total returns handled, and storage so a result can be revisited and rerun as new data arrives. It is also more useful, because the assistant gets answers rather than inputs.

ENSEMBLE's server is the second kind. Its tools do not return prices; they return strategies. The dataset, the execution, and the storage live behind the URL.

Hosted or local?

A local MCP server runs on your machine, launched by your client as a subprocess. A hosted server runs remotely and your client connects over HTTP. Most finance MCP servers on GitHub are local, and for a data wrapper that is fine.

For backtesting, hosted is the right architecture, for three reasons.

  • Execution safety. Backtesting a described strategy means generating and running code. Running generated code on your own machine is a risk you should not take. A hosted server executes in an isolated sandbox with no access to your files or network.
  • Data. A backtest needs twenty years of daily total-return history with splits, dividends, and delistings handled correctly. Maintaining that locally is a project in itself. A hosted server maintains it once for everyone.
  • Persistence. A strategy built in a chat should still exist tomorrow, with a tear sheet you can share and a nightly rerun that keeps it current. That requires a server that outlives the conversation.

The trade-off is trust. With a hosted server you are relying on the operator's methodology. ENSEMBLE addresses that by making every model's generated code readable and downloadable, and by documenting data sources, cost assumptions, and execution on the methodology page.

How authentication works

ENSEMBLE's server supports two authentication paths, and which one you use depends on the client.

OAuth 2.1 with PKCE is the default for interactive clients. You paste https://api.ensemble.markets/mcp into Claude, Cursor, or VS Code, the client discovers the authorization server through the standard metadata endpoints (RFC 9728 and RFC 8707), opens the ENSEMBLE sign-in, and receives a token. There are no keys to copy.

Bearer API keys are for headless clients, CLIs, and custom agents. Create an ensemble_ key in the dashboard and pass it in the Authorization header. The same key works for the REST API and the CLI.

What tools does the server expose?

The server exposes 45 tools, generated from the same REST API that the CLI and the TypeScript client are built on, so every surface shares one vocabulary. Models, simulations and analyses each get the same eight verbs (create_, list_, get_, update_, delete_, rebuild_, run_, list_*_runs); runs and builds are addressed by id whatever kind produced them. The ones that matter most for an agent doing research:

ToolWhat it doesWhen an agent should use it
create_modelBuilds a strategy, ensemble, or portfolio from a description. Returns immediately with a building status.When the user has stated a testable rule.
get_modelReturns status, the trading universe the code actually used, the window, run metadata, and any QA findings.After every build, and before drawing any conclusion.
get_buildReturns one build attempt: the generated code without the runtime harness, and the error when it failed. get_model carries the current build_id.When the user wants to verify the implementation, or when a result looks wrong.
rebuild_modelRebuilds a model, from a new prompt or from the stored one. On a failed model the failure context is attached automatically.To test a variation of an existing model, or to retry a failed build.
run_modelRuns the stored code, no LLM involved. With no inputs it reruns the defaults on new data and the result goes live; with inputs it produces a snapshot to compare. Waits for the result by default.When the user wants today's holdings, or the same rule at another parameter.
get_model_historyReturns the return series, holdings over time resolved through member models to tickers, the latest book with its target, metrics and fees, chosen with include.To inspect what the model returned and what it actually holds.
list_assets, get_asset, get_asset_historySearches and describes the asset catalog; history takes include=metrics.To confirm a ticker exists and has enough history before building.
update_modelRenames a model, changes visibility, or turns nightly auto-update and allocation alerts on or off.When the user wants a model kept current.
compare_runs, promote_runCompares runs of one program side by side with their input differences; promotes a run's inputs to the script's defaults.To choose between variations and make the winner the model.
create_optimizer, allocateDefines and applies a reusable weighting method.For advanced portfolio construction.
create_simulation, run_simulation, create_analysis, run_analysisBuilds a planning simulation (cash flows, glide paths, withdrawal rules) or a market analysis (regressions, correlations, tear sheets) with declared inputs, then runs it at chosen inputs.For planning and measurement questions rather than strategy backtests.

Builds run in the background because they take 20 to 120 seconds, longer than many transport timeouts. A well-behaved agent calls create_model, then polls get_model every few seconds until the status is no longer building, and only then reads the result. The tool descriptions say this explicitly, and clients that follow them do not hang. Runs are different: run_model waits for the result unless the agent passes wait: false.

What a good agent does with them

The tools reward the same habits a human researcher would use, and the backtest with Claude walkthrough shows them in a real session.

  1. Resolve the universe first. Call list_assets to confirm the tickers exist and check their start dates, so the backtest window is what the user expects. Pass start_date to create_model when the user names a period, and read window on get_model afterwards.
  2. State a complete rule. Universe, weighting, timing. An agent that passes "a momentum strategy" to create_model gets a model, but not necessarily the one the user meant. See how to backtest a portfolio for what a complete description contains.
  3. Read the whole result. get_model returns the universe the code actually traded and the rebalances per year it actually made. If either differs from the description, the agent should say so before quoting a Sharpe ratio.
  4. Vary one thing. Use rebuild_model to change a single parameter and compare, rather than reasoning about what the change would do.
  5. Compose. When two strategies are each useful, build an ensemble that holds both instead of a single strategy with more rules.

What the server does not do

It does not return live quotes, fundamentals, or news; a data server is the right tool for those, and an agent can use both at once. It does not execute trades or connect to a brokerage. It does not support intraday data or options. Its simulations do not model taxes, required minimum distributions, or Social Security rules. And it does not give advice: models are hypothetical backtests of rules the user described, simulations are hypothetical plans, and ENSEMBLE is research software rather than an investment adviser.

Connecting

The MCP server page has one-click installers for Cursor and VS Code and step-by-step instructions for Claude, Claude Code, Codex, Gemini CLI, and Windsurf. The short version for any client that accepts a URL: add https://api.ensemble.markets/mcp, sign in when prompted, and ask your assistant to backtest something.

Frequently asked questions

Is there an MCP server for backtesting?
Yes. ENSEMBLE runs a hosted MCP server at https://api.ensemble.markets/mcp that builds a strategy from a plain-language description, backtests it against twenty years of daily data in a sandbox, and returns the metrics, holdings, and generated code as tool results. Any MCP client that accepts a remote server URL can connect to it.
Do I have to run anything locally?
No. The server is remote and uses the Streamable HTTP transport. You paste one URL into your MCP client, sign in when prompted, and the tools appear. There is nothing to install, no data to download, and no keys to manage unless you prefer an API key.
What does the MCP server cost?
Reading models, assets, and metrics is free. Building, revising, and rerunning models is metered at the same rates as the web app and API, and every account starts with $100 in credit. There is no separate charge for using MCP rather than the API.
Can an MCP server place trades?
ENSEMBLE's cannot. It produces target allocations, backtests, and fact sheets; it never connects to a brokerage or executes an order. Some other finance MCP servers wrap brokerage APIs and can trade, which is a materially different risk profile and worth checking before you connect one.

Related

Backtests are illustrative. Past performance does not guarantee future results. ENSEMBLE is a software platform, not an investment adviser.

Part of AI agents for investment research.

Describe a strategy. Read the tear sheet.Connect the MCP server