Solana MCP by Vybe

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the risk profile is structured. The description adds genuinely new behavioral detail: it clarifies the tool only builds an unsigned transaction and never signs or broadcasts, and that it declines private keys — important for an agent reasoning about the security boundary. Return-format coverage is handled by 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 endpoint and the unsigned-transaction contract, and the sentences are mostly information-bearing. The second sentence about the Solana API endpoint for closing empty token accounts overlaps somewhat with the first, but nothing is seriously wasteful.

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 destructive build-transaction tool with rich annotations and an output schema, the description covers the crucial gaps: it states what is mutated (token accounts), what is returned (unsigned transaction), and what the tool refuses to do (sign/submit, accept keys). An agent has enough to invoke it 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 description coverage is 100%, with gasless, partner, rentFee, ownerAddress, and accountAddresses all documented in-schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies — the schema, not the prose, carries parameter semantics.

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

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

The description names the specific endpoint (POST /v4/wallets/util/close-token-accounts) and states the concrete outcome: an unsigned transaction to close Token-2022 and SPL token accounts and recover locked SOL. The action is unambiguous, though the opening 'Close Token Accounts' merely restates the title, and it doesn't explicitly contrast with build-swap, the closest sibling.

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

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

It gives context (closing empty token accounts to recover locked SOL) and a hard constraint (does not sign, submit, broadcast, or accept a private key), which implies a build-then-sign-user-side workflow. But it never tells the agent when to prefer this over siblings like get-wallet-empty-accounts (which surfaces accounts to close) or build-swap, leaving the selection implicit.

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=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds important behavioral context: it only calls POST /v4/trading/swap, returns an unsigned transaction, and never signs, submits, broadcasts, or accepts a private key. It does not explain why destructiveHint is true or the risk implications of the unsigned transaction, but with annotations present this is solid added context.

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 endpoint and unsigned-transaction behavior, which is useful. It is somewhat repetitive, though: 'Build Swap,' 'building token swaps,' and 'Build and return unsigned transactions' restate the same core idea, so not every sentence fully earns its place.

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

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

For a complex swap-building tool with a nested body schema and an output schema, the description covers the essential context: endpoint, Solana/DEX scope, unsigned non-custodial behavior, and no private-key handling. It would be stronger if it explicitly routed agents to or away from get-swap-quote and clarified the destructiveHint implication, but it is nearly complete.

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

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

The schema has 100% description coverage, including rich nested details for the body and its many optional swap parameters. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score 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?

The description states a specific verb and resource: building unsigned token swap transactions, calling POST /v4/trading/swap, for direct swaps on DEXs such as Pump.fun and Raydium. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like get-swap-quote or other build-* tools.

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

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

The description implies usage for direct DEX swaps and clarifies that the result is unsigned for the user to sign. However, it does not explicitly say when to use this tool versus get-swap-quote or the other build-* siblings, nor does it provide exclusions or prerequisites.

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?

Adds real context beyond the annotations: it explicitly says it does not sign, submit, or broadcast and does not accept a private key, which matters a lot given destructiveHint=true and readOnlyHint=false on a 'withdraw' tool. It also pins the single endpoint. It stops short of describing auth requirements, rate limits, or what the unsigned transaction contains — but with full annotations the bar is lower.

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 action and the endpoint constraint, followed by the non-signing caveat and then context. Slight redundancy: 'Withdraw MEV' and 'Solana API endpoint for withdrawing MEV rewards on Solana' repeat the same fact and the 'on Solana' phrase is duplicated, but overall it is tight and every sentence mostly earns its place.

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-value explanation is unnecessary, and the rich annotations cover the safety profile. The description fills the remaining critical gap (unsigned, no private key, single endpoint) for a one-parameter nested-body tool. It could still mention whether the built transaction must be signed within a validity window or what the caller must do next, but it is reasonably complete.

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

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

Schema description coverage is 100% and the nested body fields (mevFee, gasless, vybeSOL, stakeAccountAddresses, simulate, partner, router) are all documented in the schema, including the auto-fetch behavior when stakeAccountAddresses is omitted. The description adds no parameter-level meaning of its own, 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 specific verb and resource ('Withdraw MEV', 'claim accumulated MEV rewards from staking positions like Jito') and names the exact endpoint POST /v4/wallets/util/withdraw-mev. It also clarifies the output artifact (an unsigned transaction), so an agent knows what it gets. It does not explicitly contrast itself with the sibling builders (build-swap, build-close-token-accounts), which keeps it at 4 rather than 5.

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

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

The description implies usage ('Build a transaction to claim accumulated MEV rewards') and gives one hard constraint ('Calls only POST /v4/wallets/util/withdraw-mev'), but never says when to prefer this over the other build-* tools or what prerequisites exist (e.g., must have staking positions with MEV rewards). Usage is inferable but not spelled out.

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, idempotentHint, destructiveHint=false, and openWorldHint, so the read-only sentence is largely redundant. However, the description adds useful behavioral context beyond the annotations: the specific endpoint, the 10-wallet input ceiling, the 1000-account result ceiling, and what is returned (reclaimable tokens).

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 short and mostly front-loaded with the endpoint and scope. It wastes a sentence restating the title and another reiterating the non-destructive behavior already covered by annotations, but it remains easy to scan.

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 rich annotations, 100% schema coverage, and an output schema, the description supplies the key missing context an agent needs: the exact endpoint, batch scope, input and output limits, and return meaning. Authentication/pagination behavior is not described, but pagination and limit are handled by the schema.

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 page, limit, sortByAsc, sortByDesc, and ownerAddresses are already documented in the schema. The description only summarizes the body as listing wallets and reinforces the 10-wallet/1000-account limits; it does not add syntax or format details beyond the schema.

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

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

The description names a specific resource and action: fetching Token-2022 and SPL dust accounts across multiple wallets. The 'batch' scope is clear and implicitly distinguishes it from the single-wallet sibling get-wallet-dust-accounts, though it does not explicitly name that or the related get-empty-accounts-batch alternative.

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

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

Usage is implied by 'across multiple wallets' and the 10-wallet cap, but the description never states when an agent should choose this over get-wallet-dust-accounts or get-empty-accounts-batch. There are no explicit exclusions or prerequisites.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the concrete endpoint path (POST /v4/wallets/batch/empty-accounts) and a pagination/size expectation, but 'This tool does not create, modify, or delete data' merely restates destructiveHint=false and adds no new information.

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 first sentence duplicates the tool title verbatim, and the no-mutation sentence duplicates the annotations, so several sentences do not earn their place. The remaining content (endpoint, 10-wallet cap, SPL/Token-2022 scope) is useful but not front-loaded — the endpoint path precedes the actual purpose statement.

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 covering safety traits, a 100%-covered schema, and an output schema, the description only needs to convey scope and batch semantics, which it does. The main residual gap is not routing the agent to the single-wallet or dust-account alternatives, but nothing essential 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?

Schema description coverage is 100% and the nested body fields (ownerAddresses 1-10, page, limit, sortByAsc/sortByDesc) are fully documented in the schema. The description only restates that the body lists wallets and that up to 10 wallets are supported, so it adds nothing beyond structured data — baseline 3 applies.

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

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

