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.
Scored across 10 tools
Most tools have a clear lane (search_tools, list_category, compare_tools, get_incidents, get_leaderboard), but 'check', 'get_risk' and 'get_tool' all answer 'is this thing safe?' for a single tool and their returned fields overlap heavily (worst case, key custody, incident record). 'check' vs 'check_setup' is only distinguishable by the batch/single distinction buried in long prose. The verbose descriptions do enough disambiguating work to keep an agent from total confusion, but boundaries are blurry.
Eight of ten names follow a verb_noun or verb_resource pattern (get_tool, get_risk, list_category, search_tools, compare_tools, check_setup, get_incidents). The deviations are 'check' (bare verb, no object) and 'broker_order_gating' (a noun phrase describing a policy rather than an action verb). Both are still readable, so the inconsistency is minor rather than structural.
Ten tools is well within the sweet spot for a research/verification directory server. Each tool covers a distinct access pattern (lookup by id, search, enumeration, comparison, batch audit, external news, rankings) and none feels like filler. No obvious duplicate or padded surface.
Coverage is strong for the stated domain: discovery (search_tools, list_category), retrieval (get_tool, get_risk), verification (check, check_setup, compare_tools), context (get_incidents, get_leaderboard) and policy (broker_order_gating). Minor gaps remain: no reverse lookup from an incident or leaderboard entry back to its tool record, and no way to extend a setup check beyond the 8-item cap, but these are workaroundable.
Who places the order for every official broker MCP server: AI trades directly, you confirm each order, approval optional, or you place the order.
| 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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the substantive content (the four order-gating modes), which is useful, but says nothing about the return format or how the modes are presented.
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, and the subject (who places the order) is front-loaded. The colon-separated enumeration of four modes is dense but readable; it borders on being a run-on list.
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 parameters, no output schema, and full annotation coverage, the description only needs to convey scope and return shape. Scope is conveyed, but with no output schema the description should indicate what the agent gets back (a mode list, a config, prose); that gap leaves it adequate but incomplete.
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 the baseline of 4 applies. The description has no parameter semantics to explain and correctly does not invent any.
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 topic — who places orders for official broker MCP servers — and enumerates four gating modes (AI trades directly, user confirms, approval optional, user places). However it lacks a clear verb such as 'describes' or 'lists', so an agent cannot tell whether this returns a configuration, a list of modes, or documentation text. It is topical but not operationally precise.
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 tool, no prerequisites, and no reference to the sibling tools (get_tool, search_tools, compare_tools) that might be alternatives. The agent must guess the triggering context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check before connecting (TAS Check): give a name, link, Telegram or X @handle, GitHub repo or app-store link of a Telegram trading bot, web trading terminal, exchange, swap service or wallet (incl. Zcash/Monero wallets). Returns whether the link is on that service's official list (confirmed from two independent places), a known fake, or a lookalike that uses its name, plus the worst case for your money, who holds the keys, freeze/hold policy, what a leaked API key can do, Monero/Zcash support, what the service collects about you and any data breaches, incidents, deadlines and a 3-step safe setup, each with sources. For a hardware wallet (by name, maker or website: Ledger, Trezor, Coldcard, OneKey, BitBox, Tangem, Keystone, Jade, Passport, CoolWallet) it also returns the custody score from tradingagentstack.com/custody/. For a shop, it says which maker names it on its own authorized-reseller list (Ledger, Trezor, BitBox, CoolWallet), flags marketplaces, and flags shops whose reseller authorization was revoked. Unknown links are reported as unknown, never as safe.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | e.g. 't.me/solana_trojanbot', 'bananagun.io', '@krakenfx', 'github.com/cake-tech/cake_wallet', 'Kraken' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), so the description correctly spends its words elsewhere: it discloses a false-positive policy ('Unknown links are reported as unknown, never as safe'), that confirmation requires two independent sources, and the substantive answer fields (key custody, freeze policy, leaked-API-key impact, breach history). It does not discuss latency, coverage limits per service, or why openWorldHint is false for what reads like an external-list lookup.
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 intent is front-loaded in the opening clause, which is good, but the remainder is one dense run-on sentence that stacks hardware-wallet brand lists and shop-reseller enumerations inline. Much of that is genuinely informative, yet the wall-of-text structure makes it hard to scan and would benefit from splitting into purpose, coverage, and return-value blocks.
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 carries the full burden of describing return values, and it does so thoroughly: verdict types, risk/custody fields, Monero/Zcash support, breach and incident data, deadlines, a 3-step setup, and source attribution. For a one-parameter lookup of this complexity, an agent has enough to call it correctly and interpret the response.
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% and the single parameter is required, so the schema already carries the baseline. The description still adds real meaning by enumerating the accepted input forms beyond the schema example: bare name, URL, Telegram or X @handle, GitHub repo, app-store link, and for shops a maker or website.
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?
Despite the generic name 'check', the description states a specific verb plus resource population: it vets trading bots, terminals, exchanges, swap services, wallets and hardware-wallet shops by name/link/handle. It also distinguishes scope from siblings by naming what it returns (official-list confirmation, fake/lookalike verdict, custody score, reseller authorization) rather than overlapping with get_risk or get_tool.
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?
'Check before connecting' gives a clear trigger point for invocation, and the covered entity list implies the boundary of what it can be used on. It stops short of naming alternatives (e.g. when to prefer get_risk or check_setup) or stating exclusions, so it is clear context without explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a whole setup at once: up to 8 bots, exchanges, wallets, swap services or AI trading connectors someone uses (names, links, @handles or slugs). For each: who holds the keys, the worst case, who places orders, the Safety score, incidents in the last 12 months and the first fix, each from the dataset. Also returns the single biggest risk by a fixed rule, items we don't track (reported as unknown, never as safe), and a report_url that opens the same report on tradingagentstack.com. Links that use a tracked name but aren't official are flagged.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | e.g. ['Phantom', 'Trojan', 'Binance', 'Alpaca MCP server'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description discloses substantive behavior: per-item return fields, the single biggest-risk rule, unknown items reported as unknown rather than safe, a report_url, and flagging of unofficial links using tracked names. These are useful behavioral details an agent would not get from annotations alone.
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 dense sentences, front-loads the core action and scope, and uses the remainder to enumerate outputs and edge-case handling. Every sentence adds useful information without padding.
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?
Although there is no output schema, the description explains the return shape well enough for an agent to understand the result: per-item risk/safety fields, a top overall risk, unknown handling, a report URL, and unofficial-link flags. Annotations cover the safety profile, so no critical behavioral gap remains.
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 schema already defines the `items` array and maxItems. The description adds meaningful semantics by explaining that entries may be names, links, @handles, or slugs covering multiple item types, which is not fully conveyed by the schema example.
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 gives a specific verb-resource pair ("Check a whole setup at once") and scopes it to up to 8 bots, exchanges, wallets, swap services, or AI trading connectors. The phrase "whole setup at once" also distinguishes it from a singular check tool.
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 clearly signals when to use this tool: for evaluating an entire multi-item setup rather than a single item. It does not explicitly name the sibling `check` tool or state exclusions, so it falls short of the highest usage-guidance level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two tools side by side, field by field, with sources.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_a | Yes | ||
| slug_b | Yes |
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 'field by field, with sources', a useful hint about comparison granularity and provenance, but says nothing about output shape, limits on which tools can be compared, or failure 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?
A single tight sentence with the verb and scope front-loaded and zero filler. The terseness is efficient rather than repetitive, though it leaves the definition thin overall.
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 must carry the return-value burden; 'field by field, with sources' gestures at it but does not describe the structure. Combined with undocumented slug parameters and no usage routing versus get_tool, this is minimum-viable rather than complete.
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% for both required parameters, and the description does not compensate: it never explains what a 'slug' is, how to obtain one, or whether the two slugs must differ. The term 'slug' is the only implicit semantic hint.
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?
Clear verb ('compare') plus resource ('two tools'), with scope qualifiers 'side by side, field by field, with sources'. This is distinct from its siblings (get_tool, search_tools, list_category), but the description never names or contrasts them 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?
No statement of when to prefer this over calling get_tool twice, nor any prerequisites for the comparison. The usage is only implied by the verb 'compare'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Security incidents involving AI agents, trading tools and the infrastructure they run on (breaches, exploits, security releases), each from an official disclosure. Filter by date, or by a listed tool or a bot, exchange or wallet tracked by check.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Only incidents for this tool or service (slug or name), e.g. 'alpaca-mcp-server', 'Keystone', 'Bloom' | |
| since | No | Only incidents 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuine value by disclosing provenance (every incident comes from an official disclosure), but says nothing about result volume, ordering, or recency 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?
One sentence that front-loads the resource and then the filters; nothing is wasted. The nested parentheticals and the 'bot, exchange or wallet tracked by check' clause make it slightly denser than ideal, but no sentence is 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?
A simple two-optional-param read tool with full schema coverage and complete annotations needs little more. With no output schema, though, the description never hints at what an incident record contains (fields, count, ordering), leaving the agent to discover the return shape by calling it.
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 both params are already documented with formats and examples; baseline is 3. The description adds only a mild hint that the `tool` filter also accepts bots, exchanges and wallets, which is not evident from the parameter name alone but is not spelled out either.
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 (security incidents involving AI agents, trading tools and infrastructure) and a clear scope of what counts as an incident (breaches, exploits, security releases) sourced from official disclosures. No sibling covers this domain, so differentiation is implicit rather than stated, which keeps it just short of 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?
The description implies usage by describing the two filter modes (date, tool/bot/exchange/wallet), and references the `check` sibling for tracked entities, giving a partial routing hint. It never states when not to use it or what alternative covers related needs (e.g. get_risk, search_tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified performance leaderboard for AI trading agents, bots and vaults: return, BTC over the same dates, max drawdown and Sortino ratio, computed by TradingAgentStack from the venue's public API (never screenshots, self-reported PnL or backtests), with security rated separately as a gate. Sections: ai_vaults (Hyperliquid vaults whose leader says they are AI-run, with the quoted claim), vaults (biggest Hyperliquid vaults of any strategy), agents (AI agents with an officially published trading account or on-chain registration), apps (AI trading apps on Hyperliquid: users, volume and users' realized PnL from public builder fills), models (which AI model forecasts and trades best: ForecastBench, Prophet Arena, Alpha Arena, FutureEval), signals (grade B: MQL5 robot signals on real accounts, venue-reported, not ranked), usage (fees users pay Telegram bots, trading apps and AI agent protocols, and open-source repo health). Ranked vaults passed a 30% drawdown gate and are sorted by Sortino; the rest are listed as high_drawdown. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries per list (default 10) | |
| section | No | Which list to return (default all: the verified lists plus apps; models, signals and usage only when asked) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real behavioral context: data is computed from the venue's public API, never from screenshots, self-reported PnL or backtests; ranking is gated by a 30% drawdown rule and sorted by Sortino, with failing entries demoted to high_drawdown. It stops short of describing pagination, ordering within flat sections, or error 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?
The core claim and the section list are front-loaded, but the first sentence runs on across several clauses and the description is a single dense paragraph. Every clause carries information, yet the shape makes it hard to scan quickly for the key gating and ranking rules.
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 two-parameter read-only aggregator with no output schema, the description covers data provenance, ranking methodology, section taxonomy and a disclaimer, which is most of what an agent needs. Missing pieces are the shape of returned entries (field names, whether security rating is a separate field) and whether unranked sections still carry the rank/sort fields.
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 genuinely enriches the section enum by explaining what each list contains (Hyperliquid vaults with quoted AI claims, builder-fill PnL for apps, ForecastBench/Prophet Arena sources for models). The limit parameter's default is only in the schema, which is fine given 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?
States a specific verb and resource (verified performance leaderboard for AI trading agents, bots and vaults) and enumerates exactly what is measured: return vs BTC, max drawdown, Sortino. No sibling tool overlaps with this resource, so ambiguity is low.
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 per-section summaries act as an implicit router (e.g. 'signals… not ranked', 'vaults… of any strategy'), but there is no explicit when-to-use or when-not-to-use instruction such as 'call this for X; use compare_tools instead for Y'. Selecting between sections requires reading the schema default note ('models, signals and usage only when asked').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a tool before your agent connects to it: how much money could be lost if the tool, or the agent using it, is wrong, hacked or prompt-injected? Returns the Safety score (human approval, guardrails outside the agent, test mode, sending funds out, who holds the keys, open source or audited, incident record), each input with its reason and source; missing inputs are listed, not guessed. Omit tool to rank every tool in a category (e.g. agent_wallet, bot_exchange, broker_mcp).
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Tool slug or name, e.g. 'safe-smart-account', 'Hyperliquid' | |
| category | No | Rank a category instead, e.g. agent_wallet, agent_payments, ai_trading_agent, bot_exchange, defi_agent or broker_mcp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, and the description still adds real substance: each input is returned with its reason and source, and 'missing inputs are listed, not guessed' — a meaningful honesty guarantee about what the agent can rely on. That is behavior beyond anything in the annotations or schema.
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 use case, then the return shape, then the parameter modes — a sensible order with no filler sentences. The long parenthetical enumerating score dimensions is dense but each item earns its place as scoring criteria.
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 two-optional-parameter read tool with no output schema, the description covers the return shape (score, per-input reason and source, missing-input list) and both invocation modes. Minor gaps remain: how many tools a category ranking returns and whether both params can be combined.
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; the description adds the key semantic that 'tool' is optional and that omitting it ranks a whole category, plus gives example category values. It doesn't clarify precedence if both params are supplied, which keeps it at 4.
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 ('Check a tool ... Returns the Safety score') and enumerates the seven dimensions that make up that score, so the agent knows exactly what comes back. It also implicitly separates itself from siblings like get_tool/search_tools by framing the output as money-at-risk/Safety scoring rather than lookup.
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 situational trigger ('before your agent connects to it') and covers the two modes: single tool vs. omitting tool to rank a category. It does not explicitly say when to prefer siblings such as compare_tools or get_incidents instead, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full facts for one tool: pricing, live vs paper, order approval, rate limits, safety score inputs and every source URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug (from search_tools) or name |
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 goes beyond them by disclosing the actual payload contents (pricing, live vs paper, order approval, rate limits, safety score inputs, source URLs), which is genuinely useful context with no output schema present.
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 a colon-delimited field list. Every clause earns its place and there is no 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 carries the return-value burden and does so by enumerating the returned fields. The only gap is error/not-found behavior for an invalid slug, which is minor for a read-only lookup.
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?
One parameter with 100% schema description coverage, so the schema already documents the slug and even its provenance ('from search_tools'). The description adds no syntax, format, or fallback detail (e.g., behavior on an unknown slug), 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 ('Full facts for one tool') and enumerates the content returned (pricing, live vs paper, order approval, rate limits, safety score inputs, source URLs). This clearly separates it from search_tools (discovery) and compare_tools (multi-tool comparison), 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 only implied: the singular 'one tool' framing suggests a lookup-after-search workflow, and the slug schema text references search_tools, but the description itself offers no explicit when-to-use or when-not guidance versus compare_tools or list_category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every tool in a category. Call with an unknown category to get the list of categories.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category slug, e.g. broker_mcp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare it as read-only, idempotent, non-destructive, and closed-world. The description adds a meaningful behavioral detail not covered by annotations: using an unknown category returns the category list rather than an error or empty 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?
The definition is two short sentences, front-loaded with the primary action and followed by the category-discovery tip. There is no redundant or wasted text.
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 listing tool with full schema coverage and clear annotations, the description is nearly complete. It could mention the return shape, such as whether it returns tool names or full definitions, but that is a minor gap.
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%, and the single parameter is already documented with type, example, and slug semantics. The description does not add syntax or constraints beyond what the schema provides, so the baseline score 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 states a specific verb and resource: "List every tool in a category." It is clear enough to distinguish from get_tool and search_tools, but it does not explicitly name or contrast with those siblings.
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 one useful usage rule: call with an unknown category to retrieve the category list. However, it does not explain when to choose this tool over search_tools or get_tool, nor does it state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the TradingAgentStack directory of AI trading tools (broker MCP servers, trading and data APIs, bots, frameworks) by name, market or feature. Optional filters: category slug, can_trade_live, has_paper.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| query | Yes | Words to match, e.g. 'options paper alpaca' | |
| category | No | Category slug, e.g. broker_mcp, data_api, ai_bot_platform | |
| has_paper | No | Only tools with a documented paper/demo/testnet mode | |
| can_trade_live | No | Only tools that can place real-money orders |
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 nothing beyond that — no note on result ordering, relevance ranking, or what a match against 'market or feature' covers.
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 single sentence followed by a short filter enumeration; no filler. The filter list mildly duplicates schema text but keeps the description scannable.
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 should say what a result contains (name, category, capability flags) and how the limit/ranking works; it stops short of that, leaving the agent to guess the return shape.
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% and every parameter already has a description, so the schema carries semantics. The description restates the optional filters at a high level without adding syntax or defaults 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?
States a specific verb and resource ('Search the TradingAgentStack directory of AI trading tools') plus the searchable facets. An agent can tell it apart from get_tool or list_category by the keyword-search framing, though 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?
Usage is implied by 'search ... by name, market or feature' plus optional filters, but there is no explicit 'use this when you don't know the tool id, use get_tool when you do' routing against the many siblings.
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.
get_risk1 field changedInput schema / properties / category / descriptionPrevious value: -"Rank a category instead: agent_wallet, agent_payments, ai_trading_agent, agent_token, bot_exchange or defi_agent"New value: +"Rank a category instead, e.g. agent_wallet, agent_payments, ai_trading_agent, bot_exchange, defi_agent or broker_mcp"check_setupget_incidents1 field changedInput schema / properties / tool / descriptionPrevious value: -"Only incidents naming this tool (slug or name)"New value: +"Only incidents for this tool or service (slug or name), e.g. 'alpaca-mcp-server', 'Keystone', 'Bloom'"get_leaderboardsearch_tools1 field changedInput schema / properties / limitAdded value: +{
+ "description": "Max results (default 10)",
+ "maximum": 20,
+ "minimum": 1,
+ "type": "integer"
+}checkget_risk1 field changedInput schema / properties / category / descriptionPrevious value: -"Rank a category instead: agent_wallet, bot_exchange or defi_agent"New value: +"Rank a category instead: agent_wallet, agent_payments, ai_trading_agent, agent_token, bot_exchange or defi_agent"get_incidentsget_riskbroker_order_gatingcompare_toolsget_toollist_categorysearch_toolsTrading MCP server for AI agents, with live market data, account reads and controlled execution.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
Read-only search of 2,189 AI agent tools (MCP servers, x402 APIs) with daily automated trust scores.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Add one secure layer between your agents and this server.
