Exposes the server's content (futures prop firm rules, technical indicators, and Setup Odds) to OpenAI's platform: it supplies the search and fetch tools that ChatGPT's deep research and company knowledge read, and supports being connected as a custom ChatGPT MCP server over a public HTTPS endpoint or via the OpenAI Responses API's remote mcp tool (with allowed_tools such as search, fetch, get_prop_plan_rules, and compare_prop_plans).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AlgoLift MCP Server when NQ gaps up, how often does it fill by noon?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives an AI assistant three open AlgoLift tools to call:
Prop firm rules. The rules of futures prop firm accounts (profit targets, drawdowns and how they trail, daily loss limits, consistency, minimum days, contract limits, payouts, fees), each rule with its verification status, the firm's own page it was checked against, and the date.
Indicators. The technical indicators and candlestick patterns of @algolift/indicators, each ported from TA-Lib, pandas-ta-classic, pandas-ta or technicalindicators and tested against that library's output.
Setup Odds. How often an intraday setup actually happened ("when it gaps up, how often does it fill by noon?"), on your bars, with the sample size and a 95% interval on every number. The engine is Setup Odds.
It also has search and fetch, the two tools ChatGPT's deep research and company knowledge read, over the same content, each document with the algolift.ai page to cite.
It is read-only: every tool reads the data bundled in this package and computes on what you pass it, and each says so to the client (readOnlyHint: true). It needs no AlgoLift account and no API key, calls no AlgoLift service, makes no outbound network request and reads no file of yours. It runs over stdio for desktop clients, or over HTTP for clients that take a server by URL, such as ChatGPT.
Made by AlgoLift, a no-code platform for building and backtesting trading strategies.
You need Node.js 20 or later. MCP clients start the server themselves with npx, so there is nothing else to install.
Open Settings, Developer, Edit Config, and add the server to claude_desktop_config.json:
{
"mcpServers": {
"AlgoLift": {
"command": "npx",
"args": ["-y", "@algolift/mcp"]
}
}
}Restart Claude Desktop. The tools appear in the tools menu of a new chat.
claude mcp add algolift -- npx -y @algolift/mcpAdd it to ~/.cursor/mcp.json (every project) or .cursor/mcp.json (one project):
{
"mcpServers": {
"AlgoLift": {
"command": "npx",
"args": ["-y", "@algolift/mcp"]
}
}
}Any client that runs a local MCP server over stdio takes the same command: npx -y @algolift/mcp. In VS Code, add it to .vscode/mcp.json:
{
"servers": {
"AlgoLift": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@algolift/mcp"]
}
}
}On Windows, if your client cannot find npx, use "command": "cmd" with "args": ["/c", "npx", "-y", "@algolift/mcp"].
To pin a version, name it: @algolift/mcp@0.1.0.
ChatGPT connects to a remote MCP server by URL, not to a command on your machine, so it needs the server reachable over public HTTPS. There are two ways to give it one:
The hosted endpoint, https://www.algolift.ai/api/mcp. AlgoLift serves the same tools there, stateless, with tighter caps (5,000 bars for an indicator, 50,000 for Setup Odds) and a per-address rate limit. It is not switched on yet: until it is, every request to it gets a 404. This README and the changelog will say when it is on.
Your own deployment of the HTTP mode (below), behind an HTTPS address you control.
Then, following OpenAI's guide to connecting from ChatGPT: open ChatGPT Plugins, select the plus button, then Add custom MCP server; give it a name and description; under Connection choose a public endpoint and enter the URL with its path (for example https://mcp.example.com/mcp); configure authentication (this server has no sign-in); review the risk warning; and select Create as a plugin. Which ChatGPT plans and workspaces can add custom MCP servers is OpenAI's to decide and changes over time, so check OpenAI's help center for yours.
ChatGPT's deep research and company knowledge read a server through two read-only tools, search and fetch, with the input and output shapes in OpenAI's MCP guide. This server has both (see Search and fetch), and every other tool is marked read-only (readOnlyHint: true) as well.
The Responses API's mcp tool takes a remote server by URL. With the hosted endpoint on, or your own HTTPS deployment in its place:
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({
model: "gpt-6.1-sol",
tools: [
{
type: "mcp",
server_label: "algolift",
server_description: "Futures prop firm rules with each rule's verification status, technical indicators, and Setup Odds.",
server_url: "https://www.algolift.ai/api/mcp",
allowed_tools: ["search", "fetch", "get_prop_plan_rules", "compare_prop_plans"],
require_approval: "never",
},
],
input: "Compare the Topstep and Apex 50K evaluations, and say which rules are not verified.",
});
console.log(response.output_text);allowed_tools limits which of the server's tools the model sees; leave it out for all eleven. require_approval: "never" suits a server whose tools are all read-only, as these are; the API asks for approval by default. A deep research model reads only search and fetch, and OpenAI's deep research guide says require_approval must be "never" there. The model above is the one OpenAI's MCP guide uses; any model that supports remote MCP servers works.
algolift-mcp --http serves the same tools over Streamable HTTP, stateless (each request is answered with one JSON body; no session and no event stream), by the same handler the hosted endpoint runs:
npx -y @algolift/mcp --http --port 3000
# AlgoLift MCP server 0.1.0 listening on http://127.0.0.1:3000/mcp (Streamable HTTP, stateless)--port (default 3000; 0 picks a free one), --host (default 127.0.0.1, this machine only; use 0.0.0.0 in a container or behind a proxy on another host), --path (default /mcp).
In HTTP mode every call has the hosted caps (5,000 bars for an indicator, 50,000 for Setup Odds, 4 MB bodies).
A request from a browser page (one with an Origin header) is answered only from localhost, unless you allow its origin with --allow-origin https://your.site (the MCP transport asks servers to check Origin). Server-side clients such as ChatGPT and the Responses API send none.
It has no rate limit and no authentication of its own: put it behind a reverse proxy that terminates HTTPS and limits requests before you give its URL to anyone. It reads only the data in the package and makes no outbound request.
To try it locally, run it and point the MCP Inspector at http://127.0.0.1:3000/mcp with the Streamable HTTP transport.
Related MCP server: BAMCP
Each example is something you might ask, then the arguments the assistant passes.
list_prop_firms: the firms and plans, with each plan's id and how many of its rules are verified.
"Which prop firms do you have rules for?"
{ "firm": "Apex" }get_prop_plan_rules: every rule and price of one plan, each with its status, source and date. Name the plan by its id, or by firm, program and size.
"What are Topstep's 50K Combine rules?"
{ "plan_id": "topstep/50k" }{ "firm": "Apex", "plan": "EOD", "size": "50K" }compare_prop_plans: plans side by side on the rules that matter most. Pass plans, or a size to compare every firm's plans of that size.
"Compare the 50K accounts at Topstep, Apex and MFFU."
{ "plans": ["topstep/50k", "Apex EOD 50K", "MFFU Rapid 50K"] }{ "size": 50000, "firms": ["Topstep", "Tradeify"] }Every rule carries one of four statuses, exactly as the prop firm rules dataset holds it, and the answer's text says plainly when a rule is not verified:
Status | In the answer | Meaning |
|
| Checked against the firm's page (linked) on that date. |
|
| The firm's pages do not state this rule, so the value is the assumption AlgoLift's simulator uses. |
|
| The firm changed it; the value is what AlgoLift simulates today, and it is being updated. |
|
| Never checked against the firm's page. |
A verified rule older than the dataset's re-check window (45 days) is flagged as a stale check. Every answer names the dataset it comes from and the dates its rules were checked; a newer dataset ships as a new release of this package. Firms change rules and prices often: read the firm's own page before you buy an evaluation.
list_indicators: search by name or by what it measures, or list a family.
"What volatility indicators can you compute?"
{ "query": "volatility" }describe_indicator: settings with defaults and limits, outputs, the library and file the code was ported from (with its license and every change the port made), and what verified it.
{ "id": "alma" }compute_indicator: run one on bars (oldest first), as objects or columns. Settings left out take the library's defaults. Up to 20,000 bars a call; each output comes back with one value per bar, null during its warmup.
"Here are my closes: what is their 3-bar WMA?"
{ "id": "wma", "columns": { "close": [101.6, 101.9, 102.4, 102.1, 103.0] }, "options": { "period": 3 } }{ "id": "cdl_engulfing", "bars": [{ "open": 10, "high": 11, "low": 9, "close": 9.5, "volume": 1200 }] }The library holds the indicators it has ported and verified. An indicator it does not have yet is not in this server either, and list_indicators says so rather than guessing.
A Setup Odds question is two texts: a setup (which sessions you ask about, like gap > 0.5%) and an outcome (what you want to know happened later that session, like touches prior.close by 12:00). Every time is New York time on the CME equity-index futures calendar.
list_setup_presets: the 25 ready-made setups, in five families (gap, opening-range, prior-day, overnight, event), each with its setup, outcome and parameters.
{ "family": "gap", "query": "noon" }describe_setup_query_language: the language's grammar, every value, window, function, operator and outcome form, the units and worked examples, or one section of them.
{ "section": "examples" }run_setup_odds: one preset, or a setup and an outcome, on your 1-minute bars (a list or CSV text) or on the synthetic demo bars. It returns how many sessions met the setup and how many of those saw the outcome, the rate with its 95% Wilson interval, the baseline over every measured session and the lift, a first-half against second-half split, counts by year, the time to the event, and every warning. Up to 2,000,000 bars, 2,600 sessions and 10 seconds a call.
"On my ES 1-minute bars, when it gaps up more than half a percent, how often does it trade back to yesterday's close by noon?"
{ "setup": "gap > 0.5%", "outcome": "touches prior.close by 12:00", "csv": "timestamp,open,high,low,close,volume\n2024-01-08 09:30,4780.25,4782,4779.5,4781.75,1200\n...", "label": "ES 2024" }{ "preset": "gap-up-fill-by-noon", "params": { "gap": 0.5 }, "demo": {} }The demo bars are synthetic, not market data, and every answer on them says so. Setup Odds counts how often something happened; it does not trade it (no entry rule, stop, costs or sizing), and an interval is for one question asked once.
The two tools ChatGPT's deep research and company knowledge read a server through, in the shapes OpenAI's MCP guide gives. Any MCP client can use them. They cover AlgoLift's open content only: the prop firms and each plan's rules, the indicators, and Setup Odds' presets and language.
search: takes one argument, query, and returns up to 10 matching documents, each with an id, a title and the public algolift.ai page to cite as its url.
{ "query": "Topstep 50K drawdown" }{ "results": [{ "id": "prop-plan:topstep/50k", "title": "Topstep 50K Combine rules: ...", "url": "https://www.algolift.ai/prop-firms/topstep/50k-combine" }] }fetch: takes one argument, id (a search result's), and returns the whole document: id, title, text, url and metadata. A document's text is the matching tool's own answer, so a prop plan's lists every rule with its status, the firm's page it was checked against and the date, and a rule that is not verified reads NOT VERIFIED there too; a plan's title counts its rules that are not verified.
{ "id": "prop-plan:topstep/50k" }Both answer with structuredContent and, as the guide asks, the same value as JSON text. Each declares its output shape (outputSchema). A plan without a page of its own on algolift.ai is cited to its firm's page. The ids are prop-firms, prop-firm:<firm>, prop-plan:<plan id>, indicator:<id>, setup-preset:<id> and setup-odds:language. The results are deterministic: the same query on the same release gives the same list.
The answers of three tools can also be drawn as a card inside the chat, on hosts that support MCP Apps (the extension io.modelcontextprotocol/ui, specification 2026-01-26):
Card | Tools | What it shows |
|
| The plans side by side (or one plan), each firm under its logo, every value with its status, the date it was checked and the firm's page; a value that is not verified is marked NOT VERIFIED |
|
| The hit rate with its 95% interval and sample, the baseline, the lift and the halves, and when the outcome happened against the baseline's interval, or by year |
Each tool names its card in its definition (_meta.ui.resourceUri); the server lists the cards with resources/list and serves them with resources/read as text/html;profile=mcp-app. A card is one self-contained HTML page: its styles, its script and the firms' logos are inline, it declares no allowed origin (_meta.ui.csp with empty connectDomains and resourceDomains), and it draws only the result the host hands it. It makes no request and calls no tool. Open in AlgoLift asks the host to open the matching page on www.algolift.ai (the plan's page, the two firms' comparison, the prop firms hub, or the Setup Odds page); the host may ask you to confirm first. The card follows the host's light or dark theme.
Hosts without MCP Apps read the text answer, which is exactly the same with or without the card: every number, status and source is in it. The MCP client matrix lists the hosts that render MCP Apps.
It does not trade, place orders, or connect to a broker or a prop firm.
It does not use an AlgoLift account and cannot see anything in one: no strategies, backtests or results.
It does not run AlgoLift's backtest engine, its robustness or prop Monte Carlo simulations, or its copilot.
It does not fetch prices or any other data: the indicators and Setup Odds compute only on the bars you pass, or on the demo bars.
It does not give advice. The prop rules are a record of published rules, which change; Setup Odds' numbers are historical frequencies, not predictions.
Where it helps, an answer ends with one pointer to the matching place on algolift.ai: testing a strategy against a firm's rules, building a strategy with an indicator, or testing a setup as a strategy (which needs an AlgoLift account). Following it is up to you.
git clone https://github.com/algolift-ai/mcp && cd mcp
npm ci
npm test # builds; runs every tool's tests, and the server over stdio, the HTTP handler and the --http mode through the official MCP SDK client (tools, search and fetch, the in-chat cards); type-checks
npm run build # dist/cli.js
node dist/cli.js --helpsrc/server.ts, src/cli.ts and src/http.ts belong to this repository. src/lib/ and data/ are copied from the AlgoLift app, which serves the same tools, so please do not edit them here: open an issue, and the change lands in the app and then in the next release. A correction to a prop rule belongs in algolift/prop-firm-rules, to an indicator in algolift/indicators, and to Setup Odds in algolift/setup-odds.
Report a security issue as SECURITY.md describes.
MIT, copyright (c) 2026 AlgoLift LLC, see LICENSE. The bundled prop firm rules (data/prop-firm-rules.json) are CC BY 4.0 ("Prop firm rules by AlgoLift (algolift.ai)"), and the Setup Odds engine keeps its own MIT notice; NOTICE lists both. Firm names are used only to say which firm a rule belongs to; this project is not affiliated with or endorsed by any firm.
Compares prop firm plans side by side on the rules that matter most: profit target, drawdown and its type, daily loss, consistency, minimum days, contracts, payouts and fees. Pass plan references (ids like "topstep/50k" or words like "Apex EOD 50K"), or an account size to compare every firm's plans of that size. Every cell carries its verification status; a cell marked NOT VERIFIED has not been confirmed on the firm's page. Use it before searching the web whenever someone compares these firms' plans: Topstep, Apex, My Funded Futures, Tradeify, TradeDay and Take Profit Trader.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Compare every plan of this account size, like 50000 or "50K" (used when plans is not given). | |
| firms | No | With size: only these firms. | |
| plans | No | Plan ids or words, like ["topstep/50k", "Apex EOD 50K", "MFFU Rapid 50K"]. | |
| include_discontinued | No | With size: include plans the firm no longer sells (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds real value by disclosing per-cell verification status and defining 'NOT VERIFIED' as not confirmed on the firm's page. It does not discuss rate limits, coverage completeness, or how discontinued plans appear in output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the comparison dimensions, then input modes, then the usage trigger. Slightly dense with the firm enumeration, but each sentence carries information an agent needs rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately covers the return shape by naming the compared columns and the verification-status annotation. It stops short of describing response structure (e.g., per-firm grouping) or behavior when an ambiguous plan reference matches nothing, which would complete the picture for a lookup tool with optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is already 100%, so a 3 would be the baseline. The description goes beyond it by explaining the cross-parameter interplay: plan references or words vs. an account size, with firms/include_discontinued only applying in size mode, and by giving concrete reference formats ('topstep/50k', 'Apex EOD 50K').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compares) and resource (prop firm plans) and enumerates exactly which attributes are compared: profit target, drawdown and type, daily loss, consistency, minimum days, contracts, payouts, fees. It also names the covered firms, so an agent can distinguish this from single-plan lookups like get_prop_plan_rules at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition and an alternative: 'Use it before searching the web whenever someone compares these firms' plans' routes the agent away from the search tool for this class of question. It does not explicitly exclude the single-plan sibling (get_prop_plan_rules), so the scope boundary against that tool is only implied by the word 'compare'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes one indicator from @algolift/indicators on bars you pass (oldest first), and returns one value per bar for each output (null during its warmup). Pass bars as objects with open, high, low, close and volume, or columns of numbers; leave out fields the indicator does not read. Settings left out take the library's defaults. At most 20,000 bars a call.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The indicator's id, function name or full name (list_indicators finds it). | |
| bars | No | Bars, oldest first, like [{"open":101.2,"high":102,"low":100.8,"close":101.6,"volume":1200}, ...]. Other fields (a time) are ignored. | |
| tail | No | How many of the last values to write in the answer's text (default all, up to 1000). | |
| columns | No | Columns of the same length, oldest first, like {"close": [101.6, 101.9, 102.4]}. | |
| options | No | Settings by name, like {"period": 20, "source": "hlc3"}. describe_indicator lists them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent and non-destructive, so the description's added value is what it says about output semantics: one value per bar per output, null during warmup, and library defaults for omitted settings. It also states a hard limit of 20,000 bars per call. It stops short of describing error behavior or what happens on malformed or short input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose comes first, then input format, then defaults, then the size limit, which is a sensible order. It is dense but carries no filler. It is on the long side for a single paragraph without sentence breaks, but every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description has to carry return semantics, and it does this: one value per bar per output and nulls during warmup. Combined with a full input schema and annotations covering safety, an agent has enough to call the tool correctly. Error handling and the exact answer shape of the tail option are left to the schema, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; every parameter already has a description, including examples and limits. The prose restates oldest-first ordering, the 20,000-bar cap and default settings, and it adds the useful hint to leave out fields an indicator does not read. That hint is real added value, but most of the rest duplicates the schema, so this stays near the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Computes one indicator from @algolift/indicators on bars you pass (oldest first)'. It also states the shape of the result (one value per bar, null during warmup). It does not name sibling tools like list_indicators or describe_indicator in the prose, so differentiation is left to the schema and tool names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what input this tool expects, but it does not say when to use this tool instead of the sibling paths for finding ids or settings; that routing only appears inside the schema text on the id and options fields. Usage is implied by the task ('pass bars, get indicator values'), not stated as a when/when-not rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One indicator from @algolift/indicators in full: what it measures, which bar fields it reads, its settings with defaults and limits, its outputs, the library and file its code was ported from (with license and every change the port made) or, for a classic, how it compares with TA-Lib, and what its values were verified against.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The indicator's id ("alma", "cdl_engulfing"), function name or full name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the lower bar applies. The description then adds real value by disclosing the depth and shape of the returned content — provenance, license, port changes, TA-Lib comparison, verification basis — which is behaviorally meaningful given no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with zero filler, front-loaded on the scoping claim ("One indicator ... in full") before the enumeration. It runs long as a comma-list of return fields, but every clause maps to an actual output category.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns, and it does so thoroughly enough for an agent to know what it will get. Only minor gaps remain, such as error behavior for an unknown id and the fact that id accepts function names or full names (left to the schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single id parameter is already fully documented, including the example ids "alma" and "cdl_engulfing". The description adds nothing about id format or accepted aliases, which is the correct baseline when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (describe) + tightly scoped resource (one indicator) and an explicit enumeration of everything returned: what it measures, bar fields, settings, outputs, provenance, verification. An agent can tell it apart from list_indicators and compute_indicator by inference, but no sibling is named outright, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: this is the tool you call to learn about a single indicator before computing it. There is no explicit when-to-use, no statement that it does not compute values (unlike compute_indicator), and no guidance on when list_indicators is the better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Setup Odds language: a setup (a condition true or false for each session, like gap > 0.5% and or15.close > or15.open) and an outcome (an event looked for later that session, like touches prior.close by 12:00, or a condition judged later). Gives the grammar, every value, window, function, operator and outcome form, the units and worked examples, or one section of them.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | One part only: grammar, values (with windows, fields and units), functions (with operators), outcomes or examples. Default all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds useful content-scope context (what is included, and that a section can be requested alone) but says nothing about return format, size, or output structure beyond the topic list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core identification of the language, followed by an enumeration of what is returned. The first sentence is long and parenthetical-dense, but every clause carries information; only minor tightening is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a single optional enum parameter, the description adequately conveys what the tool returns (the language reference, optionally one section). Nothing required to invoke it correctly is missing, though a note on how its output feeds into run_setup_odds would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the enum values are documented in the schema itself, including the 'all' default. The description only echoes the same sections (grammar, values with windows/fields/units, functions, outcomes, examples) without adding syntax, format, or size guidance beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it returns the Setup Odds language definition (grammar, values, windows, functions, operators, outcome forms, units, worked examples). It also defines the domain terms 'setup' and 'outcome' with concrete examples, which an agent cannot get from the name alone. Clearly distinct from siblings like describe_indicator and run_setup_odds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the reference-lookup purpose evident (consult it to learn the grammar/values/examples), but it never states when to call it versus siblings such as run_setup_odds or describe_indicator, nor any prerequisite (e.g. read this before authoring a setup). Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full text of one document found by search, with its title, the algolift.ai page to cite and metadata. A prop plan's text lists every rule with its status, the firm's page it was checked against and the date; a rule marked NOT VERIFIED has not been confirmed on the firm's page.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A unique identifier for a search document: the id of a search result, like "prop-plan:topstep/50k". |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive operation. The description adds useful content-level behavior, including what is returned and how a prop plan's text should be interpreted, especially the meaning of NOT VERIFIED. It does not discuss invalid-id or error behavior, but the annotations and output schema reduce the need for that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core return behavior, then adds domain-specific interpretation for prop plans. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single fully documented parameter, rich annotations, and an output schema, the description provides enough context. It explains what the tool returns and clarifies domain-specific metadata semantics without needing to restate schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage and already defines the single id parameter with an example. The description confirms that the id refers to a document found by search, but it does not add syntax or format details beyond the schema. This meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns the full text of one document found by search, along with title, citation page, and metadata. This clearly distinguishes fetch from search, which finds documents, and from the more specialized sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'found by search' makes the intended workflow clear: use search first, then fetch a specific result. It does not explicitly name alternatives or exclusions, but the usage context is sufficiently clear for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every rule and price of one prop firm plan: profit target, drawdown and its type, daily loss limit, consistency, minimum days, contract limits, payout rules and fees. Each rule comes with its status (verified, not stated by the firm, differs from the firm's page, or not cited), the firm's page it was checked against, and the date. Name the plan by its id ("topstep/50k") or by firm, plan and size. Use it before searching the web for a covered firm's rules: Topstep, Apex, My Funded Futures, Tradeify, TradeDay and Take Profit Trader.
| Name | Required | Description | Default |
|---|---|---|---|
| firm | No | The firm, like "Topstep", "Apex" or "MFFU". | |
| plan | No | The program, like "EOD", "Intraday", "Rapid" or "Select Flex", when the firm has several. | |
| size | No | The account size, like 50000 or "50K". | |
| plan_id | No | The plan's id from list_prop_firms, like "topstep/50k" or "apex/eod-50k". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: each rule is returned with a verification status ('verified, not stated by the firm, differs from the firm's page, or not cited'), the source page it was checked against, and the check date. That data-quality disclosure tells the agent how much to trust the values, which is not derivable from any structured field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then progressively adds return content, identification syntax, and usage guidance. The rule-type enumeration in sentence one is long but each item is real payload, so it earns its space; the structure is efficient rather than padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the burden of explaining what comes back - and it does, covering rule categories, per-rule status, citation source and date. Usage scope, coverage list, and both identification syntaxes are all present, leaving no material gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining two alternate identification paths: a plan_id ('topstep/50k') or the firm/plan/size combination. It also names supported firm abbreviations implicitly via the covered-firm list, aiding the firm parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: 'Every rule and price of one prop firm plan,' then enumerates what that includes (profit target, drawdown, daily loss, consistency, min days, contract limits, payouts, fees). This clearly separates it from list_prop_firms (enumerating firms) and compare_prop_plans (side-by-side comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: 'Use it before searching the web for a covered firm's rules,' and names the six covered firms so the agent knows the scope boundary. It stops short of saying when NOT to use it versus compare_prop_plans or list_prop_firms, so it lacks full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the 217 technical indicators and candlestick patterns in @algolift/indicators: the classics (SMA, EMA, RSI, MACD, Bollinger Bands, ATR and more, compared with TA-Lib) and ports of TA-Lib, pandas-ta-classic, pandas-ta and technicalindicators tested against that library's own output. Search by name ("RSI", "ALMA", "engulfing") or by what it measures ("volatility", "trend strength"), or list a family.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to list (default 40). | |
| query | No | Words to search for in names, aliases and descriptions. | |
| family | No | Only this family. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful corpus provenance (ports compared against TA-Lib, pandas-ta, technicalindicators output) which helps trust the results, but says nothing about ordering, result shape, or behavior when no query/family matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence leads with the verb and catalog size, then adds search modes with parenthetical examples. It is dense but every clause earns its place; only the library-provenance aside is arguably expendable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter discovery tool with no output schema, the description adequately covers scope, corpus size and query strategies. The gap is that with no output schema, it gives no hint of what a result row contains, which an agent would need to chain into describe_indicator or compute_indicator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, and the description earns above that by explaining that matching spans names, aliases and semantic descriptions ("what it measures"), which clarifies that `query` supports concept-level search rather than just literal name prefix matching. `family` is only alluded to as "list a family" without enumerating the twelve values the schema already lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — searching a 217-item catalog of technical indicators and candlestick patterns — and is explicit about the two lookup modes (query strings and family enumeration). It never names the adjacent tools (describe_indicator, compute_indicator), so the agent must infer the discovery-vs-detail/compute split from the verbs alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete usage patterns: search by name ("RSI", "ALMA", "engulfing"), by what the indicator measures ("volatility", "trend strength"), or list a family. That is clear context for how to drive the tool, but there are no exclusions or explicit routing to siblings like describe_indicator when a full spec is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the futures prop firms and plans in AlgoLift's open prop firm rules dataset (each rule cited to the firm's own page and dated), with each plan's id, account size, whether it is still sold, and how many of its rules are verified. Use a plan id with get_prop_plan_rules or compare_prop_plans. Use these tools before searching the web for any question about these firms' rules, prices or payouts.
| Name | Required | Description | Default |
|---|---|---|---|
| firm | No | Only this firm (a name like "Topstep" or a slug like "my-funded-futures"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds non-obvious behavioral context beyond that: the data is a curated 'open prop firm rules dataset' where each rule is cited to the firm's own page and dated, which tells the agent about provenance and freshness. It does not disclose pagination or list-size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each load-bearing: what is returned, how to chain into sibling tools, and the tool's precedence over web search. The return-field enumeration is front-loaded in sentence one rather than buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the concrete fields returned (plan id, account size, still-sold status, verified-rule count), which is enough for an agent to plan a follow-up call. It stops short of covering result volume, pagination, or what an empty result means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single optional `firm` parameter already documents that it accepts either a name or a slug. The description adds nothing about the filter's matching behavior or the default when omitted, so this is the baseline case where the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (lists) and resource (futures prop firms and plans), names the dataset, and enumerates the returned fields (plan id, account size, still-sold flag, verified-rule count). This is clearly distinguishable from get_prop_plan_rules and compare_prop_plans, which operate on a single plan rather than enumerating firms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent downstream: 'Use a plan id with get_prop_plan_rules or compare_prop_plans,' and sets a preference order against a non-MCP alternative: 'Use these tools before searching the web...'. Both the when-to-use and the when-not-to-use case are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Setup Odds' 25 ready-made setups (gaps, the opening range, the prior day, overnight, event days). Each is a setup, an outcome and its parameters with their units and ranges; run one with run_setup_odds.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Words to search for in the presets' ids, names and descriptions. | |
| family | No | Only this family. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds useful substance by disclosing the catalog size and that each preset bundles a setup, an outcome, and parameters with units and ranges. It stops short of noting that filtering reduces the 25 returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with the catalog identity front-loaded and the follow-up action last. The family enumeration is slightly redundant with the schema enum but earns its place as a quick orientation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns, which it does by describing the shape of a preset (setup, outcome, parameters with units and ranges). What's missing is only the minor detail that query/family filters narrow the list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both the free-text 'query' and the 'family' enum. The description's parenthetical family list mirrors the enum without adding filtering semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists Setup Odds' 25 ready-made setups') and enumerates the families covered (gaps, opening range, prior day, overnight, event days). This clearly separates it from sibling listers like list_prop_firms and list_indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent forward: 'run one with run_setup_odds,' establishing that this tool is the discovery step before execution. It does not, however, say when to prefer this over search or fetch, so the exclusion side is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How often did this setup actually work? Runs one Setup Odds preset, or a setup and an outcome, on 1-minute bars and returns the engine's result: the sessions that met the setup and how many saw the outcome, with the rate and its 95% Wilson interval, the baseline over every measured session and the lift, a first-half and second-half split, counts by year, the time to the event, and every warning. Pass your bars (a list or CSV text) or demo (the engine's synthetic bars, not market data). Every time is New York time on the CME equity-index futures calendar. At most 2,000,000 bars, 2,600 sessions and 10 seconds a call. Historical frequencies, not predictions or advice.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last trading day, YYYY-MM-DD. | |
| tz | No | The zone of CSV or list times with no offset: America/New_York (default), America/Chicago, UTC or an offset like -05:00. | |
| csv | No | 1-minute bars as CSV text: a header with timestamp (or date and time), open, high, low and close, and optionally volume. | |
| tie | No | How A before B counts when both first happen in the same minute bar (default miss). | |
| bars | No | 1-minute bars, any order, like [{"time":"2024-03-08 09:30","open":5130.25,"high":5132,"low":5129.5,"close":5131.75,"volume":1200}]. | |
| demo | No | Use the synthetic demo bars ({} for the defaults: seed 1, 2023 and 2024). NOT market data. | |
| from | No | First trading day, YYYY-MM-DD. | |
| label | No | A name for the bars, like "ES 2024". | |
| setup | No | Which sessions: a condition, like gap > 0.5%, or all. | |
| stamp | No | Whether a bar's time is its open (default) or its close. | |
| params | No | Values for the $parameters, like {"gap": 0.5}. | |
| preset | No | A preset id from list_setup_presets, instead of setup and outcome (or with them, to rewrite one of its texts). | |
| outcome | No | What happened later that session, like touches prior.close by 12:00. | |
| tick_size | No | The tick size, for a setup or outcome written in ticks. | |
| instrument | No | Named in the strategy request the answer links to, like ES. | |
| min_coverage | No | The share of regular-hours minutes a session's bars must cover to count (default 0.8). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the readOnly/idempotent/destructive annotations: hard limits (2,000,000 bars, 2,600 sessions, 10 seconds per call), the New York time / CME equity-index calendar convention, that demo bars are synthetic and 'NOT market data', and that results are historical frequencies, not predictions. This is genuinely useful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and each clause carries real information (limits, timezone, return fields). It is long and somewhat run-on, but for a 16-parameter tool with no output schema the density is justified; only minor tightening is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the full result surface (rate, 95% Wilson interval, baseline, lift, first/second-half split, per-year counts, time to event, warnings) which compensates for the absent output schema, plus input forms, limits and the time calendar. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds relationship semantics the schema can't express: preset substitutes for setup+outcome or can rewrite one of its texts, and bars may be a list or CSV text. These go beyond the per-field schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete verb and resource: runs a Setup Odds preset or a setup+outcome pair over 1-minute bars. It also distinguishes itself from the preset-listing sibling by saying the preset id comes from list_setup_presets, so an agent can route correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear input paths ('Pass your bars ... or demo') and clarifies the preset-vs-setup/outcome relationship ('instead of setup and outcome (or with them, to rewrite one of its texts)'). It does not state when to prefer this over siblings like compute_indicator or search, so it stops short of explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches AlgoLift's open content and returns matching documents, each with an id, a title and the algolift.ai page to cite: futures prop firms and their plans' rules (each rule with its verification status, source and date), the technical indicators of @algolift/indicators, and Setup Odds' presets and query language. Use fetch with a result's id to read the whole document.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A single query string, like "Topstep 50K drawdown", "RSI" or "gap fill by noon". |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, and non-open-world behavior, so the description earns credit for the additional detail it supplies: the shape of each result (id, title, citable algolift.ai page) and the dependency that fetch needs a result id. It stops short of noting match semantics, ranking, or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and return shape before the follow-up guidance; every clause carries information. The middle enumeration is dense but relevant, sacrificing a little readability for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich input schema, full annotations, and an output schema that already documents returned fields, the description supplies everything additionally needed: the scope of searchable content and the fetch-with-id workflow. Nothing required 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single query parameter already carries three concrete examples, so the schema does the heavy lifting. The description implies the query may span rule names, indicator names, and natural-language phrases but adds no syntax, format, or length constraints beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (searches) plus the resource (AlgoLift's open content) and enumerates the covered domains: prop firm rules, @algolift/indicators, and Setup Odds presets/query language. This lets an agent distinguish it from structured siblings like list_prop_firms, list_indicators, or list_setup_presets without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to follow up with fetch using a result's id, which is a clear next-step usage rule. However, it gives no guidance on when to prefer this tool over the sibling list_*/describe_* tools for the same content domains, so the alternative-selection context is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0compare_prop_planscompute_indicatordescribe_indicatordescribe_setup_query_languagefetchget_prop_plan_ruleslist_indicatorslist_prop_firmslist_setup_presetsrun_setup_oddssearchScored across 11 tools
Each tool targets a distinct resource+action, and the three domains (prop firms, indicators, setup odds) each have a clean list/describe/compute-style triad. search and fetch are explicitly framed as cross-cutting fallbacks, so they don't collide with the domain tools.
Nearly everything follows a consistent verb_noun snake_case pattern (list_prop_firms, get_prop_plan_rules, compare_prop_plans, list_indicators, compute_indicator, run_setup_odds). The only deviations are the bare single-word verbs search and fetch, which are minor and conventionally generic.
11 tools is well within a healthy range and each one earns its place: three coherent triads for the three domains plus two generic retrieval tools. No redundancy or padding.
Coverage is strong: firms/plans can be listed, inspected and compared; indicators listed, described and computed; setups listed, described and executed; plus search/fetch for full documents. Minor gaps remain around lifecycle operations (e.g. no rule-change history or plan filtering), but core agent workflows are covered.
AI-powered Pine Script v6 strategy generator built for prop-firm futures traders.
Free, read-only directory of 114 AI trading tools: broker MCP servers, market data APIs, bots and backtesters. Sourced facts on who can place orders and what safeguards exist; search, compare and check order gating for every broker MCP.
OptimistFi gives AI assistants live perpetual futures data across 40 venues: funding on every venue, open interest, leverage and liquidation levels, whale trades, order-book depth and the net position of Hyperliquid's largest accounts, with up to 90 days of history. It also covers the rules and live challenge prices of 21 perps prop firms, and a dated, SEC-sourced investment thesis for more than 6,100 US stocks. Public and read-only: no key, no sign-up. Every answer names its source and time.
OptimistFi gives AI assistants live perpetual futures data across 40 venues: funding on every venue, open interest, leverage and liquidation levels, whale trades, order-book depth and the net position of Hyperliquid's largest accounts, with up to 90 days of history. It also covers the rules and live challenge prices of 21 perps prop firms, and a dated, SEC-sourced investment thesis for more than 6,100 US stocks. Public and read-only: no key, no sign-up. Every answer names its source and time.