The description names a specific verb (fetch) and resource (Token-2022 and SPL empty token accounts) with an explicit batch/multi-wallet scope and a 10-wallet cap. It distinguishes itself from the singular sibling only implicitly through 'batch'/'multiple wallets' — it never names get-wallet-empty-accounts or get-dust-accounts-batch.

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

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

Usage is only implied: an agent can infer this is for multi-wallet empty-account reads, but there is no explicit guidance on when to choose it over get-wallet-empty-accounts (single wallet) or get-dust-accounts-batch (dust accounts), which are the obvious alternatives in the sibling list.

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 description adds useful behavioral context beyond the readOnly/idempotent/openWorld annotations: it calls only the GET /v4/markets/{marketAddress} endpoint, returns that response directly, and covers multiple DEX sources. It does not mention auth or rate limits, but the annotations already establish 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 endpoint and scope are front-loaded, but the first sentence repeats the title 'Market Details' with little added value, and the second sentence redundantly says 'Solana API endpoint ... on Solana.' The content is short but not maximally efficient.

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, 100% schema coverage, single required parameter, and existing output schema, the description gives enough context to invoke the tool correctly. It could be more complete by explicitly contrasting this tool with list-markets or get-market-candles.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that the address may identify either a market or a pool across Pump.fun, Raydium, and other supported venues, which goes beyond the schema's generic 'Solana public key identifier' wording.

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 (a specific market on Solana) and ties it to the exact endpoint GET /v4/markets/{marketAddress}. It distinguishes 'specific market' from a listing operation, but does not explicitly name the sibling list-markets tool.

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

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

Usage is implied by 'fetching details about a specific market on Solana' and by mentioning market/pool address filtering across Pump.fun and Raydium. However, there is no explicit guidance on when to use this instead of list-markets or get-market-candles.

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, idempotentHint=true, non-destructive, so the safety profile is covered. The description usefully notes it is a thin passthrough of a single GET endpoint and that data comes from vetted DEX pools, but says nothing about pagination behavior, default fill behavior, or timestamp/response shape that an agent might trip over.

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 endpoint, but the first sentence restates the title and the third sentence ('Returns clean price data from vetted DEX pools and markets') is marketing filler that does not help invocation. Tightening would leave one useful sentence about the underlying endpoint plus one about data source.

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 and full parameter coverage, the description need only establish scope and origin, which it does. The remaining gap is sibling routing against the three other candle-related tools, which is the one thing structured fields cannot supply.

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%, including the marketAddress path parameter and the detailed fillEmptyCandles semantics, so the schema carries the parameter burden. The description adds no parameter syntax, units, or default information beyond what is already structured.

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: fetches OHLCV candlestick data for a specific Solana market/pool via a named endpoint. The market/pool scoping implicitly distinguishes it from get-token-candles and get-pyth-price-candles, but it never names those siblings explicitly, so the differentiation is left to inference.

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

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

No guidance on when to use this over get-token-candles or get-pyth-price-candles, which return similar candle data for different asset scopes. It also lacks any prerequisite or exclusion (e.g. which markets are supported, whether price data is needed instead of token candles). Usage is only implied by the resource name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: it pins the exact endpoint called and names the payload contents (price, confidence interval, EMAP), which tells the agent what kind of live read this is.

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 opening "Pyth Current Price." merely echoes the title, and the second and third sentences repeat the same claim (current Pyth price for any feed on Solana) in two forms. The useful content is front-loaded, but a third of the text 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?

For a single-parameter read tool with rich annotations and a present output schema, the description needn't explain return values, and it does state scope and data returned. The remaining gap is operational: nothing about invalid/missing price feed behavior or how to discover a valid feed address.

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 fully documented in the schema as a Solana public key path parameter. The description only restates the route containing the parameter, adding no format, validation, or sourcing detail beyond 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 specific verb and resource: fetching the current Pyth oracle price for a given price feed on Solana, with the exact upstream route. The word "current"/"real-time" implicitly separates it from siblings get-pyth-price-history and get-pyth-price-candles, but no sibling is named explicitly.

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

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

Usage is only implied by the phrase "current Pyth oracle price for any price feed." There is no explicit statement of when to choose this over get-pyth-price-history, get-pyth-price-candles, or get-pyth-product, and no guidance that list-pyth-price-feeds is how you obtain a priceFeedAddress.

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 the operation as read-only, idempotent, open-world, and non-destructive. The description adds that it calls only a single GET endpoint and returns that response unchanged, which is useful scoping context, but it does not disclose pagination behavior, rate limits, error handling, or default time-range assumptions beyond what the schema and annotations provide.

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 brief and mostly front-loaded, moving quickly to the endpoint and the OHLC data purpose. The opening 'Pyth Price Candles.' restates the title and is somewhat redundant, but the remaining sentences are efficient and 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?

Given the rich schema coverage, full annotations, and an output schema, the description provides enough context for an agent to understand what the tool does and how to invoke it with a price feed address. It does not discuss pagination or time-range defaults, but those are covered by the schema.

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

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

Schema description coverage is 100%, so the schema already documents all parameters, including timeStart, timeEnd, resolution, page, limit, and eliminateCloseToOpenGaps. The description only reiterates that priceFeedAddress is a path parameter and does not add meaning beyond the schema, 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?

The description clearly states the specific verb and resource: fetching historical OHLC candle data from Pyth oracle price feeds for a given price feed account. It distinguishes this from general price or token tools by naming Pyth oracle feeds and OHLC data, though it does not explicitly contrast with siblings like get-pyth-price-history or get-market-candles.

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

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

The description implies appropriate usage by specifying 'historical OHLC data' and 'Pyth price feed account', but it does not explicitly state when to use this tool versus alternatives or when not to use it. The context is present but not directive.

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, idempotentHint, openWorldHint and non-destructive. The description adds that it hits exactly one endpoint and returns that response verbatim, and that results include confidence intervals, which is modest extra context. It says nothing about pagination behavior, rate limits, or what happens for unknown feed addresses.

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 resource name, but the body is padded: 'Solana API endpoint ... on Solana' repeats itself, and the endpoint-URL sentence adds little for an agent that already knows the tool name. Three sentences deliver roughly one sentence of unique 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 needn't be explained, and annotations cover safety. But with 6 parameters including a nested, vaguely-described resolution object and time-window parameters, the description gives no guidance on how to page, how to pick a resolution, or what the timeStart/timeEnd semantics are — leaving real gaps for a time-series 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 description coverage is 100%, so every parameter including the nested resolution object is already documented in structured form. The description only reiterates that priceFeedAddress is part of the path, adding no interpretation value. 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?

Names a specific verb+resource: fetching historical Pyth oracle price time series, with confidence intervals, for a given price feed. That is a clear purpose. However, it never distinguishes this from close siblings get-pyth-price, get-pyth-price-candles, or list-pyth-price-feeds, so an agent must guess which to pick.

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

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

No statement of when to use this versus get-pyth-price (spot) or get-pyth-price-candles (OHLC-style). The description lists no prerequisites, no exclusions, and no alternatives despite three obvious sibling candidates.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scoping information — that it performs only one GET and returns that response verbatim — but says nothing about behavior on an unknown/invalid product address or rate-limit constraints. An output schema exists, so return-shape detail is not required.

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 endpoint and return-content statements are front-loaded and earn their place, but the opening 'Pyth Product.' merely restates the tool name/title and is dead weight, and the third sentence overlaps the second's description of what is returned.

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 a fully described single parameter, complete annotations, and an output schema that carries the return shape, the description supplies enough for correct invocation. Only edge behavior (invalid or nonexistent product address) is unstated, which is a minor gap for a read-only lookup.

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

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

