Tokenized US stocks onchain: listings, holdings, US prices, pre-filled trade links. Read-only.
Scored across 11 tools
Most tools map cleanly to distinct actions or resources: order lifecycle, wallet data, issuer comparison, and link generation are separated. Minor overlap remains between fair_value, compare_issuers, and trade_link around pricing/execution, and between cancel_limit_order and withdraw, though descriptions largely disambiguate them.
Names consistently use snake_case and are readable, with action tools following verb_noun (place_limit_order, list_stocks, cancel_limit_order). Some tools deviate into noun-first or link-oriented names (fair_value, trade_link, wallet_pnl), but the pattern is still predictable.
At 11 tools, the surface is well within the ideal range and each tool appears to serve a distinct part of the tokenized-stock trading workflow. There are no obvious redundant or filler tools.
The set covers listing, pricing, issuer comparison, trade/strategy links, limit-order placement/listing/cancellation, withdrawals, holdings, and P&L. Some secondary gaps exist, such as direct order lookup by ID or explicit transaction status tracking, but core workflows are covered.
One transaction: withdraw what the order still holds (vaults no other live order uses) to the wallet, then remove the order. Returns unsigned transactions for the user to sign in their own wallet, in order; nothing is sent or signed here.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | 0x... address | |
| chainId | Yes | 8453 Base, 4663 Robinhood Chain | |
| orderHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real substance beyond the annotations: it discloses that the withdrawal only touches vaults no other live order uses (partial-scope safety), that the result is an ordered list of unsigned transactions, and that nothing is signed or sent server-side — which explains why readOnlyHint=true is coherent rather than contradictory for a 'cancel' tool. It does not cover failure conditions or permission requirements, keeping it below a 5.
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 opens with the concrete action and sequencing ('withdraw… then remove'), followed by the return contract. Dense and waste-free, though the second clause packs three ideas (signing location, ordering, no side effects) into one breath.
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 correctly compensates by describing the return value (ordered unsigned transactions for external signing). For a 3-param write-intent tool this is close to sufficient; only error/precondition behavior and orderHash semantics are left implicit.
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 67%; chainId's enum is documented and owner is described, but orderHash has no description in either the schema or the description. The prose refers only to 'the order' without adding format, sourcing, or validity semantics beyond the schema, so 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 a specific verb+resource ('cancel a limit order') and goes further to describe the two-step effect: withdraw remaining vault holdings to the wallet, then remove the order. This clearly separates it from list_limit_orders (read) and place_limit_order (create) among the 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 implied rather than stated — the caller infers they need an existing orderHash (presumably from list_limit_orders) and a wallet to sign with. There is no explicit 'use this when…' or exclusion, and no mention of prerequisites such as ownership or whether partially filled orders are cancellable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where a tokenized stock is cheapest: each issuer's token (ST0x, Coinbase, Robinhood) priced per share for a $100 buy, against the stock's own price (US, or the home exchange's in dollars), with the gap in % and the lowest issuer. From quotes taken every 5 minutes (biggest stocks) or hourly; the time is in the answer. Not a live quote: for an executable best-price buy use trade_link with usd. Up to 12 tickers.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give readOnlyHint/openWorldHint, but the description adds real behavioral context: quote cadence (5-minute for big stocks, hourly otherwise), the staleness caveat that it is not executable, and that the quote timestamp is included in the response. It stops short of auth/permission or rate-limit detail, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and tightly written with no filler; the routing caveat is placed at the end where it belongs. Clauses are somewhat telegraphic ('US, or the home exchange's in dollars'), which costs a little readability.
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 shape itself (per-share price, gap %, lowest issuer, timestamp) and warns about freshness — enough to call it correctly. The remaining gap is ticker format, which neither the description nor the schema resolves.
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 (tickers) with 0% schema description coverage; the description only restates the schema's maxItems ('Up to 12 tickers'). It never says whether entries are stock symbols, issuer tokens, or exchange-qualified identifiers, so it does not fully compensate for the coverage 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?
Names a specific verb-and-resource ('Where a tokenized stock is cheapest'), enumerates the compared issuers (ST0x, Coinbase, Robinhood), and states the exact measure (per-share price for a $100 buy vs the stock's own price, gap %, lowest issuer). An agent can separate this from trade_link or fair_value without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-not ('Not a live quote') paired with a named alternative and condition ('for an executable best-price buy use trade_link with usd'). This is a concrete routing rule rather than implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Last US market price and market status of listed stocks (what the tokens track). Up to 12 tickers.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful domain context that these are token-underlying stock quotes and the batch ceiling, but says nothing about refresh behavior, staleness, or error handling.
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, with the primary purpose front-loaded and the limit trailing. The parenthetical earns its place by tying the data back to the tokens, though the phrasing is slightly indirect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only lookup with a closed-world annotation and no output schema, the description covers what is fetched and the batch cap. Only ticker format and freshness behavior remain unspecified, which 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?
The single parameter has 0% schema description coverage, so the description must carry the load. It restates the schema's maxItems=12 as 'Up to 12 tickers' but gives no ticker format or identity hints (e.g., symbol vs. name), leaving a real gap for the one 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 names the concrete resource (listed stocks and the tokens they track) and what is returned (last US market price plus market status), so an agent can tell what it fetches. It does not, however, distinguish itself from the sibling list_stocks, and the 'fair_value' name/title sits awkwardly against the plain 'last market price' 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 only guidance is the batch limit ('Up to 12 tickers'). There is no statement of when to use this versus list_stocks or the other siblings, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A wallet's limit orders on one chain: status (open, partially_filled, filled, cancelled), filled and remaining amounts in base units.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | 0x... address | |
| chainId | Yes | 8453 Base, 4663 Robinhood Chain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful return-value detail (the four status values, amounts in base units), but says nothing about pagination, ordering, or whether cancelled/filled orders are included in 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?
One tight sentence with the scope and payload fields front-loaded before any detail. It is a noun fragment rather than a full sentence, but nothing in it 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 two-parameter read tool with no output schema, the description does the minimum: it tells the agent what comes back. It omits result volume, ordering, and empty-wallet behavior, which an agent would need to plan a 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%: owner and chainId are both documented in the schema, including the enum mapping 8453/4663. The description's 'one chain' phrasing usefully signals there is no cross-chain aggregation, but adds no format or semantics 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 names a specific resource (a wallet's limit orders on one chain) and enumerates the returned fields (status, filled/remaining amounts in base units). It clearly differs from the write-side siblings place_limit_order and cancel_limit_order, though it never names 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?
There is no statement of when to use this tool versus alternatives such as wallet_holdings or cancel_limit_order, and no prerequisites. The read-only nature is only inferable from the verb 'list' in the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tokenized stocks listed on The River, with ticker, token symbol, issuer, chain and trade link. Filter by chain and/or a search query (ticker, symbol or name).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| query | No | e.g. NVDA or nvidia |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the shape of the returned records, but says nothing about pagination, result caps, or rate limits, so it adds only modest context on top of the structured fields.
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 with the resource and its identifying fields front-loaded, followed by the filtering capability. 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?
With no output schema, the description usefully describes the return fields (ticker, token symbol, issuer, chain, trade link) and how filtering works for a simple two-parameter read tool. Pagination behavior for a potentially long listing is the only notable omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: 'query' is documented but 'chain' has an enum with no description. The description compensates by explaining what 'query' actually matches against (ticker, symbol or name) and that both filters can be combined ('and/or'), which is meaning beyond the raw 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 ('Tokenized stocks listed on The River') and enumerates the fields returned, so the agent immediately knows this is a catalog listing rather than a valuation or holdings tool. It stops short of explicitly naming the sibling it differs from, but the resource is distinctive enough to separate it from fair_value, strategy_link, trade_link and wallet_holdings.
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 'Filter by chain and/or a search query' implies the intended usage and that the two filters are combinable, but there is no explicit when-to-use statement, no exclusion criteria, and no mention of what to do when no filters are supplied (all 0 params are optional). Adequate but thin.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a limit buy or sell of a listed stock token against USDC (Base) or USDG (Robinhood Chain): an exact approve only when the allowance is short, then deposit + place. amount = the stock quantity in base units (18 decimals for wt tokens); price = USDC/USDG per 1 token. No fee to place. Returns unsigned transactions for the user to sign in their own wallet, in order; nothing is sent or signed here.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | 0x... address | |
| price | Yes | Plain decimal, e.g. "182.5" | |
| amount | Yes | Base units, e.g. "1500000000000000000" | |
| chainId | Yes | 8453 Base, 4663 Robinhood Chain | |
| buyToken | Yes | 0x... address | |
| sellToken | Yes | 0x... address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint/openWorldHint; the description adds the crucial behavior that this returns unsigned transactions in order for the user to sign, and that nothing is sent or signed here. It also discloses the conditional approve step and the no-fee trait, which an agent would otherwise not know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and scope, then the return/signing caveat, with no filler sentences. It is dense—heavy parenthetical nesting in one long sentence—but every clause carries operational 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?
With six required params and no output schema, the description covers the transaction-building flow, the return value nature (ordered unsigned txs), and the safety model. It stops short of describing the shape of the returned transaction list or how the agent should proceed after signing, which would complete the picture.
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 earns above that by clarifying that amount is a stock quantity in 18-decimal base units and price is quote currency per 1 token, which resolves the ambiguity between 'base units' in the schema and quantity semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (build) and resource (limit buy/sell of a listed stock token), names the quote assets and the two chains, and implicitly separates itself from cancel_limit_order/list_limit_orders by being the order-creation path. An agent can tell what this does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the internal flow (approve only when allowance is short, then deposit + place) and that there is no placement fee, which is useful 'how' context. It never says when to pick this tool over siblings such as trade_link or strategy_link, nor does it state prerequisites like an owner wallet that will sign the returned transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A pre-filled River strategy card link (Base, ST0x stocks). Cards and fields: dip (budget, start, step, rungs); peg (amount, discount, max); recurring (budget, days, hours, max); cycle (budget, buy, step, levels, repeat, top, sell); take-profit (amount, target); sell-ladder (amount, first, last, parts); stop (amount, trigger, floor); breakout (amount, trigger, max); spread (amount, spread, weekend); portfolio (amount, preset, stocks). Missing fields are left for the user. See https://theriver.markets/llms.txt for what each card does. The user reviews this on The River and signs in their own wallet; nothing happens until they do.
| Name | Required | Description | Default |
|---|---|---|---|
| card | Yes | ||
| fields | No | Card fields as plain decimals, e.g. {"amount":"100","discount":"0.3"} | |
| symbol | No | Ticker or token symbol, e.g. NVDA or wtNVDA (not for portfolio) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely non-obvious behavior by clarifying that nothing executes until the user signs in their own wallet, and that omitted fields are deliberately left blank for the user to fill. It does not describe the returned link's shape, but with no output schema that is a minor omission rather than a contradiction.
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 in the first clause, and the long card/field enumeration is information-dense rather than padded. It is a single heavy paragraph, but nearly every token carries routing or field 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 3-parameter, no-output-schema tool, the description covers what the tool returns (a link), how fields are handled, and that user action is required. The reliance on an external URL for per-card semantics is the main gap, but the essentials an agent needs to invoke it are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the enum on 'card' has no schema-level description, so the description's card-by-card field listing (dip: budget/start/step/rungs, etc.) meaningfully compensates for that gap. It stops short of explaining what each field means, deferring to an external llms.txt URL, which weakens the added value somewhat.
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 makes clear this produces a pre-filled River strategy card link, and it enumerates exactly which cards exist (dip, peg, recurring, etc.), so an agent knows what resource it operates on. It does not explicitly distinguish itself from the sibling trade_link, which is the most plausible confusable alternative, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'Missing fields are left for the user' and 'the user reviews this on The River and signs in their own wallet; nothing happens until they do' convey the intended workflow. However, there is no explicit when-to-use-this-vs-trade_link guidance or any stated precondition, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A pre-filled River trade link. A buy by ticker with usd (no address or chain) returns a best-price link that opens the cheapest issuer for the user. Give exactly one of usd (buy only, settlement stablecoin, up to 6 decimals) or qty (tokens, up to 18 decimals). The user reviews this on The River and signs in their own wallet; nothing happens until they do.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | No | Plain decimal, e.g. 50 or 0.25 | |
| usd | No | Plain decimal, e.g. 50 or 0.25 | |
| side | Yes | ||
| chain | No | When a ticker is listed on more than one chain | |
| ticker | No | e.g. NVDA | |
| address | No | Token address (instead of ticker) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, and the description reinforces this by stating the user reviews on The River, signs in their own wallet, and 'nothing happens until they do' — valuable non-execution context beyond the annotations. It also adds validation constraints (usd buy-only, 6 vs 18 decimals) that the annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what the tool produces, then the parameter rule, then the user-consent behavior. Dense but each sentence carries information; only the opening fragment 'A pre-filled River trade link.' is slightly terse.
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 adequately conveys the return (a best-price link opening the cheapest issuer). It explains buy semantics well but leaves sell-mode behavior (e.g., whether usd is allowed on sell) unstated for a tool whose side enum includes 'sell'.
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 83% and the schema only says 'Plain decimal' for usd/qty, but the description adds real meaning: usd is buy-only settlement-stablecoin with max 6 decimals, qty is tokens with max 18 decimals, and exactly one must be supplied. That mutual-exclusion rule appears nowhere in 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 names the specific resource (a pre-filled River trade link) and the operation that produces it, so an agent knows this tool generates a shareable order link rather than executing a trade. It stops short of distinguishing itself from strategy_link, the other link-generating sibling, leaving that comparison to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete selection rules: exactly one of usd or qty, and 'a buy by ticker with usd (no address or chain)' as the path that yields a best-price link. It does not explicitly say when to prefer this over strategy_link or list_stocks, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Any wallet's stock-token and cash balances on every chain The River serves (public onchain data), plus its read-only River profile link.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | 0x... wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context by labeling the data 'public onchain data' and the profile link 'read-only', but says nothing about rate limits, error cases, or which chains are included.
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 information-dense sentence with the primary payload (balances) front-loaded and the secondary payload (profile link) trailing. It is slightly awkward as a verbless noun phrase, but no sentence 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?
No output schema exists, so the description correctly enumerates what is returned (balances plus a profile link). Annotations cover safety and the schema covers the sole parameter; only the set of supported chains and pagination/response shape remain unstated, which 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?
With a single parameter and 100% schema description coverage ('0x... wallet address'), the schema already carries the semantics. The description's 'any wallet's' adds no format or constraint detail beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource precisely (stock-token and cash balances per wallet) and adds scope ('every chain The River serves') plus a secondary return ('read-only River profile link'). It lacks an explicit verb and does not distinguish itself from siblings like fair_value, but the resource is unambiguous enough for an agent to select it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives such as fair_value or list_stocks, and no prerequisites or exclusions. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Any wallet's profit and loss on Base, from public chain data. Wallet: its stock tokens since 1 Oct 2026, average cost from the wallet's own USDC trades on any venue (DEX or orderbook), realised and unrealised per token; transfers are never priced. Strategies: one row per strategy (live and cancelled orders it placed, incl. its RiverAccount): fills, USDC spent and received, tokens bought and sold, and P&L at today's prices (value now minus what was put in). Robinhood Chain is not counted yet (stated in notes).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | 0x... wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true/openWorldHint=false, and the description substantially exceeds that bar with genuine behavioral detail: cost basis is derived from the wallet's own USDC trades on any venue, transfers are explicitly never priced, coverage of 'live and cancelled orders' is stated, and the P&L formula (value now minus what was put in) is spelled out. These are exactly the nuances an agent needs to interpret results correctly.
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 in the first clause, and the dense remainder is information-dense rather than padded — each clause adds a rule (pricing method, exclusions, strategy row contents). The heavy semicolon structure makes it harder to parse than ideal, 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?
With no output schema, the description correctly carries the return-shape burden, defining both the per-token and per-strategy row contents. Coverage limitations are disclosed. The only friction is the oddly specific and possibly erroneous 'since 1 Oct 2026' cutoff, which invites confusion about the accounting window.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (address) and schema description coverage is 100%, so the schema fully documents the input. The description adds no syntax or format guidance for the address beyond what the schema already provides, which is the baseline-3 case.
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+resource: profit and loss for any wallet on Base, computed from public chain data, with per-token and per-strategy breakdowns. Scope limits (Base only, Robinhood Chain excluded, transfers never priced) make the deliverable unambiguous. It does not, however, distinguish itself from the sibling wallet_holdings, which an agent must choose between.
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 the specificity of the output ('realised and unrealised per token', 'one row per strategy'), so an agent can infer when P&L is the right request. But there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. wallet_holdings for raw positions), so the routing decision 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.
Withdraw an exact amount (base units) or everything (max: true) from one of the owner's orderbook vaults to their wallet. Returns unsigned transactions for the user to sign in their own wallet, in order; nothing is sent or signed here.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | ||
| owner | Yes | 0x... address | |
| token | Yes | 0x... address | |
| amount | No | Base units | |
| chainId | Yes | 8453 Base, 4663 Robinhood Chain | |
| vaultId | Yes | 0x... 32-byte vault id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=true, the description adds real behavioral context the annotations don't convey: it returns unsigned transactions in order, and nothing is signed or sent here. It doesn't cover auth requirements, vault prerequisites, or failure modes, keeping it at a 4.
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 filler, and the core action and modes are front-loaded ahead of the non-obvious unsigned-transaction caveat.
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 helpfully covers the return shape (ordered unsigned transactions) and confirms nothing is sent. It stops short of describing what per-transaction fields the caller receives, which an agent would need to know to chain signing steps.
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 high (83%), establishing a baseline of 3, and the description adds value by explaining the undocumented 'max' flag ('everything (max: true)') and that 'amount' is in base units. It still doesn't clarify the mutual exclusivity or precedence of amount vs max.
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 ('Withdraw ... from one of the owner's orderbook vaults to their wallet') plus the two modes (exact base-unit amount or max). This clearly separates it from read siblings like wallet_holdings and from order-entry siblings like place_limit_order.
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 gives clear operating context: it withdraws from the owner's orderbook vault to their wallet and returns unsigned transactions for the user to sign. It does not explicitly name an alternative tool or state when-not to use it, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cancel_limit_orderlist_limit_ordersplace_limit_orderwithdrawcompare_issuerswallet_pnlstrategy_link1 field changedInput schema / properties / card / enumPrevious value: -[
- "dip",
- "peg",
- "recurring",
- "cycle",
- "take-profit",
- "stop",
- "breakout",
- "spread",
- "portfolio"
-]New value: +[
+ "dip",
+ "peg",
+ "recurring",
+ "cycle",
+ "take-profit",
+ "sell-ladder",
+ "stop",
+ "breakout",
+ "spread",
+ "portfolio"
+]fair_valuelist_stocksstrategy_linktrade_linkwallet_holdingsRead-only tokenized stock data: issuers, chains, contract addresses and corporate actions.
Browse, backtest and write rule-based portfolios of tokenized US stocks.
US stock filings, funds, insiders and Hyperliquid wallets, with sources and dates. Read-only.
Live market data & technical analysis for US stocks, ETFs and crypto. Read-only, no signup.
Add one secure layer between your agents and this server.
