A paper-money exchange: read live order books, place practice trades, test a bot. No sign-up.
Scored across 10 tools
Each tool targets a distinct resource (account, book, orders, positions, markets, prices, leaderboard) with clear action boundaries. The only mild overlap is get_account, which summarises orders/positions that get_orders and get_positions return in detail, but the descriptions make the summary-vs-detail distinction clear.
All ten tools follow a consistent snake_case verb_noun pattern (get_*, list_*, place_order, cancel_orders, create_account). Verbs are used predictably: get for single-resource reads, list for catalogues, and place/cancel/create for mutations.
Ten tools is well-scoped for a paper-trading/prediction-market server; each covers a necessary part of the workflow (account setup, market data, order placement, order/position management, leaderboard) without filler.
The surface covers the full trading lifecycle: account creation and inspection, market and book data, order placement/cancellation, order and position queries, and a leaderboard. Minor gaps exist—no explicit trade/fill history and cancellation is batch/filter-based rather than per-order—but these are workable.
Cancels your resting orders, on one market or side if you name it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. | |
| side | No | up or down | |
| market | No | A market id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. "Resting orders" usefully signals that only open, unfilled orders are affected, but the description says nothing about irreversibility, whether calling with no filters wipes every open order across all markets, what the response contains, or any permission requirements.
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 short sentence with the action front-loaded and the scoping condition attached. Nothing is redundant and nothing needs reordering.
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 three-parameter destructive mutation with no annotations and no output schema, the description covers what is cancelled and that filtering is optional, which is the minimum needed. It leaves the destructive semantics and cancel-all behavior underspecified, which matters most for exactly this kind of tool.
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 each of key, side, and market is already documented, making 3 the baseline. The description does add a little meaning by framing side and market as optional narrowing filters ("if you name it"), but it gives no format or interaction 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 opens with a specific verb and resource ("Cancels your resting orders") and clarifies scope with "on one market or side if you name it." It is distinguishable from get_orders and place_order by the mutation verb, though it never explicitly names a sibling to contrast with.
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: naming a market or side narrows the cancel, and naming neither presumably cancels everything. There is no explicit statement of when to prefer this over get_orders/place_order, and no warning about the cancel-all default when called with no arguments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A new paper account with $1,000 and its API key, shown once. Pass the key to the tools below, or set it as this server’s bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses that the API key is shown only once and how to use it, but it does not state side effects, authentication requirements for the optional key, idempotency, 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?
Two short sentences, front-loaded with the account outcome and followed by key usage. There is no repetition or wasted wording.
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?
The tool is low-complexity with one optional, fully documented parameter. However, with no annotations and no output schema, the description should do more to explain the returned account details, failure modes, and authorization expectations.
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% for the single optional `key` parameter, and the schema already explains its condition. The description adds no parameter-specific syntax or conditional 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 clearly identifies the outcome: a new paper account with $1,000 and its API key. It omits an explicit verb like 'create', but the resource and result are specific enough to distinguish it from the sibling trading 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?
Usage is implied: call this to get an account, then pass the returned key to the other tools or set it as the server bearer token. There is no explicit when-not guidance or named alternative, but the workflow context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your balance, what’s in orders and positions, realised PnL and rank.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose the response composition (balance, open orders, positions, realised PnL, rank), which is the most useful behavioral signal here since there is no output schema. It says nothing about authentication expectations despite the optional API-key parameter, nothing about whether the read is scoped or paginated, and nothing about freshness or rate 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?
A single short clause with no filler and the most important payload items placed first (balance, then orders/positions). It loses a point only because the fragment form reads like a field list rather than a statement of what the tool does.
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 read tool with no annotations and no output schema, the enumeration of returned content substitutes reasonably for a return-value section. What is missing is only the relationship to the overlapping sibling tools and any note on auth or freshness, so the definition is nearly, but not fully, self-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?
Schema description coverage is 100% and the single parameter is optional with a clear description about the rz_ API key and bearer-token fallback, so the schema does the work. The description adds no meaning about that parameter, which is the expected baseline of 3 when coverage is complete.
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 resource (account) and enumerates its contents — balance, orders, positions, realised PnL, rank — so the resource is identifiable, but it is a verbless fragment that never says 'retrieves your account summary'. It also fails to distinguish this from siblings like get_orders, get_positions, and get_leaderboard, which cover the very same data, leaving genuine overlap unresolved.
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 when-to-use guidance at all. An agent reading this cannot tell whether get_account is the aggregate snapshot to call instead of get_orders/get_positions/get_leaderboard, or a redundant convenience wrapper alongside them, and nothing states prerequisites or call ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One market’s order book: up to 30 levels a side, and its midpoint, the market’s forecast of the number. No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. | |
| market | Yes | A market id, like BTC-15s |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the substantive traits: the return is capped at 30 levels a side, includes a midpoint, and requires no API key. It leaves out whether the book is a live snapshot or delayed, and what happens on an unknown market.
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: resource first, then depth cap, then midpoint, then the auth note. No filler or redundancy.
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 tool with full schema coverage and no output schema, the description supplies the return-shape essentials (levels per side, midpoint) plus the auth note. Only minor gaps remain around freshness and error behavior.
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 parameters are already documented, and the description only implies single-market scoping. 'No key needed' loosely reinforces that key is conditional, but adds nothing the schema does not already state.
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 — one market's order book — plus its scope (a single market, up to 30 levels per side) and contents (midpoint). That is enough to separate it from get_prices and list_markets without opening a schema, though it does not explicitly name 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?
Usage is only implied: an agent can infer this is the depth/snapshot call for one market, versus list_markets for discovery. There is no explicit 'use when' condition or exclusion against get_prices, and no guidance on invalid market ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every account that has traded, ranked by realised PnL, people and bots alike. No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. | |
| limit | No | 1 to 100, default 20 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose useful traits: only accounts that have actually traded appear, both humans and bots are included, and no authentication is required. It omits return shape, pagination behaviour, and whether results are cached or rate limited, which matters for an unannotated public endpoint.
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 short sentences, zero filler, with the scope and ranking rule front-loaded before the auth note. 'People and bots alike' earns its place by clarifying that bot accounts are not filtered out.
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 two-optional-parameter read with no output schema, the description covers the essentials: what is ranked, who is included, and that no credential is needed. It could say a word about what each entry contains or how many results come back by default, but nothing critical to invocation 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%, so 'key' and 'limit' are already documented in the schema, and the description adds nothing about their syntax or interaction. The phrase 'No key needed' does reinforce that the key parameter is optional, a small but genuine addition over the schema text.
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 the resource (a leaderboard), the ranking metric (realised PnL), and the population covered ('every account that has traded, people and bots alike'). That scope clause effectively separates it from account-specific siblings like get_account and get_positions, though it never names them.
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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is referenced. The only contextual cue is 'No key needed', which implies a public/unauthenticated read but does not tell an agent when to prefer this over get_account or get_positions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your orders. Open ones by default.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. | |
| market | No | A market id | |
| status | No | open or all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It does disclose one useful trait — the default filter returns only open orders — but says nothing about read-only semantics, auth expectations, pagination, ordering, or result shape for a multi-parameter listing tool.
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 short fragments with zero preamble; the resource and the default behavior are front-loaded. There is no wasted wording, though the terseness is under-specification rather than disciplined brevity.
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 three-parameter listing tool with no annotations and no output schema needs more than a sentence. The default status is covered, but the description never says what an order record contains or how results are scoped/ordered, leaving gaps an agent would hit on first call.
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 documents key, market, and status; baseline is 3. The description adds one genuine clarification the schema lacks — that status defaults to open — but leaves market and key semantics entirely to 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?
"Your orders" names the resource but supplies no verb and reads as a fragment; the agent must infer 'list/fetch'. The default-scope note and the contrast with siblings like get_positions and cancel_orders make it barely identifiable, but the purpose is only implied.
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?
"Open ones by default" hints at the default filter but gives no when-to-use guidance, no mention of when to prefer status=all, and no comparison against siblings such as get_positions or cancel_orders. The agent has to infer both the trigger and the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your positions. Open ones by default.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. | |
| market | No | A market id | |
| status | No | open, settled or all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses only that the default status is open; it says nothing about authentication needs, return shape, pagination, or what settled/all positions include.
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 short fragments with no wasted words and the default behavior front-loaded. It is appropriately brief, though the phrase "ones" is slightly ambiguous.
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 three-parameter read tool with no annotations and no output schema, the description omits too much: return format, cost/margin fields, and per-market behavior are all left for the agent to discover.
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 the key, market, and status parameters. The description adds only the default value for status, which is marginal added meaning beyond the schema 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?
"Your positions" identifies the resource but supplies no verb (list/get), and the second fragment only states a default filter. It does not differentiate this tool from the sibling get_orders, which covers a closely related resource.
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?
"Open ones by default" hints at a default filter value but gives no guidance on when to use this versus get_orders or other portfolio tools, and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An underlying’s price history as [time, price] pairs. No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End, ms since the epoch | |
| key | No | Your rz_ API key, if this server has no bearer token set. | |
| from | No | Start, ms since the epoch | |
| step | No | Bucket size, ms | |
| underlying | Yes | An underlying id, like BTC-USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that no key is needed and that output is [time, price] pairs, but omits read-only confirmation, rate limits, default time range, and pagination 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 front-loaded sentences with no wasted wording. The resource and return format are stated immediately, followed by the auth note.
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 the rich schema coverage and no output schema, the description is complete enough: it explains the return shape and auth behavior. It leaves parameter details and defaults to the schema, which is acceptable here.
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 all five parameters are documented in the schema. The description adds little parameter meaning beyond implying 'underlying' and noting no key; baseline 3 is appropriate.
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 that the tool returns an underlying's price history as [time, price] pairs, identifying the resource and return shape. It does not distinguish itself from siblings like get_book or list_markets.
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?
Provides no when-to-use guidance or alternatives. The only context is the auth note 'No key needed,' which does not help an agent choose between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every market: its number, spot, best bid and ask (strikes), one-sigma move, rules and status. No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the auth posture ('No key needed'), which usefully resolves that the key param is optional, and it lists the returned fields. However it says nothing about ordering, pagination, freshness/delay, or rate limits for a market-data feed.
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, front-loaded with scope and immediately followed by the payload fields, ending with the auth caveat. No filler and nothing repeated from structured fields.
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 enumerated field list does real work in telling an agent what comes back, and the auth note covers the only parameter. Minor gaps remain around data freshness and ordering, but 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 coverage is 100% and there is only one optional parameter, so the baseline is 3. The description adds a small amount by implying no credential is required, but gives no further meaning beyond the schema's own 'if this server has no bearer token set' note.
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 resource ('Every market') and enumerates the payload it returns: number, spot, best bid/ask (strikes), one-sigma move, rules and status. That is specific enough to separate it from siblings like get_prices and get_book, though it never uses an explicit verb and does not directly name the sibling it contrasts with.
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 tool is the enumeration path for all markets, whereas get_book/get_prices are presumably narrower. There is no explicit when-to-use framing, no statement of when not to use it, 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.
Places an order with paper money. side up buys Higher: it wins if the number finishes above the strike. side down sells: it holds Lower. A win pays 2× size. Leave out strike for a market order.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your rz_ API key, if this server has no bearer token set. | |
| tif | No | gtc (rests), ioc (takes what it can) or post (only ever rests) | |
| side | Yes | up or down | |
| size | Yes | Paper dollars, 1 to 100,000 | |
| market | Yes | A market id, like BTC-15s | |
| strike | No | Makes it a limit order, on the market’s strike grid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful behavior: paper-money settlement, win condition (number finishing above the strike), and payout of 2× size. It omits what the call returns, what happens on rejection or insufficient balance, and whether repeated calls create duplicate orders, so a mutation tool remains under-described.
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?
Four short sentences, front-loaded with the core action and payoff before the strike caveat, with no filler. Some compression is cryptic — "it holds Lower" and "side down sells" read ambiguously — which keeps it from a 5.
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?
Six parameters, no annotations, and no output schema mean the description must cover both behavior and results; it handles side, strike, and payout but says nothing about the return value or the auth/credential path for key. Adequate for a trading mutation, but not 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 coverage is 100%, so the baseline is 3, but the description earns more by adding semantics the schema lacks: "side up buys Higher ... side down sells", and the strike-omitted-means-market rule, which clarifies how the optional strike changes order type. The tif and key parameters get no treatment in the 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 gives a specific verb and resource ("Places an order") and pins the scope with "with paper money", which separates it from real-money trading and from the read-only siblings like get_orders and get_book. It never names a sibling or explicitly contrasts with cancel_orders, 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?
"Leave out strike for a market order" is genuine conditional guidance for choosing market vs limit, and the side explanation tells the agent what each direction commits to. However, there is no guidance on when to place versus cancel an order, no prerequisite or account/authentication note despite a key parameter, and no advice on choosing tif.
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.
cancel_orderscreate_accountget_accountget_bookget_leaderboardget_ordersget_positionsget_priceslist_marketsplace_orderPaper trading for AI: live quotes, indicators, and virtual trades on stocks, crypto, and forex.
Paper trading only. 26 leagues for AI bots. Spot Crypto + Crypto 35 live. Register by MCP.
Paper trade prediction markets at live prices from your AI agent, and score every trade.
Keyless prediction-market data across 12 venues plus paper-trading of crypto spot, futures, and PM.
Add one secure layer between your agents and this server.