Schema description coverage is 100% and the single productAddress parameter is fully documented in the schema as a typed Solana public key and path parameter. The description only echoes that it is the path segment of the endpoint, adding no format, validation, or lookup guidance beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource: fetches a Pyth product by address from GET /v4/oracle/pyth/products/{productAddress}, returning product account details, asset type, and associated price feed accounts. This clearly separates it from get-pyth-price and list-pyth-price-feeds, which deal with prices/feeds rather than product metadata, though it never names those siblings explicitly.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The agent must infer from the resource name that this is the call to make when it has a product address; nothing tells it how to obtain a product address or when to prefer list-pyth-price-feeds or get-pyth-price 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 readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds value by saying it hits exactly one endpoint and returns expected output, price impact, slippage bounds and route plan — useful context beyond annotations, though it omits whether quotes expire or are cached.

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 sentences where the first two are largely redundant — 'Calls only GET /v4/trading/swap-quote and returns that response' and 'Solana API endpoint for fetching Solana swap quotes' restate each other. The informative content (returned fields) is present but not front-loaded.

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 quote endpoint with complete schema coverage and an output schema, the definition covers endpoint scope and returned data well enough to call correctly. The main gap is workflow context relative to build-swap, which the description leaves unstated.

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

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

Schema description coverage is 100%, so all five parameters (amount in UI units, slippage default 0.5, optional accountAddress, mint addresses) are already documented in the schema. The description adds no parameter-level detail beyond that, 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?

Clear specific verb+resource: fetches a swap quote from a named endpoint and enumerates what comes back (expected output, price impact, slippage bounds, route plan). It does not, however, distinguish itself from the sibling build-swap, which an agent might reasonably confuse with quoting vs. executing.

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

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

No statement of when to use this versus build-swap or how it fits a quote-then-build workflow, and no prerequisites (e.g., wallet required only for personalized routing). Usage is only loosely implied by the word 'quote'.

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, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context by specifying it calls only GET /v4/tokens/{mintAddress} and returns that response verbatim, signalling a single upstream call with no fan-out or extra processing.

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 resource and endpoint, with the field enumeration last. Minor waste in repeating the title verbatim ('Token Details.') at the start, but otherwise every sentence carries information.

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

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

With one fully described parameter, rich annotations, and an output schema handling return values, the description covers what an agent needs to invoke it correctly. The only shortfall is the lack of explicit sibling routing, which is modest for such a simple lookup 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 mintAddress parameter is already documented as a Solana public key and path parameter. The description's endpoint mention corroborates that mapping but adds no syntax, format, or validation detail beyond 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 specific verb+resource (fetch token details for a mint address) and enumerates the returned fields: price, volume, market cap, holder count, supply, social links. This distinguishes it adequately from narrower siblings like get-token-liquidity or get-token-candles, though it never names those alternatives explicitly.

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

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

The description implies a read-only lookup against a single endpoint and that the returned payload is the response body, which suggests when to reach for it. However, it gives no explicit when-to-use/when-not guidance against the many sibling token endpoints (liquidity, candles, top-holders), leaving the agent to infer that this is the aggregate overview 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so 'does not create, modify, or delete data' is largely redundant. The description does add genuine behavioral context — the exact endpoint and that results are raw, unaggregated snapshots rather than aggregates — but says nothing about billing, rate limits, auth, or pagination behavior with large wallet batches.

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 resource and endpoint, then a safety statement, then the data character — four short sentences with little waste. The final sentence leans slightly toward marketing framing ('for custom analytics') but still carries differentiating 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 rich annotations, a fully-documented nested input schema, and an output schema present, the description needn't explain return values. It covers what the tool reads and what kind of data comes back; only cross-sibling routing guidance 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%, with nested fields (days, limit, sortByAsc/Desc, ownerAddresses, vybeTokenFilter) all documented inline. The description only adds 'the request body lists wallets to read', which restates the schema; no supplementary meaning (e.g. the 10-wallet cap or default 14-day window) is contributed.

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: batch-read token account balance time series for multiple wallets, plus the exact endpoint (POST /v4/wallets/batch/token-accounts-balance-ts). The phrase 'raw balance snapshots ... unaggregated time-series data' implicitly separates it from get-token-balances-batch and get-token-balance-history-batch, but those siblings are never named, so the distinction requires inference.

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

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

Usage is only implied via 'for custom analytics and unaggregated time-series data'; there is no explicit statement of when to pick this over get-token-balances-batch or get-token-balance-history-batch, nor any prerequisite (e.g. wallet count limit, days range) in the prose.

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, idempotentHint, destructiveHint=false and openWorldHint, and the sentence 'This tool does not create, modify, or delete data' largely restates them. The description does add useful behavioral color about snapshot resolutions (daily/weekly/monthly) and aggregated USD values, but says nothing about rate limits, cost, partial failures, or what happens when wallets are invalid.

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 leads with a title restatement, then the endpoint, then a non-destructiveness line that duplicates annotations, then a feature summary sentence. The useful content (endpoint, batch semantics, snapshot resolutions) is present but diluted by redundant framing, and the sentence order meanders rather than front-loading the key distinction.

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 a full output schema and fully documented params, the core call is answerable. What's missing is the batch-vs-single decision against a very crowded sibling set and any note on limits/failure behavior for a 10-wallet batch — enough gaps that an agent could still pick the wrong sibling.

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 days, resolution, ownerAddresses (max 10) and vybeTokenFilter are already documented. The description only restates that the body lists wallets, adding no syntax, defaults, or interaction semantics beyond the schema — baseline 3 applies.

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

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

The description states a specific verb and resource (fetch multi-wallet token balance history) and pins the exact endpoint POST /v4/wallets/batch/token-balances-ts. 'Batch' and 'multi-wallet' implicitly separate it from the single-wallet sibling get-wallet-token-balance-history, but that sibling is never named, so differentiation is left to inference.

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

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

Usage is implied by 'lists wallets to read' and 'multi-wallet', suggesting this is the bulk variant, but there is no explicit statement of when to pick it over get-wallet-token-balance-history or get-token-balances-batch. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the sentence 'This tool does not create, modify, or delete data' largely repeats structured data. It does add some value by describing the returned data categories and the endpoint path, but says nothing about auth, rate limits, or the max-10-wallet constraint beyond what the schema documents.

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

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

The definition is short but front-loads a restatement of the title ('Token Balances (Batch)') and a redundant 'does not create, modify, or delete' clause that the annotations already cover. The final sentence is a dense run-on that mixes endpoint purpose with return-content detail. It is not bloated, but several sentences do not earn their place.

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 a fully documented nested schema, output schema present, and safety annotations, the description covers the essentials for calling the tool. The remaining gaps are routing (no explicit sibling differentiation) and operational constraints (auth, rate limits), which keep it at minimum-viable rather than complete.

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

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

