What Is a Stack?

A stack is a runnable bundle of two buildable parts: a skill — the playbook the AI follows — and MCPs, the tools it can call.

That is the whole definition. Everything else on this page is consequences of it.

Why the app needs this idea at all

A general AI assistant with access to your files is capable of almost anything and reliable at almost nothing. Ask it to research a strategy and you get a different method every time: sometimes a rigorous backtest, sometimes a confident paragraph with invented numbers in it.

The problem is not the model. The problem is that "research a strategy" is not a specification, and every conversation starts from nothing.

A stack is the fix. It pins down the method and the tools in advance, so that the same request produces the same kind of work every time.

The two parts

The skill

A skill is a markdown file containing the playbook: what this stack is for, what method to follow, what to refuse, what to check before starting, what the output should look like. It is instructions, written in prose, that the assistant reads before it does anything.

The skill in the shipped research stack, for instance, insists on checking that the Python engine works before you write a strategy, insists on a real backtest before any judgement, and treats "nothing appeared on the Canvas" as a bug to chase rather than an acceptable outcome. Those are opinions, encoded once, applied every time.

The MCPs

An MCP is a tool server — a program exposing capabilities the assistant can call. Running a script, querying a data provider, placing an order at a broker, reading your positions. If a skill is what the assistant knows, MCPs are what it can do.

MCPs are also where integrations live. QuantIDE ships no broker connections and no data feeds, and maintains no list of supported venues. That is not a gap to be filled in a future release — it is the design. A broker integration is an MCP, which means it is a stack, which means anyone can write one and everyone can install it.

A stack is a manifest, not a folder

The stack itself is a small JSON file that references parts by id. The parts live on disk in their own right and can be shared between stacks.

{
  "id": "quant-research",
  "name": "Quant Research",
  "description": "Idea to rules to backtest to verdict.",
  "category": "research",
  "source": "template",
  "parts": [
    { "kind": "skill", "id": "quant-research-playbook",
      "label": "Quant Research Playbook", "status": "ready" },
    { "kind": "mcp", "id": "runner",
      "label": "Runner", "status": "ready" }
  ]
}

That is a complete, working stack — the one that ships with the app. Two parts and some labels.

Parts come in three kinds. Skills and MCPs you have met. The third is context: reference material the stack carries so its work is grounded in your situation rather than in generic assumptions.

What this buys you

• Repeatability — the same request runs the same method, because the method is a file rather than a memory.
• Scope — each stack works in its own folder, so a stack pointed at one project is not quietly editing another.
• Portability — a stack is small enough to send someone in a message. What travels is the method and the tool wiring, never your local paths or keys.
• Ownership — the skill is your markdown, the MCP is your code, the scripts are your files. Nothing is locked in an account.

Forking is the point

Stacks are meant to be opened up and taken apart. The intended workflow is not "find the stack that matches how you work" — it is install something close, delete what does not fit, and keep the scaffolding.

This is why the shipped research stack teaches plain, ordinary vectorbt rather than a house wrapper. There used to be a bundled QuantIDE Python package, and it was deleted on purpose: the model has read an enormous amount of vectorbt and zero lines of our library, so every call against a custom API was a guess where idiomatic code is recall. Standard tools win. That lesson is worth carrying into anything you build.

Where a stack comes from

Three places, marked by their origin badge. Shipped, meaning it came with the app. Yours, meaning you built it. Community, meaning you installed it from the marketplace or someone sent it to you.

After the first fork, the distinction stops mattering much. It is all just yours.