Moby

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the destructiveHint/readOnlyHint annotations: it states no funds move, that the action is irreversible, the concrete consequence of cancelling a stop-loss (position left unprotected, re-entry at whatever price is available), and that order-type switches do not block cancellation. These are exactly the side-effect details an agent needs before an irreversible call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five tight sentences, front-loaded with what the tool does and the selection rule, then escalating to irreversibility and confirmation guidance. No redundant restatement of the 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?

Mutation tool covered by annotations and a dedicated output schema, and the description still supplies the gap-filling context: side effects, reversibility, parameter exclusivity, and user-confirmation etiquette.

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 already 100%, but the description adds real meaning: the exactly-one constraint, the provenance of each ID, and the schedule semantics ('stops every remaining slice, filled slices stay filled') which the schema does not convey.

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 (cancel) and two concrete resources (a resting order or a whole DCA schedule), plus the effect — 'so it can no longer fire'. This is clearly separable from siblings like create_order or get_my_orders.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit mutual-exclusion rule ('Pass EXACTLY ONE of `order_id` or `schedule_id`'), routes the agent to the source tools (`get_my_orders`, `get_my_dca_schedules`), and adds a disambiguation instruction to confirm with the user when multiple orders exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as destructive, open-world, and non-idempotent, but the description adds critical context: it spends real money, submits a real wallet transaction, cannot be undone, and requires explicit user confirmation. It also discloses trade-limit behavior, buy-vs-sell volume accounting, bracket leg behavior, cancellation interactions, refusal reasons, and that Moby does not retry or re-arm orders.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but appropriately sized for a destructive tool with eight order types and complex bracket/DCA behavior. The safety warning is front-loaded, and the order-type rules are organized as a scannable list with no obvious filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich annotations, 90% schema coverage, and an output schema, the description fills the remaining behavioral gaps: confirmation requirements, trade limits, bracket leg results, partial-exit cancellation behavior, refusal handling, and SOL limitations. An agent has enough information to invoke this tool correctly and safely.

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, but the description adds substantial conditional meaning beyond the schema: order_type determines which price arguments are required, amount means the funding asset on buys and the held token on sells, trigger_buy uses stop_loss_price, and DCA orders require order_count and interval_seconds with no price argument. It also clarifies that all prices are USD prices of the token.

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: place a resting order that executes later when a condition is met. It enumerates the exact order types and distinguishes this tool from quick_sell for immediate market closes, so an agent can tell it apart from siblings 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?

It explicitly says when to use this tool versus alternatives: use quick_sell to close or trim at market now, and place TP/SL here after a buy because Moby attaches no automatic exits. It also explains which order_type to choose for each trading intent and how to handle bracket failures.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/destructive/openWorld, so the bar is lower; the description still adds real behavior beyond them — the include/exclude asymmetry for followed wallets depending on `query`, and the scope caveat that this is whole-market data, not the user's own holdings. Missing only operational traits like ranking criteria or result staleness.

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 definition and the query/no-query split before the disambiguation tail. The `get_my_` prefix rule takes two sentences to state one idea, which is mild redundancy but still informative.

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?

An output schema exists so return shape need not be explained, and the description covers scope, filtering semantics, and sibling routing. The remaining gap is the undocumented `wallet_type` filter, which an agent would have to guess at.

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 50% schema coverage the description must compensate, and it does for `query` (name/brand or exact pasted address, followed wallets included) — meaningful value beyond the schema text. However `wallet_type` (all/kol/trader/whale) and the fixed `network` const receive no explanation anywhere, leaving one filter opaque.

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 ('Find-Wallets suggested pool: PUBLIC wallets ranked for discovery') and immediately names what each row carries (`is_following`). It explicitly separates itself from `get_my_followed_wallets` and the `get_my_` family, so an agent can route 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?

Gives explicit branches: with `query` it searches by name/brand or exact pasted address and includes followed wallets; with no `query` it returns a ranked pool excluding already-followed wallets, and points to `get_my_followed_wallets` for those. The when-not (this is not user-specific data) is also stated outright.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructive + non-idempotent, but the description adds material context beyond them: real funds, irreversibility, only the user could authorize, quote-expiry failure mode, and the `fill_pending: true` state meaning the fill is not yet booked. That last detail is behavioral knowledge an agent could not infer from schema or annotations.

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 purpose sentence comes first, the money warning is immediately second and visually marked, and the AMOUNTS paragraph is separated by a label. Length is justified for a destructive financial action; no filler sentences.

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?

Output schema exists, yet the description still adds the critical unit caveat (`_ui` = whole tokens vs smallest-unit raw fields) and the null-vs-zero distinction with a pointer to `get_swap_status`. Nothing an agent needs to call or read the result 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?

With one parameter at 100% schema coverage the baseline is 3; the description earns above that by tightening the constraint to a `quote_id` returned by `get_swap_quote` in this same conversation, ruling out stale or cross-session IDs.

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 and draws a hard line against `get_swap_quote`, clarifying that this one spends funds while the sibling only prices. It does not, however, distinguish itself from `quick_buy`/`quick_sell`, which are also fund-spending execution tools an agent could plausibly reach for instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit preconditions (quote_id from `get_swap_quote` in the same conversation, user confirmation of amount/token/network in plain language), an explicit prohibition ("Never call this to 'check' anything"), and the recovery path when a quote expires. Few definitions route an agent this completely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotency and non-destructiveness, and the description adds concrete behavioral context: following an already-followed wallet is a no-op and does not count against `max_follows`, no money moves, no agentic wallet is needed, and the call fails at the cap. These are exactly the side-effect and auth details an agent needs before invoking.

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 action and effect, followed by the key caveats. No filler or repeated 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the remaining operational context needed to invoke correctly: public-only targeting, idempotency caveat, follow-cap behavior, and no agentic wallet requirement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents `wallet_address` as a public wallet ref and `custom_name` with its 50-character limit. The description reinforces that the target must be public but does not explain `network` or `custom_name` behavior, so it adds only marginal meaning over the 67%-covered 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, 'Follow', and resource, 'PUBLIC whale/KOL/trader wallet', and names the downstream effect in `get_my_following_feed`. This clearly distinguishes it from siblings like `unfollow_wallet`, `discover_wallets_to_follow`, and `get_my_followed_wallets`.

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?