Schema description coverage is 100% and every nested body property (ownerAddresses, limit, sortByAsc/Desc, filters) is documented in the schema. The description only restates that the body lists wallets, adding no filter, pagination, or sorting semantics beyond the schema. Baseline 3 is appropriate when the schema already does the work.

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: fetches multi-wallet token balances and names the exact endpoint (POST /v4/wallets/batch/token-balances), with scope details (SPL, Token-2022, USD values, staking, portfolio metrics). It distinguishes batch from single-wallet by describing 'multi-wallet' balance reads, though it never names the single-wallet sibling get-wallet-token-balances, so the differentiation is implicit rather than explicit.

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 word 'batch' and 'The request body lists wallets to read' imply when to use it — for multiple wallets at once — but the description gives no explicit 'use this when / use X instead' guidance. It does not point to the single-wallet get-wallet-token-balances sibling or to get-token-balance-history-batch, leaving the choice 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/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds only that it is a thin passthrough ('returns that response'), which mildly signals no transformation, but says nothing about pagination behavior across 9 params, default window, or rate/refresh characteristics.

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

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

Two very short sentences with no bloat, but the first sentence is pure title repetition that earns nothing, leaving only one substantive sentence. Concise without being 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?

With 9 parameters, an enum, an output schema and several near-identical candle siblings, the description should at minimum say what kind of candles these are and how they differ from market/Pyth candles. It does none of that, leaving the agent unable to choose confidently between candle 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 description coverage is 100% and the schema documents each parameter (resolution enum, countBack TradingView pattern, fillEmptyCandles semantics). The description adds no parameter meaning at all, so the baseline 3 applies since the schema carries the load.

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 just repeats the title ('Token Candles'). The second adds the concrete endpoint GET /v4/tokens/{mintAddress}/candles, so the resource (token OHLC candles by mint) is inferable, but it never states the verb/purpose in plain terms and does nothing to distinguish it from get-market-candles or get-pyth-price-candles.

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?

'Calls only GET ...candles' implies a tight scope (candle retrieval and nothing else), which is a faint hint at when to use it. But there is no when-not-to-use and no mention of the obvious sibling alternatives that also return candle data for other entities.

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, open-world behavior. The description adds the exact endpoint and time-window limit, but it does not disclose pagination behavior despite page/limit parameters, nor rate limits or other operational context.

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 short and front-loads the endpoint and key constraints. The opening 'Holder Count History' repeats the title and earns little, but the rest is efficient.

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 a full output schema, high schema coverage, and safety annotations, the description provides enough context to call the tool. Pagination semantics for page/limit are the main unaddressed behavioral detail.

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

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

Schema description coverage is 100%, so the schema already documents all parameters including unix timestamps, the 30-day window, and interval values. The description largely repeats those constraints rather than adding new parameter meaning.

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 specific resource (holder count history) and exact endpoint, making the operation clear. It does not explicitly differentiate from related sibling tools such as get-token-top-holders, but the endpoint name supplies enough specificity.

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 tells the agent to pass startTime and endTime and gives the 30-day maximum constraint, which implies usage for historical holder-count time series. However, it does not state when to use this tool versus alternatives like get-token-top-holders or other token history tools.

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, idempotent, open-world, and non-destructive behavior. The description adds that it calls only the liquidity endpoint and aggregates across all trading markets, but does not discuss freshness, error cases, or rate limits.

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

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

The description is short and front-loads the endpoint and purpose. The opening 'Token Liquidity' restates the title and 'returns that response' is low-value, but the overall text is efficient.

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

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

For a one-parameter read-only lookup with annotations and an output schema, the description provides enough context to select and call the tool. Remaining details like error behavior or data freshness are minor omissions rather than blockers.

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% for the single mintAddress parameter, and the description adds no meaning beyond what the schema and path already document. Baseline 3 is appropriate when the schema carries parameter semantics.

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

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

The description states a specific verb and resource: fetching total USD liquidity for a Solana token, aggregated across all trading markets. It is clear what the tool returns, though it does not explicitly distinguish itself from nearby token/market tools beyond the unique liquidity scope.

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 a concrete use case: assess depth before trading. It does not mention alternatives or when not to use it, but the intended context is 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 declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered; the description adds genuinely new behavior: data covers the top 1000 wallets and refreshes every 3 hours, plus it scopes the response ('calls only this endpoint and returns that response'). Freshness cadence is the kind of trait annotations cannot express.

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 short: the endpoint scope, subject matter, and returned fields come in order. The leading 'Top Holders.' restates the title and 'returns that response' is slightly circular, but there is no filler beyond that.

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 a full output schema and 100% parameter coverage, the description only needs to add orientation and cost/freshness context, which it does (top 1000 wallets, 3-hour refresh, endpoint isolation). Only the missing sibling routing keeps it from being fully complete.

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

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

Schema description coverage is 100%, with page, limit, sortByAsc/sortByDesc and mintAddress all documented in the schema, so the baseline is 3. The description's 'top 1000 wallets' loosely echoes the limit default but adds no sorting, pagination, or format guidance beyond the schema.

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

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

States a specific verb and resource ('fetching top token holders and whales') and names the exact endpoint, so an agent can tell it retrieves holder/distribution data rather than trades or counts. It stops short of explicitly contrasting with the nearest siblings (list-top-traders, get-token-holder-count-history, get-token-top-pnl-traders), leaving that differentiation to inference.

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

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

Usage is implied by the endpoint description and the field list ('ownership %, USD value, and labels'), but there is no explicit when-to-use or when-not-to-use statement and no mention of the alternatives available in the sibling set. An agent must infer from names alone whether to pick this or list-top-traders.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it calls exactly one GET endpoint and mirrors that response, and lists the kinds of values returned (volumes, counts, wallet addresses), but says nothing about pagination behavior, rate limits, or auth.

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 purpose and the endpoint mapping. Minor waste in restating the title verbatim as the first sentence and in the filler phrase 'and returns that response.'

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 a rich output schema and full annotation coverage, the description needn't explain return values, and it correctly explains scope and the underlying endpoint. The only real gap is routing guidance relative to the several other top-trader and token-metrics 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 100%, so the baseline is 3: page, limit, sortByAsc/sortByDesc, and resolution are all documented in the schema itself. The description adds nothing about format, defaults, or the mutual exclusivity of the sort parameters beyond what the schema already states.

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: fetches top token traders ranked by realized and unrealized PnL, along with the exact REST endpoint it wraps. It implicitly distinguishes itself from get-token-top-holders and list-top-traders by the 'By Token' + PnL framing, but never names those siblings explicitly.

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

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

The description never says when to choose this over list-top-traders (global ranking) or get-token-top-holders (ownership vs trading), nor does it mention prerequisites such as a valid mint address or access requirements. Usage is only inferable from the title and endpoint path.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the concrete endpoint contract and the shape of the returned metrics, but says nothing about pagination caps (limit defaults to 1000), rate limits, or freshness of the PnL window.

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 first sentence merely repeats the title, and the third sentence restates the second ('returns that response' / 'endpoint for fetching token trader activity'). The valuable content (endpoint path, returned metrics) is there but padded by redundant framing.

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 the input schema is fully documented, so the description needn't explain return values — and it doesn't overreach. However, for a tool with 10 parameters and several near-duplicate siblings, it lacks the disambiguation an agent needs to route 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 100% and every parameter already carries a detailed description, including the mutual exclusivity of sortByAsc/sortByDesc and the meaning of the *Gt filters. The description adds no parameter-level information beyond that, which is the expected baseline when the schema does the work.

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 ('fetching token trader activity') and pins the exact endpoint GET /v4/tokens/{mintAddress}/trader-activity, plus names the metrics returned (buy/sell volume, PnL, win/loss). It does not distinguish itself from close siblings like get-token-top-pnl-traders or list-top-traders, which makes the boundary less crisp.

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

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

