2027 rankings of trading schools and prop firms, every criterion sourced, plus market data
Scored across 9 tools
Each tool has a distinct role: search finds entities, get_rankings lists rankings, get_school/get_prop_firm fetch single-entity detail, and compare performs side-by-side comparisons. The methodology, market figures, recent changes, and Tradoshi facts tools cover clearly separate information needs.
Most names follow a predictable verb_noun pattern such as get_school, get_rankings, and search_entities, all in snake_case. The only minor deviation is compare, which is verb-only rather than verb_noun, but it remains clear and consistent with the action-oriented style.
Nine tools is well scoped for a read-only rankings and research server. Each tool covers a meaningful capability without bloating the surface with redundant operations.
The surface covers discovery, detailed entity retrieval for both schools and prop firms, rankings pages, side-by-side comparison, methodology, market data, recent changes, and Tradoshi's own facts. For a read-only research domain, this provides a complete lifecycle without obvious dead ends.
Side by side ratings of two trading schools or two prop firms of the Tradoshi 2027 rankings.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so safety is fully covered elsewhere. The description contributes only the scope constraint (2027 rankings) and the same-type requirement; it says nothing about what happens when an entity is not in the rankings or what the returned comparison contains.
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 with no filler or redundancy. Its brevity is appropriate in form, though it leaves several real questions unanswered (handled under other dimensions).
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?
All three parameters are required and undocumented in the schema, and there is no output schema to fall back on. For a tool that takes free-form identifiers, the definition should at minimum state the expected identifier format and the shape of the returned comparison; neither is present.
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 0%, so the description carries the full burden, and it only partially pays it: 'two schools or two prop firms' clarifies that a and b are the same type, but never says whether a/b are names, slugs, or IDs, nor how the type enum relates to them. Two of three parameters remain opaque in both schema and description.
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 concrete outcome — side-by-side ratings of two entities of the same kind (school or prop firm) drawn from the Tradoshi 2027 rankings. It is implicitly distinct from get_school/get_prop_firm (single-entity lookups) via the 'two ... side by side' framing, but never names a sibling explicitly.
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 'of the Tradoshi 2027 rankings' usefully scopes which entities are valid inputs, and 'two schools or two prop firms' implies you cannot mix types. Beyond that, it gives no explicit when-to-use vs. when-not guidance and never points at get_school, get_prop_firm, or search_entities as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Size of the trading journal market, paying subscribers, leader's share and retained growth rate, from the Tradoshi Observatory study.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that figures come from a specific Observatory study, hinting at a static published snapshot, but it never states whether the numbers are cached/fixed or refreshed, which matters for a market-statistics call.
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 sentence that front-loads the returned metrics with no filler. It is a noun fragment rather than a full clause, but every element 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?
For a zero-parameter read-only getter with full annotation coverage and no output schema, the description adequately enumerates the return contents and names the source. Only the freshness/vintage of the figures is left unstated.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter semantics are needed or missing.
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 names the concrete metrics returned (market size, paying subscribers, leader's share, retained growth rate) and the source study, so an agent knows exactly what data this yields. It lacks an explicit contrast with near-neighbors like get_tradoshi_facts or get_rankings, which keeps it from 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?
There is no statement of when to call this versus get_tradoshi_facts, get_rankings, or get_methodology, and no prerequisites or exclusions. The only guidance is implicit in the metric list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pillars, weights and criteria of the Tradoshi 2027 ranking of trading schools or of prop firms, with the link to the full methodology.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds that the response includes a link to the full methodology, which is genuinely useful context, but says nothing about response shape or whether both ranking types can be retrieved together.
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 sentence with no filler; the substantive content (pillars, weights, criteria, methodology link) is front-loaded and the qualifier about ranking type follows naturally.
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 one-parameter, read-only lookup with no output schema, the description conveys what the caller gets back and the scope of each ranking type. Only minor gaps remain — whether the methodology is shared across both types and the exact return structure.
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 0%, so the description must compensate — and it does partially by phrasing the resource as covering 'trading schools or of prop firms', which maps directly onto the schools/prop_firms enum. It still does not state that the parameter is required or what happens if omitted.
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 names a specific resource — pillars, weights and criteria of the Tradoshi 2027 ranking — plus the methodology link, which is far more informative than the title alone. It does not explicitly contrast itself with siblings like get_rankings, but the resource is distinctive enough to distinguish it.
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: an agent can infer it should call this when it needs to explain or justify how a ranking was produced. There is no explicit when-to-use statement, no mention of when not to call it (e.g. use get_rankings for actual scores), and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Tradoshi 2027 rating of a prop firm: score out of 100, international and market ranks, pillars, trading platforms, rated programme and price of a $100,000 account, regulator warnings, and each criterion with its evidence, source URL and the date it was read.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Prop firm slug, from search_entities or get_rankings |
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 credit goes to the added substance: the description discloses that each criterion ships with its evidence, source URL and the date it was read, which tells the agent about provenance and freshness. It is still silent on what happens with an unrated or unknown slug, and there is no output schema to fall back on.
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?
It is a single front-loaded sentence that names the rating and then lists what comes back, with no filler or preamble. The mid-sentence enumeration of payload items is dense but each item conveys a distinct piece of returned data; only the trailing 'each criterion with its evidence' clause drifts toward verbosity.
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 return values and does so well, including provenance metadata. For a simple one-parameter read tool that is nearly sufficient; only the behavior for unknown or unrated slugs is left unstated.
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?
There is a single parameter with 100% schema description coverage, and that schema already explains the slug format and its sources (search_entities, get_rankings). The description adds nothing about the slug, so the baseline 3 applies rather than a 4 reserved for a zero-parameter tool.
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 title plus description clearly identify the resource as a single prop firm's Tradoshi 2027 rating, and the description enumerates the payload (score, ranks, pillars, platforms, programmes, price, warnings, criteria evidence). An agent can distinguish this from get_rankings or compare at a coarse level. It stops short of an explicit 'retrieve the rating for one firm by slug' verb, so sibling differentiation is only implicit.
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 never says when to call this versus get_rankings, compare, or search_entities, nor any precondition (e.g., the firm must be rated). The only routing hint lives in the slug parameter's schema description, which is outside the description and easy for selection to miss. Nothing states exclusions or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A page of the Tradoshi 2027 ranking of trading schools (filter by country or continent) or prop firms (filter by market: futures, forex-cfd, crypto, stocks, by trading platform: ctrader, mt5, match-trader, tradovate…, or by country).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| limit | No | ||
| market | No | ||
| offset | No | ||
| country | No | ISO 3166-1 alpha-2 code | |
| platform | No | Prop firms only: trading platform offered, for example ctrader, mt5, match-trader | |
| continent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds a little beyond that — 'a page of' signals pagination and the dataset is scoped to the 2027 ranking — but it does not explain ordering, rank semantics, or how limit/offset interact with the result.
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?
One dense sentence with no filler, and the primary resource is front-loaded. The nested parentheticals (filter by market: ... by platform: ...) make it harder to scan than it needs to be, but nothing is wasted.
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 7-parameter, no-output-schema listing tool, the description covers what the resource is and which filters apply where, but omits pagination behavior, ordering/rank basis, and what a ranking entry contains. An agent could call it correctly, but not predict the shape or order of results.
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 only 29%, so the description must compensate, and it does so partially: it spells out the type gating (schools vs prop_firms) and enumerates market values and platform examples (ctrader, mt5, match-trader, tradovate) and confirms country/continent filtering. It says nothing about limit or offset, leaving two pagination parameters undocumented in both schema and description.
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 names a specific resource (the Tradoshi 2027 ranking of trading schools and prop firms) and a specific operation (returning a page, filtered). It is distinguishable from get_school/get_prop_firm detail lookups and from search_entities, though it never names those siblings explicitly.
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 implied rather than stated: the parentheticals tell you which filters apply to which type (schools by country/continent, prop firms by market/platform/country), which is useful conditional guidance. However, there is no explicit 'use this instead of X' or when-not guidance relative to compare, search_entities, or get_methodology.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dated changes: new features of the Tradoshi trading journal (product changelog) and changes to prop firm ratings in the Tradoshi 2027 ranking (score, rank and each criterion before and after).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | all | |
| limit | No | ||
| since | No | Only changes on or after this date, YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful content-level context (that prop-firm entries carry score, rank, and each criterion before and after), but says nothing about ordering, pagination, or whether results are deduplicated per entity.
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 no filler, front-loading the key framing ('Dated changes') before enumerating the two streams. Slightly run-on with nested parentheses, but every clause carries informational weight.
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 must carry the return-shape burden; it does a fair job by describing before/after criterion fields, but leaves result ordering, item structure, and pagination semantics unexplained. For a 3-parameter read tool this is adequate but not sufficient.
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?
Only 33% schema coverage — 'since' is documented in the schema while 'type' and 'limit' are not. The description effectively explains the two meaningful values behind the type enum (product changelog vs. prop-firm rating changes), which partially compensates, but it never mentions the limit cap or what the returned date ordering means.
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 names the exact resource: a dated changelog covering two distinct content streams (product features and prop-firm rating revisions in the Tradoshi 2027 ranking), and clarifies that rating changes include before/after values per criterion. That is specific enough to separate it from siblings like get_rankings or get_prop_firm (current state vs. changes), though it never states the verb ('retrieve') explicitly.
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?
There is no guidance on when to choose this over get_rankings, get_prop_firm, or compare — the agent must infer that 'changes' means deltas over time rather than current values. No prerequisites, no exclusions, no mention of how the type filter relates to the two content streams described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Tradoshi 2027 rating of a trading school: score out of 100, international, continental and national ranks, pillars, rated programme, regulator warnings, and each criterion with its evidence, source URL and the date it was read.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | School slug, from search_entities or get_rankings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the returned payload structure (score, ranks, pillars, warnings, per-criterion evidence and read date), but says nothing about behavior on an unknown slug, auth needs, or freshness/pagination.
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?
One front-loaded sentence that leads with the resource and rating year, then lists payload contents. The field enumeration is long but each item is informative, so it 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?
With no output schema, the description must carry the return-value burden and does so thoroughly by enumerating score, ranks, pillars, warnings and evidence provenance. The remaining gap is failure/edge-case behavior for a missing or unknown slug.
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 slug parameter is already documented with its source (search_entities or get_rankings). The description adds no further meaning about the slug format or validity, so the baseline of 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?
The description names a specific resource (a trading school's Tradoshi 2027 rating) and enumerates exactly what the payload contains, which cleanly separates it from get_prop_firm and get_rankings. It lacks an explicit verb like 'retrieve' and never names a sibling, so it is clear but not maximally differentiated.
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?
There is no statement of when to call this versus get_rankings, compare, or get_prop_firm, and no exclusions. The only workflow hint ('slug, from search_entities or get_rankings') lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The official facts about Tradoshi, the trading journal publishing these rankings: legal entity and company number, public launch date, platforms, languages, number of supported brokers, plans and prices, trial, payment methods, with the date they were checked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 does add one piece of genuine context beyond that — that facts carry 'the date they were checked' — but says nothing about output shape or limitations.
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 naming the resource first, then the payload. The comma-separated inventory is dense but each item maps to a real returned datum, so little is wasted, though the list-driven style reads more like a field dump than guidance.
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 enumeration of facts is doing real work in telling the agent what comes back, and the zero-parameter contract means no invocation detail is needed. What remains thin is not content but the decision layer — when to prefer this over the sibling fact/entity tools.
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?
With zero parameters and 100% schema coverage, there is nothing for the description to disambiguate. It does usefully enumerate the fields an agent will receive, which is return-value detail rather than parameter semantics.
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 resource (official facts about Tradoshi, the publisher of these rankings) and enumerates the exact contents, so an agent can distinguish it from get_methodology or get_market_figures. It is clear what the tool returns, though the description is a content list rather than a verb-led statement of action.
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: an agent infers it should call this when it needs entity/company background. There is no explicit 'use this when' clause and no mention of alternatives among the eight siblings, so routing depends on the agent reading the content list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find trading schools and prop firms by name in the Tradoshi 2027 rankings. Returns slugs to use with get_school or get_prop_firm.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Part of the name, at least 2 characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive search. The description adds useful context that it searches the 2027 rankings and returns slugs, but it does not explain result ordering, limits, empty/no-match behavior, or matching semantics beyond name.
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 purpose and followed by the useful downstream routing detail. There is no redundant or wasted language.
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 simple one-parameter search tool with full schema coverage and strong annotations, the description provides enough to invoke it correctly and understand its role. It could be slightly more complete about return shape or no-result behavior, but it is adequate overall.
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 schema fully documents the single q parameter, including that it should be part of the name and at least two characters. The description reinforces that matching is by name, but adds no syntax or behavioral detail beyond the schema.
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 uses a specific verb and resource: find trading schools and prop firms by name within the Tradoshi 2027 rankings. It also clarifies the tool's role relative to get_school and get_prop_firm by explaining that it returns slugs for those detail 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?
It clearly implies the tool should be used to resolve a name into a slug before calling get_school or get_prop_firm. It does not explicitly describe when not to use it or mention alternatives such as get_rankings, but the intended workflow is clear.
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.
compareget_market_figuresget_methodologyget_prop_firmget_rankingsget_recent_changesget_schoolget_tradoshi_factssearch_entitiesIndependent rule and fee data on 71 prop trading firms, every figure with its evidence state.
Honest A-F grades for trading strategies, backtested on real out-of-sample data. No hype.
27 live market-research tools for trading agents: scans, options flow, sentiment, valuation, alerts
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.
Add one secure layer between your agents and this server.