Explains the use case (followed wallet's trades appear in the following feed), constrains the target to PUBLIC wallets, and notes that it fails at the follow cap. It does not explicitly direct the agent to `discover_wallets_to_follow` for finding candidates, so alternative guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly/openWorld; the description adds materially more: volatility and short-lived-token risk, best-first ranking with page 1 as top, a results cap with context-cost rationale, and precise semantics for the whale block (buyers-plus-sellers vs buyers-only) and safety_tier colors (grey is not a red flag; Moby refuses agent buys on red). This is exactly the context annotations cannot carry.

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 critical differentiator and the risk warning are front-loaded, and each paragraph covers a distinct concern (identity, routing map, pagination discipline, whale block, asset class, safety tier). It is dense and long, but nearly every sentence earns its place; the Solana group-id addendum is the only slightly expendable part.

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?

Covers everything needed to call this correctly despite an output schema already existing: risk framing, ordering, pagination limits, optional whale block semantics, asset_class handling, safety_tier interpretation, and an explicit note that this is market-wide data not user wallet data (distinguishing it from the get_my_* 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?

Schema coverage is 75% and the schema already documents page/limit, but the description supplies the meaning the schema omits: guidance to keep limit small, the cost tradeoff of paging, and — critically — what `whale_windows` produces per row (whale_count, buyers vs sellers, net flow, and the correspondence with `whale_count_h24`), which the schema never explains.

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 exact resource ('the high-risk degen leaderboard') and immediately contrasts it with `get_screener_leaderboard` as newer, smaller, more volatile tokens. An agent can distinguish it from every sibling leaderboard tool without opening a 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?

Provides an explicit routing map across all five leaderboards (Main/Degen/Majors/Stocks/Pulse) with the exact group ids, plus concrete when-to-use rules ('raise limit or step page only if the answer is genuinely not in the first page'). Also warns never to resolve majors/stocks by ticker search, which prevents a common misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, non-destructive), and the description layers on non-obvious behavior: results are capped, large results consume context needed later, null figures mean unknown, safety_tier grey is NOT a red flag while red is the only warning tier, and Moby refuses agent buys on red. It also disambiguates public market data from get_my_* wallet tools, which prevents a real class of misuse.

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 purpose and routing, and most sentences earn their place. It is dense, though, and the per-field whale block explanation partially duplicates what the output schema already defines, so a little length could be trimmed without losing routing value.

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 read tool with a rich output schema, this covers everything an agent needs to call it correctly: id provenance, ordering, pagination cost, tier interpretation, and scope (market data vs. user data). No ambiguity remains about what the call will return or how to interpret edge values like grey tier and nulls.

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 60% and group_id has no schema description at all, but the description fully compensates: it names the source tool, gives literal example ids (home_majors, home_stocks, home_pulse, majors_solana), and forbids guessing. For whale_windows it adds the meaning of each returned whale field and clarifies whale_count is buyers-plus-sellers, not buyers alone — semantics the schema does not carry.

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?

Opens with a specific verb+resource: ranked tokens inside one group/category, best-first. It then explicitly separates itself from the closest siblings (get_screener_leaderboard, get_degen_leaderboard) and names the concrete group_ids that select the Majors/Stocks/Pulse variants, so an agent can route correctly without opening another 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?

Gives explicit when-to-use routing across five boards, plus a hard precondition (group_id must come from get_screener_groups, never invented) and a negative instruction (never resolve a major or stock by ticker search, never keep your own mint list). It also states when not to paginate — only if the answer is genuinely not on page 1 — which is exactly the kind of usage guidance agents need.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds value the annotations cannot: that the result is whole-market public data rather than user-scoped data, which prevents a class of misinterpretation. It does not mention result limits, pagination, or whether an empty list means 'no tracked KOLs' versus 'untracked token', so it is not fully complete.

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 short sentences with the core definition front-loaded, followed by the sibling relationship and the data-scope caveat. The final get_my_ sentence is slightly tutorial-ish but earns its place as a broad disambiguation rule across a large sibling set. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape explanation is correctly omitted, and annotations cover the safety profile. For a two-parameter read-only lookup, the description supplies everything needed to decide to call it and interpret the result as market-wide rather than personal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden, and it barely does. 'This token' only obliquely implies the required token_address parameter, giving no format or network expectations, and the network parameter (const 'solana') is never mentioned at all. An agent learns nothing beyond the name of the concept being queried.

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 ('Tracked KOLs holding this token') and immediately defines the ambiguous term KOL as 'named public traders/influencers'. It also positions itself against siblings by calling itself 'the KOL-only slice of get_token_key_holders', so an agent can distinguish it from get_token_key_holders, get_whale_holders, and get_top_held without opening any 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 gives a clear selection rule via the negative case: it is 'NOT about the user's own wallet or holdings', and get_my_* tools are the ones for personal data. That is a real disambiguation across a sibling list full of get_my_* tools. It stops short of explicit when-to-use framing such as 'use this when you need KOL conviction vs. all holders', leaving the choice against get_token_key_holders partly inferential.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered by structured data. The description adds value by scoping the data as public market-wide rather than user-specific and by flagging that newly launched tokens are the riskiest category — a genuine caveat for downstream reasoning. It says nothing about result volume, ordering, or freshness, which 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?

Front-loaded with what the tool returns, then the routing exclusion. The sentence about newly launched tokens being the riskiest category is slightly tangential and could be trimmed, but it does carry decision-relevant risk context rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return shape needn't be described; the only parameter is a constant. Given that, the description covers everything an agent needs — what the data is, when to reach for it, and the critical distinction from the many `get_my_*` siblings in this toolset.

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 `network` parameter is a const 'solana' with a default, so the schema fully constrains it even at 0% description coverage; there is no ambiguity for the description to resolve. The description adds nothing about the parameter, but there is nothing meaningful to add, landing at the expected baseline for a near-parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names the resource and the grouping axis precisely ('tokens grouped by the launchpad they were created on') and gives a concrete example (pump.fun), which is more specific than a generic 'get launchpads'. It stops short of naming a functional sibling (e.g. search_tokens, get_token_live_feed) that returns similar data under a different lens, so differentiation is present but indirect.

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?

Explicitly gives a use case ('what launched recently' questions) and an explicit exclusion: it is not about the user's own wallet, and `get_my_` tools are the ones for user data. This is a real routing rule, though it points at a naming convention rather than naming a specific competing tool for market-wide token discovery.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, non-destructive, open-world, non-idempotent), so the description focuses on what annotations cannot express: newest-first ordering, the polling/paging idiom, and the crucial split between fields that are AS OF NOW (liquidity, smart-money flow) versus AT EVENT TIME (market cap, price). It does not cover rate limits or freshness lag for polling, which keeps it off 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?

Front-loaded with the core definition and the change-vs-rank distinction, then field semantics, then the wallet-scope disclaimer. Dense and mostly waste-free, though the closing two sentences about `get_my_` tools are somewhat belabored for a point already implied by the prefix convention.

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 9-parameter, zero-required read tool with an output schema, the description covers everything an agent needs: what an event is, ordering, temporal field semantics, pagination strategy, and the scope boundary versus personal-data tools. Return shape is delegated to the output schema, as allowed.

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 89%, so the baseline is 3; the description still adds real semantic value by explaining how `after_timestamp` and `before_timestamp` are meant to be used (polling vs. back-paging) rather than just what they filter. It also clarifies the scope implied by `token_address` filtering ('omit for the whole market') implicitly through its whole-market framing.

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: a screener event stream of discrete token events (price/volume moves, notable activity) over a period, newest first. It explicitly contrasts itself with the leaderboards ('the event stream behind the leaderboards') and with `get_my_` tools, so an agent can place it against `get_screener_leaderboard` and `get_screener_event_filters` without opening a 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?

Gives an explicit selection rule — use it when the user asks what CHANGED or HAPPENED rather than what ranks highest now — which directly routes between this and the leaderboard siblings. It also names two concrete usage modes with their parameters: poll forward with `after_timestamp`, page back with `before_timestamp`.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/non-destructive, but the description adds substantial context beyond them: data is server-persisted so all clients see it, scope is resolved from the caller's API key with no cross-user access, `app_links` are user-facing deep links, and it explains how `active` vs `paused` vs stopped should be treated.

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 identity and returned field list, then usage rules. It is dense and nearly every sentence earns its place, though the field enumeration partly duplicates the output schema and adds length.

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?

Despite an output schema existing, the description covers scope, timing, status handling, and the meaning of `app_links`, leaving nothing an agent would need to call it correctly. Complete for a read-only, single-optional-param 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% and the single `include_stopped` boolean is already documented in the schema. The description restates the same behavior ('pass include_stopped=true for stopped ones too') without adding new meaning, so the baseline of 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 ('the strategies the user's agents are running') and scopes it tightly to the current user's own persisted data. It does not explicitly name or contrast with the sibling `list_strategies` or `get_strategy`, which is the one thing keeping it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit timing ('at the start of every session' and 'before starting a strategy') plus the reason (prevent duplicate runs across sessions) and behavioral rules (resume `active` on its `schedule`, leave `paused` alone unless asked). This is when-to-use guidance with concrete operating instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare read-only/non-destructive; the description adds the operationally critical traits: cursor-based pagination with an explicit warning not to send a page number, and identity resolution from the API key. These are exactly the behaviors that cause failed calls when undisclosed, and they are stated up front.

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 purpose, then pagination warning, then sibling routing, then scope — a sensible priority order. Slightly longer than necessary; the '⚠️' framing and repeated pagination point cost a little density, but every sentence carries distinct 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 annotations, a full output schema, and high schema coverage, the description covers the remaining gaps: ordering, pagination protocol, identity scope, and sibling routing. Only minor omissions remain, such as no hint about expected page sizes or whether the feed mixes categories by default.

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 80% and the schema already documents `cursor`, `limit`, and the `category`/`token_address` dependency (including the buys/sells/closed_trades rejection rule). The description reinforces cursor semantics but adds no parameter detail beyond the schema; the most valuable conditional logic lives in the schema, 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?

States a concrete verb and resource ('wallet activity feed') and enumerates the contents (trades, transfers, deposits, withdrawals) plus ordering ('newest first'). It explicitly distinguishes itself from the sibling `get_my_transactions` and scopes to the current user, so an agent can tell the two history tools apart without opening a 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?

Provides an explicit decision rule: prefer activity for 'what have I been doing', use transactions when a specific type such as deposits is needed, with the structural reason (merged human-readable timeline vs. raw filterable list). It also states a hard exclusion — there is no way to query someone else's wallet with this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover safety/read semantics; the description adds far more — cache staleness on non-native balances, chain vs ledger `balance_source` and what `ledger_disagrees` actually means, the ledger-vs-chain quantity trap that can make a sell fail on-chain, and null USDC fields when orders are unreadable. None of this contradicts the annotations (readOnly=true, destructive=false are consistent with a self-scoped read).

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?

Roughly 700 words for a two-parameter read tool, with the core answer buried under repetition — chain-vs-ledger authority is stated twice, and the closed-positions warning is re-emphasized in capitals. Bullets help structure, but a large share of sentences could be cut without losing decision-relevant 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?

Despite an output schema, the description maps every response section (`tokens`, `native_token`/`usd_token`, `swap_user_tokens`, `available_usdc`/`reserved_usdc`/`reserved_breakdown`, `app_links`, `interview_due`) and warns against the double-count and double-spend errors. An agent has everything needed to call it and interpret the result correctly.

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 carry the load; it explains `refresh` thoroughly, including cost (much slower) and the precise trigger for using it. The `network` parameter is never mentioned, though as a const `solana` with a default it carries no decision for the agent.

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?

Opens with a specific verb+resource+scope: the CURRENT USER's holdings in their Solana agent wallet with balances and USD values. It explicitly differentiates from siblings — `get_my_portfolio` for equity totals, `get_my_token_balance`/`get_my_position` for single positions, `get_my_closed_positions` for exited positions — so an agent can route without opening another 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?

Gives explicit when-to-use and when-not-to-use: use for per-token detail and the affordability check, use `get_my_portfolio` for a single equity total, check `get_my_orders` when the USDC fields are null. It also spells out the refresh condition (call once more with `refresh=true` only after an off-Moby deposit doesn't show, never routinely because it is much slower).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly/non-destructive/openWorld; the description adds genuinely non-obvious behaviour — data is scoped to the calling user's API key with no way to query another wallet, results are position-level rollups rather than fills, and an empty response means 'never closed a position' rather than 'holds nothing'. These are semantic traits the annotations could never convey.

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 distinction and the highest-risk warning, so skimming yields the right behaviour. It does repeat the 'closed only' point twice (the IMPORTANT sentence and the empty-result sentence), costing some length for a four-parameter read tool.

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?

An output schema exists, so return shape needn't be described; the remaining gaps an agent could hit — user scoping, empty-result interpretation, and the position-vs-trade granularity — are all covered.

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 75% (page, limit, and token_address are documented in the schema), so the baseline applies. The description adds nothing about the `token_address` filter, which is the one parameter whose usefulness ('how did I do on X') is implied but never spelled out, and says nothing about paging behaviour.

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?

Opens with a specific verb+resource and scope: closed positions the user has fully exited, with realised PnL. It explicitly separates itself from `get_my_balances` (open positions) and `get_my_closed_trades` (individual fills), so an agent can pick the right tool without opening any 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?

Gives an explicit decision rule: positions for 'how did I do on X', trades for 'show me every trade'. It also states a when-not ('never tell a user they hold nothing based on an empty result') and names the alternative that answers holdings questions, which is precisely the failure mode for this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a read-only, non-destructive operation, and the description adds substantial behavioral context: data is scoped to the current API-key user, token_address is required with no cross-token mode, and include_fills=false skips fill legs. It also explains that rationale is null when absent and that empty closed positions do not imply no holdings.

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 key scope and sibling distinction are front-loaded and most sentences carry useful operational guidance. It is somewhat long and has a slight tension between 'one entry per closed buy→sell cycle' and later 'one entry per fill', which could be tightened.

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 this read-only history tool, the description covers scope, user isolation, required token constraint, sibling alternatives, fill inclusion behavior, and important empty-result caveats. With an output schema present, return-value detail need not be repeated.

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 only 20%, so the description must carry semantics; it does so well for the required token_address and for include_fills. It does not explain page, limit, or network beyond the schema titles/defaults, so it is strong but not fully compensatory.

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 retrieval purpose: the current user's completed trades, newest first, with the cycle/fill structure and realised result. It explicitly distinguishes this tool from get_my_closed_positions by contrasting trade-level vs position-level history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit usage guidance: use positions for 'how did I do on X' and trades for 'show me every trade', and use get_my_balances for still-held positions. It also states the required one-token-at-a-time constraint and that asking about another wallet is impossible.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only nature implied by annotations, the description clarifies operational behavior by stating the default scope (live schedules only) and how to override it using `include_terminal`. It also asserts data privacy boundaries regarding the 'CURRENT USER's own data.'

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?

While dense, the structure is highly logical, starting with a definition, moving to differentiation, and ending with operational rules and scope constraints. Every piece of information serves a critical function in guiding tool selection.

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 complexity and the necessity of distinguishing this tool from related siblings, the definition is highly complete. It covers functionality, scope, error handling, and usage context thoroughly.

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 description adds semantic meaning to the `include_terminal` parameter by explaining that setting it returns 'finished and cancelled schedules,' adding necessary context beyond the schema's simple type definition. It also clarifies the scope of the `network` parameter contextually.

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 provides an explicit definition of DCA schedules (recurring buys/sells with slices and progress) and strongly differentiates the tool from the sibling `get_my_orders`, specifying it is for DCA rows alone.

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 provides explicit usage guidelines, instructing agents to use this tool when `get_my_orders` is insufficient, and offers a crucial workflow tip regarding the `dca_schedules_error` case, requiring a call to this tool before concluding there are no DCA schedules.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and destructiveHint=false annotations, the description discloses that data is scoped to the current API-key user, newest-first ordering, the status values, and the presence of a team reply when available. It does not cover pagination behavior or limits in detail, but the annotations already carry the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, then adds scope and usage details without unnecessary repetition. Every sentence contributes useful 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 read-only two-parameter list tool with an output schema and full annotation coverage, the description is complete enough: it explains the returned fields, ordering, user scoping, status values, and the inability to query other users. No critical agent-facing information 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 both the limit and status parameters are already well documented in the schema. The description adds context around status values and ordering but does not add parameter-level meaning beyond what the schema provides, making the baseline 3 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?

The description clearly states the tool returns the current user's earlier feedback submissions and their statuses, including fields and ordering. It also distinguishes this from querying another user's data, which sharpens the scope against sibling tools like submit_feedback.

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 usage context: mention a shipped item to the user when relevant, and it explicitly notes that this only returns the current user's own data with no way to query someone else's wallet. It does not explicitly name submit_feedback as the alternative for adding new feedback, but the context is otherwise clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's job is additive context, and it delivers: the response includes max_follows so 'N of 50' can be reported without a second call, includes list associations and nicknames, and is scoped strictly to the API key's owner. It does not discuss ordering or whether follows are paginated, which is the remaining gap.

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 the return payload before the access-scope caveat. The 'N of 50' example earns its place by telling the agent why max_follows matters rather than just listing it.

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?

An output schema exists and there are no parameters, so the description only needs to cover scope and the notable return fields — both are done, including the unusual max_follows field and the per-row associations. Nothing an agent needs to call this 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?

Zero parameters, so there is nothing to mis-specify and the baseline is 4. The description correctly describes max_follows as a returned field rather than an input, avoiding the confusion of implying a filter exists.

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 — every wallet the CALLER follows — plus the extra payload each row carries (max_follows, list associations, nicknames). The clause 'This returns the CURRENT USER's own data, resolved from their API key' cleanly separates it from get_whale_wallet_* and search_whalewatch_wallets, which query other people's wallets.

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 makes clear when this tool applies (you want your own follow list) and rules out querying someone else's follows. However, it never names the adjacent alternatives an agent would realistically weigh — get_my_following_feed for activity from followed wallets, get_my_wallets for wallet holdings, or follow_wallet/unfollow_wallet for mutation — so routing is left to inference from names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare read-only/open-world safety; the description adds caller-scoped resolution from the API key, the hard constraint that other wallets cannot be queried, results being capped, and the cost of large pages. These are behavioral facts the annotations do not carry.

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 definition, then the critical empty-result warning, then pagination and scoping caveats — a sensible priority order. It is dense rather than padded, though the 'filters mirror that tool' sentence is slightly meta and could be tighter.

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?

An output schema exists, so return shape needn't be described; the description instead covers the things that actually cause mistakes — empty-result misinterpretation, caller-only scope, and pagination cost. Nothing an agent needs to invoke this 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 83% and already documents each filter, so the schema does most of the work. The description still adds value by framing the filter set relative to the whalewatch feed ('minus list selection, since following is orthogonal to lists') and by advising against large `limit`/deep `page` values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: 'Trades made by wallets the CALLER follows, newest first.' It explicitly contrasts with the sibling `get_whalewatch_feed` (market-wide), so an agent can pick between them without opening a 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?

Gives an explicit when-not: empty means 'you follow nobody or nobody you follow traded recently,' not 'no whale activity anywhere,' and names the alternative `get_whalewatch_feed` for market-wide data. It also bounds when to raise `limit`/`page` ('only if the answer is genuinely not in the first page').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and destructiveHint=false, so the description's added value is the enforcement semantics: maxTradeUsd caps buys only, sells into USDC never count, cancelled buys release reservations, and paused blocks everything. It also discloses that data is resolved from the caller's API key with no way to query another wallet, and mentions platform rate limits. Minor gap: it doesn't say what a refusal/error response looks like, though that likely lives in the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the imperative and the READ-ONLY constraint, and the bulleted field breakdown is scannable. However, it is very long for a zero-argument getter, and much of the field-by-field explanation overlaps with the output schema that already exists — several clauses (e.g. the trailing restatement that this returns the current user's data) could be trimmed without losing meaning.

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 no-parameter, read-only tool with an output schema, the description covers everything an agent needs: what the fields mean operationally, how the daily volume math works, when trades get refused, and where the user must go to change limits. Nothing required for correct 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?

Zero parameters, so the baseline is 4. The description spends its words on return-field semantics instead, which is a reasonable use of the space but is not parameter documentation.

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 precisely — the trading limits the user set on the agent in the Moby app — and immediately marks it READ-ONLY. No sibling tool returns guardrails, and the description makes the scope unambiguous in the first clause.

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?

Explicitly tells the agent to read this before planning trades 'instead of discovering limits by refusal,' which is a concrete when-to-use trigger. It also explains that only the user can change the limits and that app_links.settings is where they do it, so the agent knows the correct escalation path rather than attempting a write.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/destructive annotations, it discloses critical behavioral facts: this resolves the current user's data from their API key with no way to query another wallet, that a null dca_schedules means the read failed rather than no DCAs, and the data_warning self-contradiction rule. It also explains the origin field lifecycle and what each output field carries.

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?

Well front-loaded, opening with the core scope before expanding into history, row-reading, and DCA details. However, it is dense and somewhat repetitive toward the end (restating the DCA/orders relationship twice), which slightly exceeds what's needed given the schema already covers the params.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-param tool with an output schema and rich annotations, the description covers scope, history mode, fallback behavior, literal field interpretations, and multi-tool interactions. Nothing an agent needs to call it correctly or interpret results 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 86%, so the schema already documents most params. The description adds real meaning: status='terminal' = full history, page stepping only when the answer isn't on page one, and token_address matching either the sold or bought token. It mostly reinforces rather than extending the schema, so a 4 rather than a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource ('The user's single orders — limit orders, take-profit and stop-loss') and immediately qualifies the default scope ('only LIVE ones, not executed yet'). It explicitly differentiates from siblings like get_my_dca_schedules and clarifies the boundary that a DCA's slices never appear here.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use conditions: 'use that before placing a new order (to avoid duplicates) and to find an order_id for cancel_order.' It also gives the history trigger ('pass status=terminal') and a fallback instruction to call get_my_dca_schedules when dca_schedules is null. No sibling ambiguity remains.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral context beyond them: the scope excludes non-agent wallets, excluded_wallets explains omissions, refresh=true is much slower because it performs a vendor round trip per wallet, and the tool only returns the current user's own data. These details materially affect correct invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with scope and purpose, then usage guidance, then parameter behavior. It is longer than typical but mostly justified by the tool's scope and refresh complexity, though some repeated emphasis on not double-counting wallets could be tightened.

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 output schema, the description does not need to document every return field, yet it still explains the key return structure: summary.hero_usd, summary.wallets, holdings.items, trading_balances.items, excluded_wallets, and scope. It also covers onboarding gating and freshness behavior, leaving no material gap for correct use.

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 carry the burden for the single refresh parameter. It explains exactly what refresh=true does, how costly it is, and when it should and should not be used, which is more than enough to compensate for the missing 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?

The description states a specific verb and resource: returns everything the user's agent holds in one call, with a combined total over the agent's own wallets only. It explicitly excludes Copy Trading and manual wallets and distinguishes itself from get_my_balances, so an agent can identify its role without opening any 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?

It gives explicit when-to-use guidance: start here for 'how am I doing', 'what do I own', and 'what is my agent worth'. It also names the alternative get_my_balances and the condition for using it instead, warns when refresh=true is appropriate, and says to go back to onboarding first when interview_due is true.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the read-only/idempotent annotations by explaining that the result is always the API key's own data, that there is no way to query another wallet, how null money fields mean unknown rather than zero, and what ledger_present: false implies. It also warns that lifetime invested/sold totals use a different denominator from current cost basis, which prevents a common analytical error.

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 and well organized with bullets, and much of the detail is genuinely useful for avoiding misinterpretation. However, the description is extremely long for a two-parameter read tool, and it duplicates a lot of return-field semantics that an output schema can carry, so it is dense rather than concise.

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 complexity of mixing chain balances with a swap ledger, the description covers the critical edge cases: unknown versus zero, scope differences between PnL measures, ledger-present false, TP/SL inclusion, and closed-cycle history. With an output schema present, it does not need to explain return formatting, and it leaves no major behavioral gap for calling the tool correctly.

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 for parameter meaning, but it does not explain token_address or the network field. The phrase 'ONE token' and the incidental token_address in the get_my_closed_trades reference give a hint, but there is no description of required format or what network does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: the current user's position in exactly one token, including holdings, cost, and unrealised PnL, with the example query 'am I up on X'. It explicitly separates itself from sibling tools like get_my_balances and get_my_token_balance, so an agent can choose it 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?

Gives explicit usage guidance ('Use this for am I up on X') and names the alternatives for the underlying data: chain balances from get_my_balances/get_my_token_balance, and per-fill legs from get_my_closed_trades. It also states a strong when-not-to: never quote a ledger quantity as the amount held, because ledger and chain amounts diverge.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover the safety profile (readOnly, openWorld, non-idempotent, non-destructive). The description adds genuinely non-obvious behavior: empty results are a valid answer rather than an error, and identity is resolved server-side from the API key with no way to target another user. That is exactly the context annotations cannot convey.

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, each doing distinct work: definition, empty-result semantics, and data-scoping. The core identity of the tool is front-loaded in the first clause with zero preamble.

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?

An output schema exists, so return-shape explanation is unnecessary; the description only needs to cover scoping and edge cases, and it does both (empty array, caller identity, no cross-user access). Nothing an agent needs in order 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?

Only one parameter exists `network`, whose schema entry is a bare const with no description. Because it is a single-value const (solana) it needs no elaboration, and the description is not obliged to mention it. The 0% schema coverage is harmless here, but one clause confirming the network scope would have made it airtight.

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: tracked wallets overlapping the CALLER's own holdings, and pins the response shape to the familiar `get_whalewatch_wallet_list_detail`. The explicit 'CALLER's OWN' and 'no way to ask about someone else's wallet' cleanly separates it from whale-wallet and discovery 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?

The 'For you' framing plus the empty-holdings scenario gives a clear condition for using it, and it explicitly rules out the wrong use (querying another user's wallet). It stops short of naming a concrete alternative for the adjacent case, e.g. `discover_wallets_to_follow` when the caller holds nothing and still wants suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a read-only, non-destructive operation, but the description adds critical context beyond them: the data is the current user's own and cannot target another wallet, a balance of 0 is a real answer, and chain balance is distinct from Moby's ledger data. It also warns about `ledger_present`, `ledger_disagrees`, and the danger of sizing a sell from ledger quantities.

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 answer is front-loaded in the first sentence, and the warnings are grouped into clear paragraphs. It is fairly long and occasionally repeats the same warning in different words, but the repetition is defensible given the costly failure mode it is trying to prevent.

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 description covers the tool's purpose, alternatives, data provenance, and key caveats, while an output schema exists to explain return fields. For a two-parameter read-only balance tool, the only notable omission is parameter-level detail, which is handled separately in the parameter semantics score.

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 carry the burden of explaining `token_address` and `network`. It implies that a single token is queried and that results are scoped to the current user, but it never mentions the required `token_address` parameter, its expected address format, or the fixed `network: solana` constraint.

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 first sentence states a specific resource and scope: how much of ONE token the user holds right now and its worth. It distinguishes itself from `get_my_balances` (all holdings) and `get_my_position` (unrealised PnL), so an agent can tell when this tool is the right one.

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 explicitly names the use cases: cheapest way to answer 'do I have any X' and sizing a sell before placing one. It also names alternatives and when to use them: `get_my_balances` for everything held, `get_my_position` when unrealised PnL is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, non-destructive), and the description adds substantive behavior the annotations cannot: the v1-to-v2 read mapping, the meaning of interview_due/status states, guardrail_conflicts semantics, and the important disclosure that the scan schedule is never persisted to Moby and must be recreated agent-side each session.

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 highest-priority instruction and the connect-time requirement, then organized as scannable bullets tied to specific response fields. It is long and embeds an entire onboarding workflow script, which is more than a tool description strictly needs, but nearly every line carries operational meaning.

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?

An output schema exists, so return values need not be restated, yet the description still annotates the semantically tricky fields (interview_due, status, recommended_strategies, guardrail_conflicts). For a zero-param read tool plus a multi-step onboarding flow, an agent has everything needed to call it and act on 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?

With zero input parameters the baseline is 4, and the description adds real value by explaining why: 'The wallet is never a parameter. This returns the CURRENT USER's own data, resolved from their API key' and that querying another wallet is impossible. That closes a common misuse path, though there is no parameter surface to describe.

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 plus the exact payload returned (experience, assets, work mode, sizing, protection) and even notes v1 rows are normalized to v2. It also draws an explicit boundary against get_my_guardrails by explaining that the profile is intent while guardrails are enforcement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an unconditional when rule ('call this BEFORE ANY OTHER TOOL on every connect — before balances, portfolio, strategies or research') and enumerates the branch conditions for each `status` value, including the explicit exclusion 'skipped = ... do not ask again unless interview_due is true'. Alternatives and hand-offs (get_my_guardrails, list_strategies, save_trading_profile) are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), and the description adds genuinely non-structured context: the record is scoped to the CURRENT USER resolved from their API key, so cross-wallet access is impossible. It does not describe failure behavior for an unknown or foreign transaction id, leaving a small gap for an idempotent=false read.

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 short sentences, front-loaded with the core purpose, then the prerequisite, then the access-scope constraint. Every sentence carries distinct information; nothing is redundant with the title or 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 read with full schema coverage, annotations, and an output schema, the description covers purpose, id provenance, list-vs-detail routing, and user scoping. No return-value explanation is needed because the output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is documented, so the schema does the heavy lifting (baseline 3). The description adds value the schema cannot: the provenance of `transaction_id`, telling the agent to obtain it from `get_my_transactions` rather than construct or guess it.

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 ('One transaction in full detail, by its id') with explicit singular-by-id scope. It is clearly separable from the sibling `get_my_transactions`, whose name is invoked as the source of ids. An agent can distinguish detail-fetch from list-fetch 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?

Gives an explicit prerequisite ('Get the id from `get_my_transactions` first') and an explicit exclusion ('this tool does not search or list'), which routes the agent to the right sibling for listing. It also rules out a whole class of misuse by stating there is no way to query another wallet.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, non-destructive, open-world behavior. The description adds important behavioral constraints beyond annotations: the result is scoped to the current user resolved from their API key, and there is no way to query another wallet. It also discloses ordering and pagination style, though it does not discuss rate limits or response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and scope, and most sentences add useful decision guidance. The comparison between history feeds is slightly repetitive, and the type examples are not exhaustive relative to the enum, but there is little wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, annotations, and 80% schema coverage, the description supplies the remaining context an agent needs: current-user scope, ordering, pagination style, and sibling-tool routing. No critical invocation detail 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 80%, and the schema already documents page, limit, token_address, and the transaction_type enum. The description reinforces the purpose of transaction_type filtering and gives example types, but it does not add syntax or guidance for token_address, page, or limit beyond what the schema provides.

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 resource (raw wallet transaction list), ordering (newest first), pagination style (page-numbered), and scope (current user only). It explicitly distinguishes this tool from `get_my_activity`, so an agent can identify it 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?

It gives explicit guidance for choosing between the two history feeds: prefer `get_my_activity` for the merged timeline, and use `get_my_transactions` when a specific transaction type is needed. It also names the filter field to use for that purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, non-destructive and open-world semantics, and the description adds real value on top: data is scoped to the current user via API key and there is no way to query another user's wallet. It does not discuss caching, freshness, or why idempotentHint is false, but the added scoping and wallet-class caveats are substantive.

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-loads the core definition and the deposit instruction, with the wallet-class warning emphasized. Slightly repetitive (the 'agentic wallets only' point is made twice) and the heavy caps/emoji styling adds length, 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?

An output schema exists, so return values need not be described; combined with zero parameters and read-only annotations, the remaining gaps an agent could face — scope, wallet class, which chain to deposit to — are all covered. Nothing needed 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The text correctly frames the implicit 'parameter' — whose wallets are returned — as fixed to the API key.

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 ('the user's AGENTIC wallets, with their addresses') and immediately narrows scope so the agent can distinguish it from the many other get_my_* tools. The explicit contrast with regular app wallets removes the most likely confusion at selection time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives actionable routing ('AI Trading is Solana only for now: tell the user to deposit to the Solana one') and warns that this is the source of truth for all other get_my_* data. It does not name a specific sibling to prefer for a different task (e.g. get_my_balances for balances), so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds value beyond them by disclosing the return granularity (names and ids only), the identity resolution mechanism (resolved from the API key), and the hard boundary that no other user's wallet can be queried. The statement that adding/removing tokens is unavailable is consistent with, not a repeat of, the read-only hint.

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 fact and the hand-off, and every sentence is short. The final two sentences ("resolved from their API key" and "no way to ask about someone else's wallet") restate the same user-scoping guarantee, which is mild redundancy rather than wasted space.

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?

An output schema exists, so return fields needn't be enumerated; the description still usefully signals the result is names and ids only. For a single-param, read-only list tool, an agent has everything needed: what it returns, what it cannot do, which tool continues the workflow, and whose data it is.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter with 0% schema description coverage, so the description must carry the load. It only says "on one network" without naming solana, while the schema pins network via const with a default — making the parameter effectively choice-free. The gap is small given the const, but the description adds no format or constraint detail beyond what the schema already enforces.

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 opening sentence gives a specific verb scope and resource ("The user's watchlists on one network — names and ids only"), plus the return shape. It actively disambiguates from siblings by naming get_my_watchlist_tokens and get_my_balances, and clarifies that a watchlist is followed tokens, not holdings — a distinction that matters among ~70 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?

Explicit entry-point guidance ("Start here for 'what's on my watchlist'...") plus an explicit hand-off path ("Pass an id to get_my_watchlist_tokens to read a list's contents"). It also states what the tool cannot do (add/remove tokens, query other wallets) and which sibling covers balances instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only/idempotent/non-destructive, and the description adds what annotations cannot: the 404 behavior for a non-owned watchlist id, that data is scoped to the API-key owner, and the safety_tier semantics (green/grey/red, with an explicit warning that grey is NOT a red flag and that agent buys are refused on red).

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 purpose, batching benefit, and the alternative, with the safety_tier guidance placed where it matters. It is somewhat dense: enumerating every returned field is partly redundant given an output schema exists, though the semantic notes (gray = not scored, red = Moby blocks buys) earn their space.

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 an output schema and rich annotations, the description closes every practical gap: default-list behavior, auth scoping, error behavior, and how to interpret returned tiers. Nothing an agent needs to call it correctly or to triage results 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?

watchlist_id is covered in both schema and description, with the description adding the default-list rule and the 404 failure mode. The network parameter is undocumented in prose, but it is a const ('solana'), so it needs little explanation; this small gap keeps it below 5.

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 the specific resource (tokens on one of the user's watchlists) and the batching behavior (market data in ONE call, replacing a per-token get_token_overview). It explicitly distinguishes itself from both get_token_overview and get_my_watchlists, so an agent can pick it 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?

Gives explicit conditional usage: omit watchlist_id for the default list on this network, otherwise pass an id from get_my_watchlists. It also points to get_token_overview for the full picture of one token, and rules out asking about another wallet entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only and open-world safety profile, but the description adds important behavior beyond them: the false-empty-list pitfall for invalid filters and the fact that this is public market data, not the user's wallet or holdings. It also routes agents away from user-specific tools by naming the `get_my_` prefix convention.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tightly structured and front-loaded: it starts with what the tool returns, then gives the call-order instruction and failure mode, then clarifies the data scope. Every sentence adds useful selection or invocation context.

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?

An output schema exists, so the description needn't explain return values. It covers purpose, call ordering, the false-empty pitfall, and public-vs-user scope; only the single `network` parameter remains under-explicated, which is a minor gap given its schema const and default.

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 only parameter, `network`, is barely addressed by the vague phrase 'for one network.' The description does not name `solana`, say it is the only supported network, or explain whether the parameter affects the returned filter values, so it fails to compensate for the missing schema documentation.

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 resource: the valid filter values for `get_market_movers`' `event_types`, `period`, and `market_cap_group` arguments. It distinguishes this tool from `get_market_movers` itself and from user-data `get_my_` tools, so an agent can identify its role 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?

It explicitly instructs the agent to call this BEFORE filtering `get_market_movers` and explains why: an invented filter string returns an empty list that can be misread as 'no events found.' That is a clear when-to-use rule with a concrete failure mode.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only status and open-world behavior, so the bar is lower. The description adds useful behavioral context by stating that this is public market-wide data rather than user-specific data, and it notes that `home_tabs` supplies valid `group_id` values. It does not contradict the annotations.

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 and routing instruction are front-loaded, which is good. However, the description is long for a simple list tool and repeats information, such as the `home_*` group IDs and leaderboard mappings, which could be tightened.

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 has no required parameters, an output schema, and annotations, so the description is largely complete for invocation. It explains how `group_id` is used and what `home_tabs` provides, though it could briefly clarify the `network` parameter to close the last 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?

There is only one parameter, `network`, which is constrained to the constant `solana` with a default. The description does not explicitly explain the parameter, though it does mention Solana-specific group IDs. With a single const parameter, this is adequate but adds little 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: 'List the token groups/categories Moby tracks (themes, sectors, narratives).' It also distinguishes this discovery tool from related leaderboard tools by naming them explicitly, so an agent can tell exactly what this tool 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?

It explicitly says to use this tool to discover a valid `group_id`, then pass it to `get_group_leaderboard`, and it maps the other leaderboard tools to their intended contexts. It also clarifies scope: 'This is public market data about the whole market — it is NOT about the user's own wallet or holdings,' with a pointer to `get_my_` tools for user data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only/open-world/non-destructive behavior, but the description adds substantial operational context: capped results, pagination context cost, whale-block field meanings, null semantics, safety_tier meanings, and the red-tier buy restriction. It also clarifies that this is public market data, not the user's wallet data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loads the purpose and usage guidance before moving through alternatives, pagination behavior, whale fields, and safety tiers. Given the crowded sibling set and non-obvious row semantics, the dense sentences earn their place without decorative fluff.

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?

An output schema exists, so the description need not fully document return values, yet it still covers selection context, pagination, whale output interpretation, asset_class, and safety_tier behavior. This gives an agent enough context to invoke and use the tool correctly.

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 75% schema coverage, the schema documents page, limit, and whale_windows, and the description adds meaningful usage guidance: page 1 is the default answer, raise limit/page only when necessary, and whale_windows adds a per-row whale block with defined buyer/seller counts and net flow. The network parameter is const solana, so the description's lack of elaboration there is acceptable.

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 explicitly identifies the resource (Moby token leaderboard), the ranking basis (composite 24h score), and the whole-market public-data scope. It also distinguishes this board from sibling leaderboards and get_my_* tools, so an agent can select it without opening another 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?

It states the primary use case directly: start here when the user asks what is moving, trending, or what they should look at, and has not named a specific token. It also names alternatives and their conditions, including Degen, Majors, Stocks, Pulse, and get_my_* tools for user-specific data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, openWorld, non-idempotent), and the description adds substantial behavior beyond them: ~2-minute refresh cadence with `data_as_of`, the `min_trade_usd` exclusion, one-swap-counts-once accounting, overlapping wallet-type membership (a wallet on two lists counts in both), and `smart_money` being null when unknown.

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 claim and the differentiator, and the sentences are dense but purposeful. The long enumeration of every returned slice and field partly restates what the output schema already supplies, which costs some length without adding equivalent value.

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 an output schema exists, the description need not document return shapes, yet it still defines the non-obvious ones (dump_sells = sold half or more of position, fresh_launch thresholds, net_flow_usd). Combined with cache freshness and aggregation rules, an agent has everything needed to call and interpret it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is effectively one parameter (`network`, a const with default 'solana'), so there is little to explain and the 4 baseline applies. The description instead clarifies a server-side filter (`min_trade_usd`) that never appears in the schema, which is genuinely additive even though it is not a parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: whole-market whale/KOL/smart-money buy/sell/dump aggregates across three windows, returned in one call. It explicitly separates itself from the token-level siblings ('before reading a single token') and from the feed-paging tool `get_whalewatch_feed_window`, so an agent can pick it without opening a 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?

Gives the decision rule ('tell "whales are dumping everything" from "this one coin is weak"') and names the alternative it replaces ('instead of paging `get_whalewatch_feed_window`'). It also closes the common mis-route by stating this is NOT the user's wallet data and that `get_my_*` tools cover that.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds real context beyond that: the prompt text is the app-copied canonical version, `ask_before_every_trade` only adds a line on cards where `ask_line_supported` is true, and `app_links` are deep links for the user's phone. It omits behavior on an invalid/unknown `strategy_id`, but otherwise the downstream side-effects (a human-facing instructions session, a separate save call) are clearly disclosed.

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 what is returned, then ordered preconditions and follow-up actions; nearly every clause carries operational information. It is dense with backticked identifiers and could be trimmed slightly, but nothing is redundant.

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 an output schema present and annotations covering safety, the description need not explain return values, and it supplies the full call-and-save workflow plus the capability-gated flag behavior. Only failure handling for a bad `strategy_id` is unaddressed.

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 adds meaning the schema lacks: `strategy_id` is bound to the `save_active_strategy` call, and `ask_before_every_trade` is qualified by the `ask_line_supported` capability gate, which the schema's plain 'True adds the line' does not mention.

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 the tool returns one starter strategy plus its ready-to-run `prompt` text ('the same text the app copies'), which distinguishes it from `list_strategies` (browsing cards) and `save_active_strategy` (persisting a choice). The retrieval verb itself is only implied by 'One starter strategy with...', but the resource and payload are 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?

It sequences the workflow explicitly: run the prompt as standing instructions, confirm editable `chips` with the user first, check `get_my_active_strategies` to avoid double-running, then record via `save_active_strategy` with `strategy_id` after user approval. Alternatives and their selection conditions are named rather than left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/destructive=false, but the description adds non-obvious traits: nothing is submitted on-chain, quotes go stale in seconds, and a `quote_id` is returned for downstream consumption by execute_swap. The staleness window is a behavioral constraint no structured field conveys.

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 purpose and the quote fields, then workflow rules. Nearly every sentence is load-bearing, but the pacing is dense and mixes three topics (return fields, safety disclaimer, cross-tool workflow) in one block.

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?

Even though an output schema exists, the description flags the two most easily misread return fields (smallest unit vs UI units) and names the lifecycle handoff via quote_id. For a read-only pricing call whose safety profile is annotation-covered, nothing an agent needs to invoke 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 75%, and the description reinforces the critical unit distinction ('`output_amount` is in the token's smallest unit' vs `output_amount_ui`) and the spend/receive direction of input vs output token. It does not explain the `network` parameter, though its const value makes that self-evident.

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?

Opens with a specific verb+resource ('Price a token swap') and immediately enumerates what the price consists of (output amount, price impact, fees, slippage, minimum output). It explicitly separates itself from execute_swap ('This only prices the trade'), so an agent can distinguish it from the sibling that actually submits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit sequencing ('Always call this before `execute_swap`'), a re-quote rule ('if they hesitate, quote again rather than executing an old one'), and a routing rule for the ambiguous case ('If `execute_swap` returns `pending` or `fill_pending`, only `get_swap_status` can tell you it completed'). Both the when and the when-not are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it read-only and non-destructive, but the description adds substantial non-structured behavior: it "moves nothing," is safe to repeat, warns that the status can be transient (pending) and must not be assumed final, and enumerates every failure class and what each implies for the user. The "safe to call again" wording is compatible with idempotentHint=false because the returned status legitimately changes over time — no 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?

Front-loaded with what the tool does and the critical call trigger, then structured status-by-status. It is long and dense, and a few clauses (filled amounts, resting orders) border on explaining the output schema, but nearly every sentence changes how an agent should act on the result.

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?

An output schema exists, yet the description explains the decision-relevant semantics of status values and error classes that a schema alone would not convey (e.g., not_executed means nothing was traded and can still execute until expiry). For a two-param post-trade status check, nothing an agent needs 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 both params are already documented, so the baseline is 3; the description adds real value by stating the exactly-one constraint and by noting that request_id also accepts the Reference ID printed in a failure message — a non-obvious acceptance rule absent from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Check where a quote or swap stands") plus the two mutually exclusive lookup keys, and implicitly separates itself from get_swap_quote (pre-trade) and execute_swap (submission) by being the post-execution read. An agent can tell exactly what this returns and when it applies.

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 trigger ("CALL THIS WHENEVER execute_swap OR quick_buy RETURNED A next_step"), an explicit prohibition with rationale ("never re-execute the quote to find out (that would trade twice)"), and follow-up guidance for the pending case ("if it is still pending, say so and check again shortly"). This is the strongest possible when/when-not coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: prices are USD, data is public market-wide rather than user-scoped, and period has a default. It does not address the idempotentHint=false signal or error/rate-limit behavior, so it stops just short of fully exploiting the low annotation bar.

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?

Well front-loaded: the core behavior leads, the sibling routing follows, and the scope caveat closes. The get_my_* disambiguation is two sentences where one would do, which is the only padding in an otherwise dense definition.

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?

An output schema exists, so return values need no explanation, and the chart-vs-candles routing covers the main selection risk. The remaining gap is input-side: acceptable period strings and the token address format are not stated anywhere given 0% schema coverage.

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 `period` semantically (selects the window, defaults to 1d) and clarifies units for the returned prices, but never enumerates valid period values, and says nothing about `token_address` format or that `network` is fixed to solana. Coverage of 3 undocumented params is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and shape: 'Price history for one token as a series of points, for describing or plotting a trend.' It explicitly names the sibling it could be confused with (get_token_ohlcv) and characterizes the difference (line vs. OHLCV candles), so an agent can discriminate without opening either 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?

Gives an explicit decision rule – 'Prefer the chart unless you need per-candle numbers' – with the condition that selects the alternative. It also pre-empts a second, larger confusion class by contrasting with the get_my_* family. When-to-use and when-not-to-use are both stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context that this is public on-chain market data unrelated to the user's wallet, but it says nothing about result limits, recency, or why idempotentHint is false on a read 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?

The exclusion is front-loaded and the warning marker draws attention to the key disambiguation. However, the 'not your own DCA' point is restated three separate ways, which is more repetition than the disambiguation requires.

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?

An output schema exists, so return values need no explanation, and the read-only annotations cover safety. The remaining gap is parameter-level guidance for sorting and result sizing, which an agent would need to call this effectively.

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 only 20% — only `size` is documented. The description never explains `order_by` (usd_per_min/created/amount/percent_filled), `order_direction`, or `network`, so four of five parameters carry no semantic guidance anywhere. It only implies that `token_address` is the subject token, which is already evident from the name.

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 with scope: public on-chain DCA orders open against a token, described as what 'who ELSE in the market' is doing. It explicitly contrasts with the sibling get_my_dca_schedules and even names the `get_my_` naming convention, so an agent can disambiguate without opening a 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-to-use (market-wide DCA activity for a token) and when-not-to-use (the user's own DCAs), naming the alternative tool by name. The `get_my_` prefix heuristic generalizes the rule to the rest of the toolset.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, non-destructive, open-world), so the description's added value is the disclosure that 'results are capped' and that a large result costs context for later steps — real behavioral context an agent cannot get from the annotations. It stops short of stating what the cap actually is or how ranking ties are handled, which keeps 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?

Front-loaded with the core purpose and sibling disambiguation before the operational caveats, and each sentence carries a distinct payload (scope, alternative, cost warning, user-data exclusion). The closing `get_my_` explanation is slightly redundant given the exhaustive sibling list but earns its place as a routing guard against a common confusion.

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?

An output schema exists, so return-shape explanation is unnecessary. For a four-parameter read-only list tool, the description covers purpose, sibling routing, pagination discipline, result capping, and the user-vs-market data boundary — nothing an agent needs in order 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 50%: `page` and `limit` are documented in the schema, while `token_address` and the const `network` are not (the latter being self-evident). The description nonetheless adds decision-level meaning to both pagination params — when it is legitimate to raise `limit` or step `page` — which goes beyond the schema's mechanical '1-based page number' and 'keep it small.'

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 ('ALL top holders of this token') and immediately scopes it with 'not just the wallets Moby tracks,' which directly distinguishes it from the tracked subset. It then names the sibling `get_token_key_holders` and frames the relationship (subset vs. full concentration picture), so an agent can route between them without opening either 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?

Gives explicit when-to-use guidance for pagination ('raise `limit` or step `page` only if the answer is genuinely not in the first page'), names the alternative tool and the condition that selects it, and adds a clear when-not: this is not about the user's own wallet, unlike `get_my_*` tools. Both the positive and negative routing conditions are stated rather than implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare this as a read-only, non-destructive, open-world operation. The description adds valuable behavioral context by clarifying that the data is public market data about the whole market, not user-specific information, which helps prevent misuse. It does not discuss idempotency or the non-idempotent annotation, leaving a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then efficiently covers sibling alternatives and the public-data scope. Every sentence adds useful routing or scope information without unnecessary padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, the description need not explain return values, and the annotations already establish safety. It fully addresses tool selection and data scope, but it leaves the input parameters underspecified given the 0% schema description coverage.

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 should compensate for undocumented parameters. It only implies that exactly one token is targeted, but does not explain the `token_address` format, required status, or that `network` is constrained to `solana`. The schema itself contains bare fields with no descriptive 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?

The description states a specific verb and resource: an aggregate holder-distribution summary for one token, in bucketed concentration form. It explicitly distinguishes itself from similar token-holder siblings and clarifies that it covers public market data rather than the user's own wallet.

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 names the alternatives explicitly: `get_token_holders` for itemised top holders and `get_token_key_holders` for tracked whales/KOLs. It also provides a clear negative rule: tools prefixed with `get_my_` return the user's own data, so this tool should not be used for personal holdings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only safety, but the description adds substantial behavioral context: concentration as a risk signal, true totals for counts, `min_position_usd` filtering, null/unknown semantics, tracked-trade limitations, result caps, and context-cost warnings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and warnings, but it is one very dense paragraph. It repeats the non-user-wallet point and the public-market disclaimer, which makes it less concise than it could be despite the useful detail.

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 tool's complexity, existing output schema, and annotations, the description is complete enough for an agent to interpret results and avoid common mistakes. It covers data scope, caveats, filtering behavior, and alternative tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is decent at 71%, and the description adds meaningful semantics for `min_position_usd`, `tag`, `page`, and `limit`, including defaults, ignored cases, and echoed values. It does not add much about `sort`, but the schema enum is adequate.

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?

Clearly states it returns the most significant holders of a token and concentration information. It distinguishes itself from the user's own position via `get_my_position`, but does not explicitly differentiate from sibling holder tools such as `get_token_holders` or `get_token_whale_holders`.

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?

Explicitly directs agents to `get_my_position` for the user's own holdings and to `get_whale_wallet_track_record` for wallet quality, and it gives practical guidance about pagination and context cost. It stops short of explaining when to choose this tool over other holder-focused siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/openWorld/idempotent annotations: discloses that there is no $ floor unlike the app, that data begins when Moby started tracking the token, that duplicate whale+KOL identities are collapsed to one row, that pagination is cursor-based with no gaps or duplicates, and that SELL rows carry held_seconds/quick_flip. These are exactly the non-obvious traits an agent needs before trusting the rows.

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 what the feed is and its main exclusion, and nearly every sentence contributes a distinct fact. It is dense and long, with a couple of sentences (win_rate/realized_pnl, days_since_prev_trade) that could be tightened, but little 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?

An output schema exists, yet the description still explains the interpretation-critical return fields (identities, is_whale/is_kol, win_rate, held_seconds, quick_flip) and the sort/ordering rule. Nothing an agent needs to call this correctly or read the response 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 60% and the description compensates for the key gap by explaining cursor semantics ('Pass next_cursor back as cursor for the next page until it is null'), which the schema only partly states. It adds no meaning for page, limit or the fixed-value network parameter, so it does not fully close the remaining 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?

States a specific verb and resource — a trade-by-trade feed of tracked wallets that traded one token — and immediately scopes it ('only wallets Moby tracks appear'). It also distinguishes itself from the get_my_* family and from a whole-market feed in the same breath, so an agent can place it among ~60 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?

Explicitly says when NOT to use it: it is not the whole market (only tracked wallets) and not user data, with the naming rule 'get_my_ tools return the user's own data' as a routing heuristic. It does not, however, name the closest token-level siblings (e.g. get_token_smart_money, get_whalewatch_feed) and say which to pick, which keeps it 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already cover safety, but the description adds critical behavioral details beyond them: newest-first series ordering, closed-candle default, the effect of including the in-progress candle, unsupported interval rejection, and echoed response fields. These are exactly the traits likely to cause silent calculation errors if omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well structured, with the purpose first, interval behavior next, and a clearly marked warning about return-calculation pitfalls. Some interval and timestamp details repeat schema text, but the length is mostly justified by the complexity and risk of silent misuse.

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?

An output schema exists, so the description does not need to enumerate return fields, but it still adds the output orientation an agent needs for correct calculation: descending time order, closed candles by default, and USD denomination. It also clarifies the tool's public-market scope relative to wallet-scoped 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?

Schema description coverage is high at 80%, and much of the description's parameter guidance is already present in the schema, especially for `interval`, `timeframe`, `aggregate`, `time_from`, `time_to`, and `before_timestamp`. The description reinforces precedence and seconds/milliseconds handling, but adds limited meaning beyond the structured parameter descriptions.

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: raw OHLCV candles for one token, with open/high/low/close/volume per interval. It explicitly distinguishes this tool from its closest sibling, `get_token_chart`, and clarifies that it is public market data rather than `get_my_` user data.

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 explicit selection guidance between `get_token_chart` and `get_token_ohlcv`, including when to prefer the chart and when raw candles are needed. It also specifies interval precedence, defaults, and when to use `include_in_progress_candle`, leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, non-destructive, open-world), but the description goes far beyond them: how safety_tier colours should be interpreted (grey is NOT a red flag), that Moby refuses agent buys on red, that smart_money_read_v2 deliberately mixes a 1-hour tier with a 7-day base and the two can disagree, and that data_notes enumerates known gaps requiring web verification. That is exactly the extra behavioural context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded correctly with the purpose, but the body is a single unstructured wall of several hundred words covering output-field interpretation, alias names, tier colour semantics and window mixing. Much of this overlaps with the existing output schema, and the density makes it hard to scan for the one thing needed at call time.

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 an output schema exists and a rich annotation set, the definition is more than complete: it explains how to interpret ATH bases, concentration capping, exited vs left-out wallet stats, and what to do when Moby lacks a data point. Nothing needed to call or interpret the result 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 0%, so the description carries the burden. It does add meaning for token_address (source it from search_tokens), but the second parameter, network, is never mentioned even though it is a const/default field the agent may need to reason about. Partial compensation only.

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 opening sentence names a specific resource (one token) and enumerates exactly what it returns (price, market cap, liquidity, volume, holders, safety, metadata), and explicitly declares itself 'the default tool for tell me about <token>'. This clearly separates it from siblings like get_token_price, get_token_holders and get_token_chart.

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 states the default-use case, tells the agent where to obtain the required argument ('Get token_address from search_tokens'), and gives an explicit exclusion: market data only, not the user's own wallet — use get_my_* tools for that. Both a positive routing rule and a negative one are present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.