The only usage signal is the loose framing 'identify active traders and whales'. There is no explicit when-to-use/when-not, and no mention of the obviously competing siblings (get-token-top-pnl-traders, list-top-traders, get-token-top-holders) that an agent would need to choose between.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing that this is a thin passthrough to a single GET endpoint returning that response, but says nothing about rate limits, auth requirements, or the shape of the time series beyond what the enums imply. An output schema exists, so return-value explanation is not required.

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 sentences where two would suffice: the leading "Trade Volume Timeseries." restates the title, and "Solana API endpoint for fetching token trade volume over time" duplicates the first clause's meaning. The endpoint-scoping sentence is the genuinely useful one, but it is not front-loaded.

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 rich annotations, a full output schema, and 100% schema description coverage, the description is complete enough for an agent to call the tool correctly: it knows the resource, the granularity, and the metrics available. Only the lack of sibling differentiation keeps it from a 5.

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

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

Schema description coverage is 100% and both enum-bearing parameters are documented in-schema, so the baseline is 3. The description only restates the enum semantics ("hourly or daily", "buy and sell volumes or counts") without adding syntax, unit, or range conventions — notably it does not clarify the unix-timestamp format for timeStart/timeEnd, which the schema does cover anyway.

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 — fetching token trade volume over time — and names the exact endpoint GET /v4/tokens/{mintAddress}/trade-volume-ts, which lets an agent distinguish it from get-token-candles or get-token-liquidity by resource. It stops short of explicitly contrasting with those siblings, so a 4 rather than 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?

"Track buy and sell volumes or counts hourly or daily to analyze trading trends" implies the appropriate context, but there is no explicit when-to-use/when-not guidance and no named alternative for related analytical needs (e.g. candles vs. aggregated volume). Usage must be inferred from the sentence.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that it issues exactly one GET and returns that response verbatim, which is modest but real value; it says nothing about pagination behavior, the 1000-item default result size, or auth/cost constraints.

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

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

Three short sentences with no padding, but the first two are partly redundant — 'Calls only GET /v4/...' and 'Solana API endpoint for fetching wallet counterparties' convey nearly the same fact. The analytical use-case sentence is the only one that earns new 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 an output schema present, return values need not be described, and annotations cover the safety profile. What remains thin is guidance on combining the time-range, grouping and sort parameters for meaningful analysis, but for a single-endpoint read tool the description is largely sufficient.

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

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

Schema description coverage is 100%, so every parameter (page, limit, timeStart/timeEnd, sortByAsc/sortByDesc, group, ownerAddress) is already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb ('fetch') and resource ('wallet counterparties'), and even pins the exact endpoint GET /v4/wallets/{ownerAddress}/counterparties. The resource is distinct from siblings like get-wallet-transfer-volume or list-transfers, though the description never contrasts itself with them explicitly.

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

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

The closing clause ('Analyze transfer relationships, volumes and interactions with wallets or programs over time') implies the use case, but there is no explicit when-to-use, when-not-to-use, or named alternative such as get-wallet-transfer-volume or list-transfers for adjacent questions.

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, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real value beyond that by naming the single underlying call (GET /v4/wallets/{ownerAddress}/defi-positions) and sketching the response shape (a flat list of self-contained position elements under `data.portfolio`), which tells the agent there is no aggregation and no side effects.

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 opening repeats the title verbatim ('DeFi Positions.'), and the text is cut off mid-sentence at '— there', leaving an unfinished clause. The endpoint and protocol enumeration are front-loaded and useful, but the lead-in wastes a sentence and the truncation damages structure.

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 fully explained, and the tool is a simple single-parameter read. Still, the description trails off mid-thought about the response structure, so the one piece of extra context it was trying to supply is left incomplete.

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

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

Schema description coverage is 100% for the single parameter, and the schema already explains ownerAddress as a typed Solana public key path parameter. The description adds nothing about the parameter beyond what the schema states, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource: it returns a wallet's live DeFi positions and enumerates the covered protocol categories (lending/borrowing, liquidity pools, perps, DCA, staking, rewards, vesting). This is far more informative than the title, though it never explicitly contrasts itself with lookalike siblings such as get-wallet-token-balances or get-wallet-pnl.

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

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

There is no statement of when to choose this tool over alternatives, no prerequisites, and no exclusions. The agent must infer from the protocol list that this is the wallet-level DeFi exposure endpoint rather than a token-balance or PnL endpoint.

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, idempotent, non-destructive and open-world behavior, so the bar is lower. The description adds that it calls only that one endpoint and returns the response verbatim, which is mildly useful, but says nothing about pagination caps, rate limits, or result volume.

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 that front-load the endpoint and the resource. There is mild redundancy between 'Calls only GET ... and returns that response' and 'Solana API endpoint for fetching ...', and the leading 'Dust Accounts.' restates the title, but nothing is padded.

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

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

An output schema exists and annotations cover the safety profile, so the description only needs to establish what the tool hits and why. It does that; only secondary details like pagination behavior under the 1000-default limit or batch-tool tradeoffs are absent.

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 page, limit, sortByAsc/sortByDesc and ownerAddress are fully documented in the schema. The description only alludes to ownerAddress through the endpoint path, adding no new parameter meaning; baseline 3 applies.

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

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

States a specific verb and resource: fetching dust Token-2022 and SPL token accounts for a wallet, plus the concrete endpoint GET /v4/wallets/{ownerAddress}/dust-accounts. It does not explicitly distinguish itself from close siblings like get-wallet-empty-accounts or get-dust-accounts-batch, so it stops short of a 5.

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

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

The phrase 'reclaimable tokens to identify accounts for rent recovery' implies the use case, but there is no explicit when-to-use guidance and no routing to alternatives such as the batch variant or the empty-accounts endpoint. Usage must be inferred from the purpose statement.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that this is a pure passthrough of one specific endpoint ('calls only ... and returns that response'), but says nothing about pagination behavior, result size caps, or rate limits.

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

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

The opening 'Empty Accounts.' merely repeats the title, and the second and third sentences overlap in describing the same endpoint. The useful content (single-endpoint passthrough, Token-2022/SPL scope, rent-cleanup purpose) is present but could be stated in two 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?

With an output schema present, a fully documented input schema, and complete annotations, the description only needs to establish purpose and data scope, which it does. The remaining gap is routing between this tool and the very similar batch/dust-account siblings, which is a usage rather than completeness issue.

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

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

Schema description coverage is 100% and the schema already documents page, limit, sortByAsc, sortByDesc, and ownerAddress thoroughly, including the mutual exclusivity of the sort parameters. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource: fetches empty Token-2022 and SPL token accounts for a wallet via GET /v4/wallets/{ownerAddress}/empty-accounts. It does not, however, distinguish itself from close siblings like get-empty-accounts-batch, get-wallet-dust-accounts, or get-dust-accounts-batch, which appear to cover overlapping 'rent cleanup' territory.

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

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

