Live Canton Network DEX data: prices, best execution across venues, exit cost, premiums. No key.
Scored across 12 tools
Most tools target clearly distinct questions: token vs list_tokens, quote vs check_trade, pools vs perps, and venues vs market_overview are separable. The main potential confusion is among quote, exit_cost, spreads, and check_trade, since all involve trade pricing, but their descriptions define different scopes well enough.
All names are snake_case or single lowercase words, so they are readable. However, the set mixes resource-style nouns (token, pools, perps, venues, alerts, premiums, spreads) with verb_noun names (list_tokens, check_trade) and compound nouns (exit_cost, market_overview), so no predictable verb_noun convention is followed.
Twelve tools is well scoped for a Canton DEX market-data and execution-analysis server. Each tool covers a meaningful slice of the domain without obvious padding.
The surface covers tokens, pools, perps, venues, premiums, alerts, quotes, spreads, historical trade checks, and exit costs, which is broad for this domain. Minor gaps remain around standalone historical/order-book depth and venue-fee detail, but nothing critical for the apparent analytics purpose is missing.
Alerts fired on Canton DEXes: stablecoin peg breaks, premiums over 1%, hourly moves over 5%, and spreads that clear their costs. Newest last.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
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 the trigger thresholds that define an alert (>1% premium, >5% hourly move, spread clearing costs) and the ordering, but says nothing about freshness/refresh cadence, whether it is strictly read-only, or whether older alerts are retained — gaps that matter for an alerting 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?
Two tight sentences: the alert taxonomy is front-loaded and the ordering note is appended. Slightly fragmentary ('Newest last') but nothing is wasted or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so the description is the only documentation, and it omits the shape of an alert record and the meaning of limit. It does provide good domain context on what counts as an alert, which is enough to attempt a call but not to fully understand the result.
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% and the single parameter (limit, default 20) is never mentioned in the description. With coverage this low the description should compensate — e.g. state that limit caps the number of alerts returned and how ordering interacts with it — but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('fired') and resource ('alerts') plus a concrete scope ('on Canton DEXes') and an enumeration of the four alert triggers. This is clear enough to pick out from siblings, though it references 'premiums' and 'spreads' — which are also sibling tools — without clarifying the relationship, leaving a small risk of confusion with premiums/spreads.
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 when-to-use or when-not-to-use guidance and no named alternatives, even though 'premiums' and 'spreads' exist as sibling tools that overlap with two of the listed alert categories. The only usage hint is the implicit 'recent' framing and 'Newest last' ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Was a trade well executed? Give the token sold and bought, the amount sold, the amount received, the time (ISO such as 2026-10-27T18:05:00Z, or unix seconds) and optionally the venue. The trade is priced again on every venue from the pool reserves and order books read at the five-minute ticks either side of it (archive since 27 Oct 2026), by the same code as quote(), after network fees. Returns the venue that returned the most, how far the trade fell short of it in basis points (at the reading least favourable to that), and with venue given, how much of the gap was the choice of venue and how much the fill itself. Nothing is executed or stored.
| Name | Required | Description | Default |
|---|---|---|---|
| buy | Yes | ||
| sell | Yes | ||
| time | Yes | ||
| venue | No | ||
| amount_in | Yes | ||
| amount_out | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and largely meets it: 'Nothing is executed or stored' declares the read-only profile, and it discloses the mechanics beyond the obvious — five-minute ticks either side, archive coverage since 27 Oct 2026, network fees included, and the least-favourable reading used for the shortfall. Missing are error/unavailable-data behaviour (e.g. trade before the archive window) and any latency or rate characteristics.
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 decision question, then inputs, then output semantics — a sensible ordering with no filler sentences. The second sentence is long and clause-stacked, which costs a little readability, but every clause carries information an agent needs.
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 six-parameter analytical tool with no annotations and no output schema, the description covers the two things structured data cannot: it explains what is returned (best venue, shortfall in bps, and venue-vs-fill attribution when venue is supplied) and that nothing is mutated. Return shape/serialization and behaviour outside the archive window remain 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?
Schema description coverage is 0% across six parameters, so the description must compensate, and it does for most: it maps sell/buy/amount_in/amount_out to sold token, bought token, amount sold, amount received, gives the accepted time formats with a concrete ISO example plus 'or unix seconds', and states venue is optional. It does not say whether token parameters are symbols or addresses, nor whether amounts are decimal or raw units.
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 specific operation: re-pricing a given trade on every venue at that time from pool reserves and order books, then returning the best venue and the shortfall in basis points. That is a distinct verb-and-resource from siblings like quote() (forward pricing), exit_cost, or spreads, and it even states it shares quote()'s engine, which lets an agent distinguish the two without opening schemas.
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 opening question 'Was a trade well executed?' plus the required past-trade inputs (sell/buy, amounts in/out, time) make the post-trade retrospective use case clear, and the parenthetical 'archive since 27 Oct 2026' is a real usability constraint the agent would otherwise miss. It never states an explicit exclusion such as when to prefer quote() or exit_cost for a forward-looking question, so it stops 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.
What selling a token for dollars (USDCx) nets on Canton, as a share of its value at our price: a ladder from $1K to $1M per venue and at the best one (with across_venues when selling the token for CC on one venue and that CC for dollars on another keeps more), the largest sale each venue (and all of them together) takes within 1%, 2% and 5%, what limited each (the cost, or the end of a venue's visible order book), and the worst share at $10K and $50K since the record began. For lending, vault and risk tools: what collateral sells for on Canton, not only what it is quoted at. With amount_usd, also that exact sale priced now on every venue (as quote() would).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| amount_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses substantial behavior: the ladder, best venue, across_venues logic, liquidity thresholds, limiting factor, historical worst shares, and the effect of amount_usd. It still omits data freshness, error behavior, and response structure, but the computational behavior is unusually well explained.
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 purpose is front-loaded, and most clauses add distinct information about outputs or options. However, it is a single dense run-on sentence with nested parentheticals, making it harder to parse than a structured list would be.
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 complex analytics tool with no annotations and no output schema, the description covers the conceptual metrics well but leaves important gaps: parameter format, response shape, error conditions, and data freshness. It is adequate but not complete for the tool's complexity.
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. It explains amount_usd clearly as requesting an exact current sale priced on every venue, but it only implies the meaning of symbol through 'selling a token' and does not specify symbol format, expected values, or required status.
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 purpose: computing what selling a token for USDCx nets on Canton as a share of its value. It enumerates the exact output dimensions, including price ladders, across-venue comparisons, liquidity constraints, and historical worst shares, which clearly identifies the tool. It references quote() for the amount_usd case but does not sharply distinguish the default mode from quote as a sibling.
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 useful implied usage context, especially 'For lending, vault and risk tools: what collateral sells for on Canton, not only what it is quoted at,' and explains what adding amount_usd does. However, it never explicitly says when to use this tool instead of quote, market_overview, or other siblings, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every token on Canton DEXes with price, 24h/7d change, liquidity and volume. sort_by: liquidity, volume, change_24h, change_7d or premium.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sort_by | No | liquidity |
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 the returned fields and sorting options, which implies a read-only listing operation, but it does not mention pagination, the default limit of 30, rate limits, or any auth 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?
Two short sentences with no wasted words. The resource and return data are front-loaded, and the sort options are presented compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain both output and behavior. It adequately covers returned fields and sort options but omits the limit parameter's effect and pagination behavior, which are important for a list endpoint with a default limit of 30.
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%, and the description compensates for sort_by by enumerating its allowed values (liquidity, volume, change_24h, change_7d, premium). However, the 'limit' parameter is completely undocumented in both the schema and description, leaving a meaningful gap.
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 states the resource (tokens on Canton DEXes) and the data returned (price, 24h/7d change, liquidity, volume). It does not explicitly distinguish itself from the sibling 'token' tool, but the list-vs-single distinction is reasonably inferable from the name and content.
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 lists sort_by options but gives no guidance on when to use this tool versus alternatives such as 'token', 'venues', or 'premiums'. There are no exclusions, prerequisites, or context about when this listing approach is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Canton DEX market right now: CC price, spot volume per venue we read, Canton's TVL for the day named, top movers, the largest premiums to global prices, and the latest alerts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. 'right now' implies live/fresh data and a read-only snapshot, and it discloses the categories returned, which is useful. However, it says nothing about freshness guarantees, caching, or output shape, leaving behavioral gaps beyond the content list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded clause with a colon-delimited list of contents, with no filler. The list is dense but earns its place by describing return contents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain returns, and it does list the six content categories. Still, it doesn't describe structure or format, and it omits why an agent would choose this aggregation over the more targeted siblings.
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 schema baseline is 4. There is no parameter semantics to add, and the description correctly implies a no-argument call.
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 (Canton DEX market) and enumerates concrete contents: CC price, spot volume per venue, TVL, top movers, premiums, latest alerts. This tells an agent it's an aggregated snapshot rather than a single-metric tool. It lacks a crisp verb (returns/summarizes) and overlaps conceptually with siblings premiums and alerts, but the composite scope is clear.
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 guidance on when to prefer this over the dedicated siblings (premiums, alerts, venues). The description actually lists data that siblings also provide ('largest premiums to global prices', 'latest alerts'), which could mislead an agent into calling this when a targeted tool is better, with no exclusion clause to resolve that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perp markets on Rocky, Ekiden and Canborsa: price, basis to the outside spot price, funding, spread, open interest and 24h volume where the venue publishes them. base filters by asset, e.g. BTC, ETH or CC.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does disclose one real behavioral trait: values are only present 'where the venue publishes them,' so missing fields per venue are expected. It does not state that the operation is read-only, whether results are paginated, or the response shape (venues as keys vs list).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, no filler, with the returned-metrics list up front and the parameter note last. Slightly compressed to the point that unfamiliar venue names (Rocky, Ekiden, Canborsa) go unexplained, 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 single optional-parameter read tool with no output schema, listing the returned fields is the most valuable thing the description could add, and it does so. The remaining gap is the no-filter default behavior and return structure, which is minor for this complexity level.
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 0% and the lone parameter has no description, so the sentence 'base filters by asset, e.g. BTC, ETH or CC' is doing real work — it defines the parameter's meaning and gives concrete accepted values. It stops short of saying what happens when base is null (all markets) or whether matching is case-insensitive.
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?
Names a specific resource (perp markets) and enumerates exactly what is returned: price, basis, funding, spread, open interest, 24h volume. An agent can tell it is a market-data read for perpetual futures, but the description never contrasts it with sibling tools like premiums, spreads, or market_overview that overlap on the same metrics.
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 by the data it exposes — an agent must infer that this is the tool for perp-specific metrics rather than spot or premium data. No explicit when-to-use, when-not-to-use, or named alternative among the eleven siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CC pools on every AMM (Cantex, Tradecraft, OneSwap, Pool Party) with liquidity, 24h volume where
the venue publishes it, fee and LP fee APR from the last 24 hours of volume; a pool whose reserves
have stood still while its price left the market carries not_trading_since. sort_by: tvl, volume
or apr.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sort_by | No | tvl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that 24h volume exists only 'where the venue publishes it' (i.e. may be absent), that APR is derived from the last 24 hours of volume, and that `not_trading_since` marks pools whose reserves are stale versus market price. It omits pagination/limit behavior and result ordering defaults.
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, front-loaded sentence covering scope, metrics, caveats and sort options, with no filler. It is slightly run-on but every clause carries information.
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 no output schema and no annotations, the description covers what is returned, data availability caveats, and a special output flag. Only limit/pagination semantics are 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 0%, so the description must compensate. It does explain the sort_by domain (tvl, volume, apr), but says nothing about `limit` or the default of 20, leaving one of two parameters undocumented anywhere.
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 specific resource (liquidity pools across four named AMMs) and enumerates the metrics returned (liquidity, 24h volume, fee, LP fee APR), so an agent can tell this apart from list_tokens or venues. It lacks an explicit verb like 'list', but the intent is unambiguous.
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 — you call this to inspect pools — with no statement of when to prefer it over siblings such as venues or list_tokens. The only explicit guidance is which values sort_by accepts, which is parameter-level rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Best execution for selling amount of token sell (or amount_usd worth) for token buy, on
every venue that can make the trade on its own markets in one or two swaps: an AMM pool (Cantex,
Tradecraft, OneSwap, Pool Party), an order book (Temple, Rocky), or two of them in a row on the same
venue (Temple: CC to USDCx, then USDCx to CBTC; Pool Party: CC to USDC.B, then USDC.B to CBTC). The
same comparison as the site's best execution, at any size. Pool fees, book fees and price impact are
included; after_network_fee also takes off the venue's per-trade network fee on each swap (the fee
table, with which fees are measured, documented or assumed, is in network_fees). A pool whose
reserves have stood still while its price left the market is no market here (not_trading). A
venue whose route takes an order book that shows more of a token than exists (a side larger than its
registry's total supply) carries book_shows_more_than_exists: its price, not a size it can fill.
| Name | Required | Description | Default |
|---|---|---|---|
| buy | Yes | ||
| sell | Yes | ||
| amount | No | ||
| amount_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses that pool fees, book fees and price impact are included, that `after_network_fee` additionally deducts per-swap network fees per the `network_fees` table, and it names two degradation signals (`not_trading`, `book_shows_more_than_exists`) with their meanings. It stops short of stating the operation is read-only and non-mutating, or what happens when no route exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core intent is front-loaded in the first sentence, but the body is a dense run-on of nested parentheticals, including two full worked route examples (Temple CC→USDCx→CBTC, Pool Party CC→USDC.B→CBTC) that add length without changing how the tool is called. The signal-to-word ratio is mediocre.
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 explain the return; it explains individual flags and the fee treatment but never describes the overall response shape (per-venue entries, best route, comparison ordering). For a multi-venue quoting tool with four undocumented parameters, the definition is workable but leaves real gaps.
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 0%, so the description must carry all parameter meaning; it does define `sell`, `buy`, `amount` and the `amount_usd` alternative sizing path. However, it never states whether `amount` and `amount_usd` are mutually exclusive, what happens if both or neither are supplied, or whether tokens are symbols or addresses — significant gaps at 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — computes best execution for selling `sell` for `buy` across named Canton venues — and clarifies it is the site's best-execution comparison at any size. An agent can tell it produces a cross-venue price comparison rather than a single-venue lookup. It does not explicitly contrast itself with siblings like check_trade or exit_cost, which keeps it out of the top band.
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 description bounds scope to routes achievable in one or two swaps on the same venue, and flags pools that are stale (`not_trading`) or books that overstate supply. There is no explicit when-to-use/when-not guidance and no named alternative for cases this tool excludes, leaving the agent to infer that check_trade or exit_cost covers other questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy-on-one-venue, sell-on-the-other round trips at their best size, after each venue's network
fee: cost_cc per route, swap_cost_cc per venue (Cantex measured, OneSwap and Tradecraft
documented, the rest assumed at 1.5 CC). A trip through an order book in dollars (via=usd) also
pays the CC/USDCx leg of each pool side. clears is true when one nets at least $0.50.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
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 the fee model (network fee deducted, 1.5 CC assumed for unmeasured venues), the data-quality caveats (Cantex measured, OneSwap/Tradecraft documented, rest assumed), and the `clears` threshold of $0.50. What it omits is the read-only/expense character of the call and how `limit` shapes or orders the results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with the core definition front-loaded, followed by fee caveats and the clearing threshold. The inline code-shorthand (`cost_cc`, `swap_cost_cc`, `clears`) is compact but forces the reader to infer that these are returned 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?
For a one-parameter tool with no output schema, describing the returned fields (`cost_cc`, `swap_cost_cc`, `clears`) and fee assumptions is genuinely useful. But a phantom `via=usd` parameter and an unexplained `limit` leave gaps an agent must guess through.
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 only schema parameter is `limit` with 0% description coverage, and the description never explains what it limits or in what order. Worse, it references `via=usd`, a parameter that does not exist in the schema, which can send an agent to build an invalid call.
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 computation: buy-on-one-venue / sell-on-the-other round trips at best size, net of each venue's network fee. That is a concrete verb-and-resource framing an agent can act on. It does not, however, differentiate itself from siblings like quote, check_trade, or exit_cost, which also concern trade economics.
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 statement of when to prefer this over quote or check_trade, nor any preconditions or exclusions. The mention of a 'trip through an order book in dollars (via=usd)' implies a mode selection, but that mode is never framed as a usage decision and does not correspond to any real parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One token: price, changes, liquidity and volume, price on each venue, premium to its outside reference, its pools with fee APR, and hourly USD prices for the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the returned data richly (including a 7-day window), which is real behavioral value. However it says nothing about whether this is a read-only call, what happens for an unknown symbol, or any auth/rate-limit constraints.
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 the resource front-loaded and no filler. The trailing enumeration is long but every listed item earns its place by telling the agent what data comes back in the absence of an output schema.
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, no-output-schema, no-annotation tool, the description does well on return-content coverage. It is incomplete on the input side (symbol semantics) and on failure/safety behavior, which is the main gap an agent would hit when invoking 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 0% for the single required 'symbol' parameter, so the description must compensate. It never mentions the parameter at all — no format, case sensitivity, or whether it accepts ticker vs address — leaving the agent to guess how to populate the only input.
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 concrete resource and enumerates exactly what 'token' returns (price, changes, liquidity, volume, per-venue price, premium, pools with fee APR, 7-day hourly prices). 'One token' also implicitly distinguishes it from the list_tokens sibling. It lacks an explicit verb like 'get' but the scope is unmistakable.
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 'One token' implies single-token detail versus the list_tokens sibling, and the mention of venues/pools/premiums hints at overlap with those tools, but no alternative is named and no when-to-use condition is stated. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every Canton trading venue we know of: type, 24h volume, and whether we price it live, see its volume only, or cannot read it (key needed, testnet, no public API). Also the share of Canton spot DEX volume that these prices cover.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does add real value: it discloses three distinct data-quality states (live-priced, volume-only, unreadable) along with the reasons (key needed, testnet, no public API). That is meaningful disclosure about trustworthiness of the data, though it says nothing about caching, freshness, or the shape of the response.
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 with zero waste. The core inventory is front-loaded and the parenthetical of failure modes is compactly packed rather than spelled out in prose.
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, no annotations, and no parameters, the description must convey what comes back, and it does: venue identity, type, volume, pricing status, and a coverage share. Only minor gaps remain, such as sort order or how unpriced venues are represented.
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 is 4; there is nothing for the description to compensate for and it correctly avoids inventing parameter discussion.
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 (Canton trading venues) and enumerates the fields returned: type, 24h volume, pricing status, and coverage share. It is clearly distinct from siblings like pools, list_tokens, and market_overview, though it never uses an explicit verb such as 'list' or 'returns'.
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 usage context is implied by the content ('every venue we know of' plus a coverage share), but there is no explicit statement of when to reach for this tool rather than pools, market_overview, or list_tokens. For a zero-parameter read-only listing that is largely acceptable, but the routing guidance is left to inference.
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.
alertscheck_tradeexit_costlist_tokensmarket_overviewperpspoolspremiumsquotespreadstokenvenuesSwap quotes + unsigned txs on 8 EVM chains, plus Solana data: boards, candles, wallet PnL. No key.
Live non-custodial stablecoin liquidity: open positions, volume, and an on-chain swap quote.
A Mentat's eye on Sui DeepBook v3: read-only market data plus desk template tools. No keys.
Read-only Hyperliquid analytics: orderflow, liquidation levels, whale positioning, funding.
Add one secure layer between your agents and this server.