Usage is only implied through the phrase 'Returns results to identify accounts eligible for rent cleanup,' which hints at the underlying goal without stating when to pick this tool over the batch or dust-account siblings. No exclusions, prerequisites, or explicit alternatives are given.

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 readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds that it hits exactly one endpoint (GET /v4/wallets/{ownerAddress}/pnl) and summarizes what the payload contains, which is useful context, but says nothing about rate limits, auth, pagination behavior, or failure modes.

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 endpoint mapping and the metric list front-loaded and no filler. The opening 'Wallet PnL.' merely restates the title, which is the only wasted fragment.

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 explain return values, and it is adequate for calling the tool. The missing piece is routing guidance against the PnL-adjacent siblings, which matters given how many wallet/token analytics tools are in this server.

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

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

Schema description coverage is 100%, so all seven parameters (including resolution, page, limit, mintAddress and the sortBy fields) are documented in the schema itself. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific verb and resource (fetch wallet PnL) and enumerates the returned metrics (realized/unrealized PnL, win rate, trade volume, per-token performance). It implicitly distinguishes itself from get-wallet-pnl-history by omitting a time-series framing, but never states that distinction explicitly.

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

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

There is no guidance on when to choose this over the nearby siblings get-wallet-pnl-history or get-token-top-pnl-traders, and no statement of prerequisites or exclusions. The only usage-adjacent signal is the 'vetted markets' scope, which is descriptive rather than directive.

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, idempotent, open-world, non-destructive behavior. The description adds that it calls only the GET /v4/wallets/{ownerAddress}/pnl-ts endpoint and returns that response, which is useful, but it does not discuss auth, rate limits, or pagination.

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 short but contains redundancy: the first sentence only repeats the title, and 'Solana API endpoint for fetching wallet PnL timeseries data' largely restates the endpoint sentence. The useful content is present but not as front-loaded or economical as it could be.

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

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

Given the rich input schema, existing output schema, and detailed annotations, the description supplies enough context for correct invocation: endpoint, resource, and granularity. The main remaining gap is explicit differentiation from the sibling get-wallet-pnl 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 description coverage is 100%, so the schema already documents ownerAddress, timeStart, timeEnd, and resolution thoroughly. The description reinforces the day/week/month resolution granularity but adds no syntax or default details beyond the schema.

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

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

The description clearly states a specific resource: wallet PnL timeseries data, with realized PnL bucketed by day, week, or month. It distinguishes the timeseries nature implicitly from the sibling get-wallet-pnl, but it does not explicitly name or contrast with that sibling.

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

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

The phrase 'for tracking wallet performance over time' implies when this tool is appropriate, but there is no explicit guidance on when to use it versus get-wallet-pnl or other wallet analytics tools. Alternatives and exclusions are not 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds that it makes exactly one upstream call and returns the provider response unmodified with unprocessed snapshots, which is useful behavioral context, but it says nothing about pagination behavior, rate limits, or data volume (the limit/days caps live only in the 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?

Three short sentences, front-loaded with the core purpose and the single-endpoint constraint, with no filler. The opening "Token Account History." merely repeats the title and is the only wasted fragment.

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 a full output schema and 100% parameter coverage, the description needs only to frame purpose and routing, which it does adequately. What is missing is differentiation from get-wallet-token-balance-history and any note on the 30-day/1000-entry caps that shape how the tool is called in practice.

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

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

Schema description coverage is 100% and every parameter (days, page, limit, sortByAsc/Desc, vybeTokenFilter, ownerAddress) is documented in the schema itself. The description adds no parameter meaning beyond restating the endpoint path parameter, so the baseline 3 applies.

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

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

"Fetching raw wallet token account history with unprocessed balance snapshots" gives a specific verb and resource, and the endpoint mapping (GET /v4/wallets/{ownerAddress}/token-accounts-balance-ts) pins down the exact scope. It does not explicitly distinguish itself from the very similar sibling get-wallet-token-balance-history, so an agent has to infer the difference from the words "raw" and "unprocessed".

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?

"For custom time series analysis and advanced processing" implies when this tool is appropriate, but there are no explicit exclusions and no named alternative for the common case (e.g. "use get-wallet-token-balance-history for processed/summarized balances"). Usage is only implied.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, openWorld=true, so the safety profile is covered. The description adds the exact endpoint it calls and that it returns that response verbatim, plus the snapshot granularity, but says nothing about rate limits, auth, or data freshness.

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?

Compact and front-loaded, but the opening 'Token Balance History.' merely restates the title and does not earn its place. The remaining two sentences are efficient and 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?

A read-only, well-annotated tool with a full output schema and 100% parameter coverage; the description's job is only to establish scope, which it does. Nothing an agent needs 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 description coverage is 100%, so all four parameters are already documented in the schema. The description reinforces the resolution semantics ('daily, weekly, or monthly ... over time series') and the USD valuation nature of results, but adds no new detail beyond the schema.

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

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

States a specific verb and resource: fetching wallet token balance history over time series, with daily/weekly/monthly portfolio snapshots and USD valuations. The wallet-scoped framing implicitly separates it from token-centric siblings like get-token-balance-history-batch, but no sibling is named explicitly.

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

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

Usage is implied: the mention of time series and portfolio snapshots over time tells the agent this is for historical balance trends rather than current balances (get-wallet-token-balances). However, there is no explicit when-to-use / when-not-to-use guidance or named alternative.

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, idempotentHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds one genuine behavioral fact – that it calls only this single endpoint and returns that response verbatim – but says nothing about pagination behavior, rate limits, or response size despite the 1000-entry default limit.

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 compact sentences with the scope constraint front-loaded before the capability list. The opening 'Token Balances.' is a verbatim restatement of the title and earns nothing, but the remaining text is efficient.

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, the description needn't explain return shape, and 100% schema coverage plus full annotations cover the mechanics. What remains thin is differentiation from the batch and history siblings, which is the only thing an agent could plausibly get wrong here.

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

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

Schema description coverage is 100%, so all 11 parameters including the sortByAsc/sortByDesc exclusivity and the minAssetValue/maxAssetValue override behavior are already documented in structured data. The description adds no parameter-level meaning beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('fetching wallet token balances') and names the exact endpoint GET /v4/wallets/{ownerAddress}/token-balance, plus enumerates the asset types returned (SPL, Token-2022, USD values, staking balances). It never names a sibling, so the agent must infer the difference from get-token-balances-batch or get-wallet-token-balance-history, which keeps 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?

Usage is only implied: 'for fetching wallet token balances' tells the agent what class of task it fits, but there is no explicit when-to-use, no exclusions, and no routing to the batch or history variants in a sibling list that contains three closely related balance tools. Given the crowded sibling set, this is a real gap.

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, idempotentHint, openWorldHint and destructiveHint=false, so the description's contribution of 'calls only GET ... and returns that response' mainly confirms it is a single-endpoint read. It adds nothing about auth requirements, rate limits, or pagination/result size beyond what annotations and the output schema supply.

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 short and front-loaded, but two of the three sentences restate the same idea ('Transfer Volume USD' then 'Solana API endpoint for fetching wallet transfer volume in USD'). The endpoint sentence is the only one carrying unique 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 an output schema present, 100% schema coverage, and full annotations, the description need only confirm the resource and semantics — which it does. The remaining gap is sibling differentiation, which slightly limits how self-sufficient 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?

Schema coverage is 100%, so the schema already documents ownerAddress as a path parameter and the timeStart/timeEnd defaults. The description adds no syntax, format, or default information beyond that, which is the expected baseline when the schema does the heavy lifting.

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 (fetch) and resource (wallet transfer volume in USD) and names the exact endpoint. It is clear the tool returns sent and received totals, but it never explicitly distinguishes itself from close siblings like get-wallet-counterparties or list-transfers.

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

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

Usage is only implied through 'to analyze fund flow, activity levels and net movement' — there is no explicit when-to-use, when-not-to-use, or named alternative among the many wallet/transfer siblings. An agent must infer the choice context itself.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context specific to this tool: it is a static, no-side-effect guide that neither initiates payment nor performs network calls. It does not describe the guide's contents or whether the guidance is versioned, 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?

Two sentences, front-loaded with what it returns and what triggers use, followed by the exclusion clauses. Every clause earns its place by preventing a costly misinterpretation (treating it as a paying endpoint call).

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 zero parameters, the description need only establish what the tool is and when to call it, which it does. Minor gap: it does not hint at what the returned guidance contains or that the agent must apply it manually before retrying the paid sibling 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?

The tool takes zero parameters, so there is no parameter semantics to explain; baseline is 4. The description correctly signals a no-argument call by saying it returns static guidance with no input described.

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 ('Returns') and resource ('static guidance for calling the Vybe API with x402 pay-per-call') plus the triggering condition ('no API key is available'). The negative clauses explicitly separate it from the query/build siblings, so an agent can tell it is documentation, not an endpoint call.

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

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

Gives a clear condition for use ('when no API key is available') and effectively excludes the action siblings by stating it does not call an endpoint or sign anything. It stops short of naming which sibling to use instead (e.g., query-vybe-api) once credentials exist, but the context is unambiguous.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that it makes a single GET call and returns that response verbatim, which is useful context about the pass-through nature, but says nothing about pagination, result size, or behavior when all optional filters are 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?

It leads with the endpoint call, which is good front-loading, but the first fragment 'Instruction Names.' duplicates the title and wastes a sentence. The remaining sentences are compact but the middle one is redundant with the purpose already implied.

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 correctly states it is a single-endpoint pass-through lookup. What is missing is what happens with zero arguments (presumably all instruction names) and whether the four filters are ANDed — a modest gap for a 4-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 description coverage is 100%, so all four filters (ixName fuzzy search, programName, callingInstructions discriminant, callingProgramAddress) are already documented in the schema. The description adds no semantics about how the filters combine or which takes precedence, so it lands at the baseline.

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

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

The description names a specific resource and action: fetching available token instruction names for Solana programs via a named endpoint. That is more than a restatement of the title, though the opening 'Instruction Names.' sentence is a tautology and no sibling (e.g. list-labeled-programs, list-supported-dexes) is named to sharpen the boundary.

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?

'Use to filter and categorize on-chain token program interactions' hints at intent but gives no conditions, no exclusions, and no alternative tools to choose instead. An agent can infer it is a reference-lookup list tool, but only by reading the schema.

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, idempotent, openWorld, and non-destructive, so safety is covered. The description adds the useful concrete detail that it calls only that one endpoint and returns the raw response, but says nothing about result size limits despite advertising 10000+ entities.

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 endpoint contract. The leading 'Labeled Accounts.' merely restates the title and earns little, but overall there is minimal waste.

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 the schema fully documents parameters. Only the pagination/result-volume behavior for a 10000+ entity dataset is left 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 description coverage is 100%, so all seven parameters are self-documenting; baseline is 3. The description's mention of CEX/KOL/VC/entity name/address loosely maps to labels, entityName, and accountAddress but adds no syntax or semantics beyond the schema.

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

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

The description gives a specific verb+resource (fetching labeled wallets, programs and accounts) and names the exact endpoint GET /v4/wallets/labeled-accounts. It doesn't distinguish itself from the sibling list-labeled-programs, which is a notable overlap given both surface labeled entities.

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 says what can be filtered (CEX, KOL, VC, entity name, address) but never states when to choose this tool over list-labeled-programs or other list-* siblings. Usage is implied by the filter categories rather than explicitly framed.

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 description confirms that the tool uses a GET request against a specific public API endpoint (/v4/programs/labeled-program-accounts). Since the annotations already cover safety profiles (readOnlyHint, destructiveHint), the description adds helpful, but not critical, operational context.

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

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

The definition is highly concise and direct. It identifies the resource, the API method, and the operational scope in just two clear sentences without unnecessary jargon or 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?

The combination of 7 parameters, robust annotations, and the clear statement of its function provides a complete enough picture for an agent. The description successfully conveys the 'why' behind the tool's existence.

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?

Given that schema coverage is 100%, the baseline score of 3 applies. The description does add high-level guidance on how labels function ('matching all labels'), which is reinforced in the schema but contextualized here.

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 defines the resource (Solana program accounts) and the action (fetching/identifying). By mentioning 'labeled program accounts across DEX and protocols,' it provides excellent operational context, making it distinct from general account listing tools.

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

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

The description implies the usage scenario (identifying labeled programs), but it fails to explicitly compare when to use this tool versus similar siblings, such as list-labeled-accounts. It offers context without providing explicit operational boundaries.

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, idempotent, openWorld, and non-destructive semantics. The description adds real context by disclosing that this is a thin passthrough of GET /v4/markets and what the response contains, but it says nothing about pagination behavior despite page/limit parameters, nor about rate limits or response size.

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

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

Four short sentences, front-loaded with the core resource and the endpoint it wraps. Minor redundancy in restating the title and repeating 'Solana' multiple times, but nothing is wasted.

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

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

An output schema exists, so the return values need not be explained in depth, and annotations are rich. However, with six optional parameters including four opaque public-key filters, the description should clarify that the mint addresses act as filters and how page/limit interact — that gap keeps this at minimum-viable.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the programAddress filter but adds nothing for page, limit, or the baseMintAddress/quoteMintAddress/tokenMintAddress parameters, whose schema text is generic ('Typed Solana public key identifier used across request parameters and response fields').

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 ('fetching Solana DEX markets by program address') and enumerates the returned data (market IDs, token pairs, program names for Pump.fun, Raydium). It does not explicitly distinguish itself from the sibling get-market, but the 'list' vs 'get' framing plus the filter description makes the distinction inferable.

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

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

Usage is only implied: the agent can infer this is for enumerating markets filtered by program address. There is no explicit when-to-use, no mention of when to prefer get-market for a single market, and no guidance on list-supported-dexes as an alternative.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that it 'calls only GET /v4/oracle/pyth/pricefeeds and returns that response', which is modest extra context, but says nothing about pagination, result size, or auth/rate-limit behavior.

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

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

Front-loaded with the endpoint path, but the opening 'Pyth Price Feeds.' merely restates the title, and the third sentence repeats the second's purpose while saying 'Solana' twice. Roughly one sentence of the three 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?

An output schema exists, so return-value documentation is not required, and annotations cover the read-only/idempotent contract. What remains thin is how the two optional key parameters affect the listing, but overall it is sufficient to call 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 100%, so the baseline is 3 even though the description never mentions the two optional parameters. The description adds no meaning about whether productAddress/priceFeedAddress act as filters on this list call, which is the one thing the schema's generic public-key text does not resolve.

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+resource: discover all available Pyth price feeds and their product accounts, plus the exact endpoint GET /v4/oracle/pyth/pricefeeds. 'all available' implicitly separates it from siblings like get-pyth-price and get-pyth-product, but the differentiation is left implicit rather than named.

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

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

Usage is only implied by 'Discover all available Pyth price feeds' — an agent can infer this is the enumeration call before fetching a specific price or product. No explicit when-to-use/when-not guidance and no sibling tool is named as the alternative.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing that it makes exactly one GET call and returns the response verbatim, implying no pagination, filtering, or transformation.

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 statement, but the first sentence merely restates the title and the second and third sentences overlap ('supported DEXs in the Solana ecosystem' said twice). The payload field listing also duplicates what the output schema already provides.

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

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

For a zero-parameter, read-only reference endpoint with full annotations and an output schema, this is close to complete: the agent knows the source endpoint, that it is a single call, and roughly what comes back. Only the absence of any usage guidance keeps it from the top 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-param tool applies. The description correctly signals the absence of inputs by noting it only calls a fixed endpoint.

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 ('fetching all indexed supported DEXs') plus the exact endpoint, so an agent knows precisely what it retrieves. It doesn't explicitly contrast with siblings like list-labeled-programs or list-markets, but the resource is distinct enough that confusion is unlikely.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no named alternative. The phrase 'Calls only GET /v4/reference/dexes and returns that response' implies this is a static reference lookup with no filtering, which is usable context but only implicitly 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, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds that it returns the raw endpoint response (no post-processing/aggregation) and that results are paginated, but says nothing about rate limits, auth, or ordering defaults — modest added value over 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 leading 'Token List' merely restates the title, and 'returns that response' carries little information beyond a backend implementation note. The substantive content (token universe, pagination, summary metrics) is present and reasonably front-loaded, but roughly a third of the text is filler.

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

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

With rich annotations covering safety and an output schema present, the description only needs to convey scope and return shape; it does say the result is a paginated list of tracked tokens with summary metrics. Nothing critical is missing for an all-optional, read-only list 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 description coverage is 100%, so all six optional parameters (name, symbol, page, limit, sortByAsc, sortByDesc) are already documented, including the mutual exclusivity of sort directions. The description adds only the general notion of pagination and does not elaborate on filtering or sort-field value syntax, 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 specific verb and resource: fetching paginated lists of all tracked Solana tokens (Token-2022 and SPL) with summary metrics, and names the underlying GET /v4/tokens endpoint. It is distinguishable from siblings like get-token (single token) by the plural list framing, though it never explicitly contrasts with them.

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

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

No guidance on when to use this versus alternatives such as get-token, list-top-traders, or the various get-token-* metric tools. The only implied usage is that it pages through the full token universe, but the agent must infer that from 'paginated lists' with no stated conditions or exclusions.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that it is a thin pass-through to a single endpoint returning that response verbatim, which is mildly useful. It says nothing further about pagination limits or truncation beyond what the schema already states.

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 endpoint mapping and scope come first, which is the right front-loading, and the whole thing is four short sentences. The closing marketing sentence about copy trading leaderboards is the weakest part and only loosely earns its place.

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 all eight parameters are documented, so the description need not explain returns; the annotations cover safety. The remaining gap is sibling disambiguation from get-token-top-pnl-traders, which the description leaves implicit.

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

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

Schema description coverage is 100%, so all eight parameters including sortByAsc/sortByDesc, resolution and ilikeFilter are already documented. The description mentions ranking by PnL, win rate and volume, which loosely maps to the sort fields, but adds no syntax or interaction details (e.g. mutual exclusivity of sort directions) beyond the schema.

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

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

States a specific verb and resource ('Calls only GET /v4/wallets/top-traders') plus the ranking dimensions (PnL, win rate, volume), which makes the wallet-level scope recognizable. It does not name or contrast with the closest sibling, get-token-top-pnl-traders, so an agent must infer that this returns traders across the whole DEX rather than per-token.

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

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

Usage is only implied: 'Power copy trading leaderboards and smart money discovery tools' suggests the intended scenarios but gives no explicit when-to-use or when-not-to-use rules. There is no mention of how it differs from get-token-top-pnl-traders or list-labeled-accounts, both of which an agent could plausibly reach for.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavior context by saying it calls only GET /v4/trades and returns that response, implying a direct passthrough, but it does not mention rate limits, authentication, or pagination behavior beyond what the schema provides.

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 three short sentences and front-loads the resource and endpoint mapping. 'Trade History' restates the title somewhat redundantly, but the rest is efficient with no wasted prose.

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

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

For a 17-parameter tool with an output schema and rich annotations, the description gives a minimally adequate orientation. It does not summarize the broad set of available filters or mention notable behavioral details, but the schema and output schema already carry most of the burden.

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

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

Schema description coverage is 100%, so all 17 parameters are already documented in the schema. The description adds only a high-level mention of filtering by program, which maps loosely to programAddress, but does not add syntax or semantics beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (trade history) and ties it to the exact endpoint GET /v4/trades, making the core purpose clear. It does not explicitly distinguish this tool from siblings such as list-transfers or get-token-trader-activity, so sibling differentiation is only implicit.

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

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

The description names a filtering capability ('filtered by program') but gives no explicit guidance on when to use this tool versus alternatives. There are no when-not conditions, no prerequisites, and no sibling routing hints.

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/idempotent/openWorld/non-destructive, and the description adds real value beyond them: it discloses that exactly one endpoint is called and its raw response is returned unmodified, which lets an agent predict the payload shape. It stops short of disclosing pagination/rate-limit behavior for what is a potentially high-volume, open-world query.

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 compact sentences, front-loaded with what the tool fetches, with no filler. The leading 'Transfer History.' repeats the title and is slightly wasted, and the endpoint-mechanics sentence reads as an internal implementation note, but the prose is tight overall.

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

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

With 16 optional params, an output schema, and full annotation coverage, most burden is carried elsewhere, and the description correctly needn't explain return fields. However, for a paginated open-world query defaulting to up to 1000 rows it says nothing about pagination strategy or how filters combine, leaving a meaningful gap.

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

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

Schema coverage is 100%, so all 16 parameters are already documented, and the description only restates the filter categories (mint, sender, receiver, amount, time) without adding format, combination, or default semantics. It also omits sort and address-type params entirely, but the schema covers those, 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 specific verb and resource: fetch historical Token-2022/SPL transfers, with the exact upstream endpoint (GET /v4/transfers) and the filter surface (mint, sender, receiver, amount, time range). It is clearly not a trade list or a wallet aggregate, but it never explicitly contrasts itself with the close sibling list-trades.

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

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

The phrase 'for analytics and whale tracking' implies a use case, but there is no explicit when-to-use/when-not and no naming of an alternative such as list-trades or get-wallet-transfer-volume. An agent must infer the routing decision from the names alone.

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