coin-scout

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

Annotations already declare the safe-read profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so that burden is lifted. The description adds real behavioral substance by explaining the analytical method – top1/top10/HHI concentration with program-owned pools separated from real holders – which tells the agent the metric is pool-adjusted and not a naive headline number. It stops short of stating rate limits, whether scores are cached, or how flags are worded.

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

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

A single dense sentence with the purpose front-loaded before the enumerated checks, so nothing needs scanning. The middle section is a long list, but each item is a distinct analysis dimension rather than filler, so it is appropriately sized for a tool with no output schema.

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

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

With no output schema, the description must convey what comes back, and it does: the listed metrics plus a 0-100 risk score and explicit flags. That is enough for an agent to know what it will receive. The remaining gap is the undocumented 'holders' parameter, which leaves input semantics 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 coverage is 50%: 'mint' is documented as a Base58 Solana address, but 'holders' (integer, min 1, max 20, default 20) has no description anywhere, and the description never mentions it. Given the low coverage, the description should have explained what this bounded parameter controls (e.g. depth of the holder-concentration sample), and it does not.

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

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

States a specific verb (screen) and resource (SPL mint) and enumerates exactly what is checked: authorities, metadata mutability, supply/FDV, holder concentration, plus a risk score and flags. An agent can distinguish it from the raw-data siblings like get_token_holders or get_assets without opening any schema, since this is the only tool described as producing an analytical risk verdict.

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 'Rug-pull and manipulation screen' implies the use case (due diligence on a mint before interacting), but there is no explicit when-to-use or when-not-to-use guidance and no named alternative for simpler lookups such as get_token_holders. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds the heuristic risk flags and notes that higher transferSample is slower but more accurate, providing some behavioral context beyond annotations. However, it doesn't clarify what 'heuristic risk flags' entail or how they are computed.

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 a single, dense sentence that front-loads the key capabilities and a directive. Every phrase adds value without redundancy.

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

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

Given the complexity of a multi-faceted wallet analysis tool, the description covers the main outputs and usage context. It lacks details on output format (no output schema) and the meaning of certain parameters, but remains largely complete for an agent to invoke it correctly.

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

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

Schema description coverage is 50%; address and transferSample are documented in the schema, but holdings and counterparties lack descriptions. The description does not add meaning for these parameters, leaving gaps for the undocumented ones.

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 specifies a clear verb+resource: 'One-call wallet profile' that includes portfolio value, holdings, first/last activity, flow shape, top counterparties, funders, and risk flags. It distinguishes itself from siblings like wallet_pnl or find_counterparties by offering a composite overview.

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

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

It explicitly states 'Start every wallet investigation here,' giving clear guidance on when to use this tool first. This implicitly positions it as a hub before more specialized tools like trace_funds or wallet_pnl.

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 declare readOnlyHint=false and idempotentHint=true, and the description's 'write the case to disk' is fully consistent with a non-read-only, non-destructive, repeatable operation. It adds genuine value beyond the annotations by naming the exact file outputs and stating that file paths are returned. It does not say where on disk files land or whether existing files are overwritten, which keeps it short of 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 the primary action and output file, then the diagram artifacts and return value. Dense but every clause carries information; the parenthetical enumeration is slightly heavy but earns its place by specifying artifact types.

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

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

With no output schema, the description correctly carries the return-value burden by stating it returns file paths, and it describes the generated contents in enough detail for an agent to know what it gets. Only the destination directory and overwrite behavior are left unspecified.

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

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

Schema description coverage is 100%, so both parameters (case, artifactId) are already documented in the schema; the description adds no syntax or format detail beyond them. The 'per saved trace or cluster' phrasing loosely relates to the artifact-scoping behavior but does not explicitly explain the artifactId filter, 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 (write/export), resource (the case), and enumerates the concrete artifacts produced (report.md with labels, notes, tables, Mermaid diagrams, plus per-trace/cluster SVG fund-flow diagrams). An agent can immediately distinguish this from case_read and case_update siblings.

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

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

The phrase 'ready to drop into a report' hints at the reporting use case, but there is no explicit guidance on when to call this versus case_read or case_update, nor any stated prerequisite that the case must already contain saved traces/clusters for the SVG output to be produced.

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 and destructiveHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: what each mode returns (labels, notes, artifact index) and that artifactId expands a single trace/cluster/bridge result in full. Limits such as result caps or pagination are not mentioned.

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 a single dense sentence-per-mode block with no filler; the no-argument case is correctly front-loaded. The em-dash constructions make it slightly run-on and require a second read, which keeps it out of the top band.

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

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

With no output schema, the description takes on return-value disclosure and does so per mode, which is the right call for a three-mode read tool. The main omission is guidance on result size or whether the list/search is truncated.

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

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

Schema coverage is only 67% (artifactId has no schema description at all), so the description must compensate, and it does: it explains that address triggers a cross-case search for prior labels/notes/traces and that artifactId fetches one artifact in full. That is more semantic detail than the schema supplies, though the interaction between case and artifactId could be spelled out further.

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

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

The description opens with a specific verb and resource ('list every case') and then enumerates each invocation mode (no args, address, case, artifactId). This distinguishes it cleanly from sibling case_update and case_export, which are the only other case-* tools. An agent knows exactly what this tool does before opening the schema.

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

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

It gives explicit when-to-use guidance per mode, including an unusually strong directive: search by address 'before starting on any address.' It does not name alternative tools (case_export, case_update) or state when not to use it, so it falls short of the top band, but the conditional routing 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 cover the safety profile (readOnly=false, destructive=false, idempotent=false), so the bar is lower. The description adds a genuinely useful behavioral trait not in the schema: labels are shown by every other tool from then on, across sessions and cases. It omits the destructive side effect of removeLabels, but the cross-tool persistence disclosure is valuable 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?

Two sentences, front-loaded with the core action, no filler. Slightly dense with the parenthetical enumerations, but every clause carries information.

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

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

For a 7-parameter case-authoring tool with no output schema and only 43% schema coverage, the description covers the intuition but leaves removeLabels and the note-address/signature plumbing unexplained. Adequate for the main flow, incomplete around deletion and note metadata.

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 43% (low), so the description must compensate. It names summary, labels (with confidence and evidence signatures), and notes (findings, leads, retractions), which maps to several params, but it says nothing about removeLabels, noteAddresses, or noteSignatures. Partial but not full compensation.

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+resource: it creates/adds to a case (summary, labels, notes). An agent can tell it is a mutating case-authoring tool rather than a reader. It does not name the sibling case_read/case_export explicitly to sharpen the contrast, so it stops at 4.

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 content (add findings, labels, notes to a case), but there is no explicit when-to-use/when-not or reference to the alternative case_read/case_export tools. It is inferred rather than 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 establish readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: the call is cheap (cost guidance) and its data is point-in-time 'current', useful as a freshness anchor. It omits how often values change or whether the priority fee is a recommendation versus an enforced value.

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, zero filler, with the returned data front-loaded and the operational advice second. Every clause carries information an agent can act on.

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

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

With no output schema, the description carries the burden of telling the agent what it returns, and it does so by enumerating slot, epoch, block height and priority fee. Minor gaps remain — no units or format for the priority fee, and no note on staleness or refresh interval.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The description correctly implies a parameterless call by making no mention of inputs.

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 concrete resource ('Current Solana slot, epoch, block height and recommended priority fee'), so an agent knows exactly what comes back without opening a schema. It stops short of differentiating itself from the sibling solana_rpc, which could plausibly also return chain-level data.

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

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

Gives an explicit usage context — 'cheap orientation call', 'anchor timestamps', 'confirm the RPC is healthy' — which tells the agent when this is the right first step. It never states when not to use it or points at solana_rpc as the alternative for deeper chain queries.

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 openWorld, so the safety profile is covered. The description adds analytic behavior the agent cannot get elsewhere: the specific heuristics run and the 0-100 link-strength output, which matters because there is no output schema. No note on cost/latency from sampling, which keeps it from 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 the core operation and following immediately with the usage trigger. The first sentence is dense with a comma-list but every clause earns its place; no filler.

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

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

For a read-only multi-signal analysis tool with rich annotations and no output schema, the description covers both what it computes and roughly what it returns (link strength per pair). The one real gap is the undocumented transferSample parameter, which an agent might otherwise ignore.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It conveys the addresses constraint ('2-10 wallets') matching minItems/maxItems, but says nothing at all about transferSample, its default, or that it trades off cost against accuracy. One of two parameters is effectively documented, the other is not.

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

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

States a specific verb + resource (compare wallets) and enumerates exactly what is computed: direct transfers, shared funders, counterparty-set Jaccard overlap, and a 0-100 link strength per pair. The 2-10 wallet scope plus 'test whether separate addresses are the same actor' cleanly separates it from single-wallet siblings like analyze_wallet and from find_cluster.

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 sentence gives a clear trigger condition ('Use to test whether separate addresses are the same actor'), which tells the agent when to reach for this tool. It stops short of naming alternatives (find_cluster, find_counterparties) or stating when-not to use it, so it is clear context without routing.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds substantial context beyond that: data sources, pool discovery, detection heuristics, and the exact categories of returned results.

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

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

The description is dense but front-loaded and purposeful, with the action first and the heuristic list afterward. It could be split for readability, but no sentence is wasted.

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

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

For a complex, multi-parameter detection tool with no output schema, the description does a good job explaining methodology and return shape. Remaining gaps are minor: time-window semantics, pool-count behavior, and any operational limits are not spelled out.

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

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

Schema coverage is 60%, so several parameters are already documented structurally. The description adds useful meaning around automatic pool discovery and recent-trade scope, but it does not explain maxPools, sinceUnix semantics, or how the trade window is bounded.

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: read a token's recent trades and score them for wash trading. It clearly distinguishes the tool from generic token analysis by naming the exact detection heuristics and output.

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 intended use is strongly implied by the name and description, but there is no explicit when-to-use versus alternatives such as analyze_token, nor any stated 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 cover read-only/idempotent safety, so the description adds real value: it enumerates what's mined (fee payers, co-signers, rent flows, funder, timing) and discloses the output (scored members with signature evidence per signal). Doesn't mention cost/latency despite sampling 50-500 transactions, but overall strong.

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

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

Three dense sentences, front-loaded with the core purpose, followed by signal enumeration and routing. No filler.

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

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

Complete for a discovery tool: purpose, signals, output shape, and alternative are all present. Only minor gaps around runtime/limits on sampled transactions remain, which are not essential to invoke 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 coverage is 100%, so baseline is 3, but the description adds semantic meaning: it explains how txSample and maxCandidates are used (transactions mined vs candidates scored in depth) and what 'discover' produces. The compute-heavy nature of larger samples is hinted but not quantified.

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

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

Specific verb (discover) and resource (wallets controlled by same actor), with an enumerated list of evidence signals (fee payer, co-signers, rent, funder, same-slot). Clearly distinct from siblings and names compare_wallets as the 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?

Explicit positive case (start from one wallet with no candidate list) and an explicit negative: 'Use compare_wallets instead when you already have the candidate list.' Routes the agent unambiguously.

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, so the safety profile is covered. The description adds the meaningful behavioral fact that results are computed over a bounded "transfer sample" rather than the full history, which is a real caveat an agent should know. It does not address pagination or result shape, but the sampling disclosure is substantive 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?

Two sentences with zero filler: the first front-loads what is computed and how it is broken down, the second gives the motivating use case. Every clause 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?

With no output schema and 17% parameter coverage, the description does well on core behavior and sampling but leaves gaps: how "top" limits results, what sinceUnix filters, and whether the sample bound makes output approximate in a way the agent should caveat. Adequate but not fully complete for a 6-parameter analytic 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 only 17% (just the address field), so the description must carry the load and it partially does: "transfer sample" maps to transferSample, "inbound/outbound" to direction, and "per-mint volume" to mint. It says nothing about top, sinceUnix, or the ranking/limit semantics, leaving real gaps.

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 with unusual precision: it ranks every address a wallet transacted with, split by inbound/outbound count and per-mint volume, plus first/last contact. An agent can tell what it produces. However, it never names a sibling (e.g., analyze_wallet, trace_funds, find_cluster), so the boundary against adjacent tools 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?

"Use to spot the funder, the sink, or the one address a wallet keeps cycling with" gives intent-level guidance that implies the analytic scenarios this tool serves. It offers no explicit when-not condition and no named alternative, so an agent choosing between this and trace_funds or analyze_wallet gets only implied direction.

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, so safety is covered; the description adds value beyond that by naming the supported bridge protocols and the fields returned per crossing. It does not disclose cost/latency of scanning up to 1000 recent transactions or what happens when a bridge is unsupported, but the behavioral profile is otherwise well communicated.

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 outcome and the supported bridges, followed by input modes and a sibling pointer — three dense sentences with no filler. The final sentence about trace_funds is slightly terse in a way that creates ambiguity, 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?

No output schema exists, and the description compensates by enumerating exactly what each crossing yields, which is the key missing information. Combined with named protocols and dual input modes, an agent has enough to call it correctly; only the fallback behavior for unrecognized bridges or empty scans 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 coverage is 75%, so the schema documents most fields; the description adds meaning the schema does not, namely that signatures and address are alternative entry modes (one direct lookups, one history scan). The case parameter is only explained in the schema, and mutual exclusivity is implied rather than stated, keeping this below a 5.

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

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

States a specific verb and resource: resolve cross-chain destination/source of funds through named bridges (Wormhole, deBridge, Mayan, Circle CCTP), and enumerates the returned facts (other chain, recipient address, amounts, other-chain tx hash). It explicitly distinguishes itself from trace_funds, which 'already resolves the crossings it meets', so an agent can route between the two without opening schemas.

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

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

Gives clear invocation modes: pass signatures, or pass an address to scan recent history for bridge activity, and covers both directions (left Solana / arrived on Solana). The exclusion relative to trace_funds is stated but ambiguously phrased, leaving the agent to infer which tool to prefer for a crossing already encountered inside a trace.

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/openWorld/idempotent, so the safety profile is covered. The description adds the shape of returned data and hints at raw-vs-parsed output, but omits practical behavior such as what happens for non-existent accounts and the 100-address batch 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?

Two tight sentences, front-loaded with the return payload and followed by the routing cue. No filler, no repetition of the title, and every clause carries information.

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

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

For a 3-parameter tool with no output schema and 0% schema description coverage, the description covers purpose and output fields but leaves parameter semantics (encoding, commitment, batch size) and missing-account behavior unexplained. Adequate but with clear gaps.

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

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

Schema description coverage is 0%: encoding and commitment enums have no documented semantics in the schema. The description's 'raw + parsed' phrase loosely maps to the encoding option but does not explain jsonParsed vs base64, commitment levels, or the batched addresses array, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('raw + parsed on-chain account state for any address') and enumerates the returned fields (lamports, owning program, executable flag, parsed data). This clearly separates it from transaction- and wallet-analytics siblings, though it never names an alternative to distinguish against.

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 this to tell a wallet from a PDA, a mint or a program' gives a genuine use case, so usage is implied rather than absent. However, there is no when-not guidance and no mention of siblings like solana_rpc or get_balances that could retrieve overlapping state.

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 genuine context beyond that: result ordering (oldest to newest) and the indexing scope constraint. It does not mention pagination behavior, though the page/limit params imply it.

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 tight sentences: scope first, use case second, exclusions third. Front-loaded and no filler.

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

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

With no output schema and annotations covering safety, the definition is nearly self-sufficient for selection and invocation. The one gap is pagination/result-size behavior for a list tool with page/limit, which is left entirely to convention.

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

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

Schema coverage is only 33% (only assetId is described, as 'Base58 Solana address'), and page/limit are undocumented in both schema and description. The description does add meaning to assetId by defining the asset class as a COMPRESSED NFT / Bubblegum tree asset, which is more than the schema gives, but it does not compensate for the undocumented pagination params.

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 (get) and resource (activity) scoped precisely to COMPRESSED NFTs / Bubblegum tree assets, and explicitly names what it is not (fungible mints, standard NFTs). An agent can distinguish it from get_transaction_history and get_transfers without opening any schema.

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

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

Gives an explicit when-to-use ('reconstruct a cNFT's mint-and-sale chain of custody') and explicit exclusions with named alternatives ('Fungible mints and standard NFTs are not indexed here — use get_transaction_history or get_transfers for those'). This is textbook routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds genuine value by enumerating the returned content (metadata, authorities, creators, royalties, price) and asset classes covered. It does not mention pagination behavior or cost/rate limits, so it stays at a solid 3 rather than 4.

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

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

A single dense sentence front-loads the standard and the primary access pattern, then enumerates coverage and returned fields. No filler, though the field/asset enumeration is crammed into the same sentence and could be separated for readability.

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

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

With 5 parameters, 40% schema coverage, and no output schema, the description should carry more of the load. It covers asset classes and returned fields adequately but leaves three of five modes and pagination semantics (page/limit defaults, max 1000) undocumented. Adequate but with clear gaps for a tool of this breadth.

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

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

Schema description coverage is only 40%, so the description is expected to compensate, and it partially does: it maps 'by mint' to byId and 'by owner' to byOwner. But byCreator, byAuthority and byCollection modes are unexplained in both schema and description, and onlyVerified is only documented in the schema. Partial compensation justifies a 3.

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 (lookup) and resource (digital asset) and names the standard ('DAS') and the two dominant access paths (by mint, by owner). It is distinguishable from the sibling search_assets by being a direct lookup rather than a search. It falls short of 5 because it does not acknowledge that five modes are supported, listing only two.

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 by contrasting 'one asset by mint' vs 'every asset held by an owner', which maps loosely to byId vs byOwner. However, it never states when to prefer this tool over search_assets, analyze_token, or get_token_holders, and gives no exclusions or prerequisites. Usage is implied, not 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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds a real behavioral nuance: USD value is only present where Helius prices the token, which warns the agent about partial output completeness. It does not mention rate limits or pricing coverage gaps beyond that.

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, no waste, with the core capability front-loaded and the usage trigger second. Every clause 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 read-only tool with fully documented params and no output schema, this covers what is returned (balances plus optional USD value) and when to call it. It could note response shape or the 20-wallet cap, which is left entirely to 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% and all three parameters (addresses, limit, includeZero) are documented in-schema, so baseline is 3. The description only implies multi-wallet support via 'one or more wallets' and adds no syntax, format, or default 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: SOL and SPL token balances for one or more wallets, plus USD valuation. This is distinguishable from balance-adjacent siblings like get_assets or analyze_wallet because it names the exact asset classes and the multi-wallet 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?

Explicitly says to use this 'before any transfer or portfolio question,' giving clear positive context. It stops short of naming a specific alternative or an exclusion, so it falls just short of a 5.

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

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

Annotations already declare read-only, idempotent, open-world. The description adds the important nuance that results include a per-mint net-position summary and can be scoped by includeTrades, plus the normalization framing. But it doesn't mention pagination/resume behavior or rate/scan limits, which matter for a history scan. Modest value above 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?

Two tight sentences: first defines return content, second states use cases. Front-loaded and no filler, though the use-case sentence is somewhat generic marketing framing rather than operational guidance.

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

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

No output schema, so the description's enumeration of return fields is useful and partially compensates. But pagination semantics (resumeBeforeSignature) and the meaning of the per-mint summary are not fully specified for an agent that must resume scans. Adequate but with clear gaps.

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

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

Schema coverage is 80%, so the schema mostly carries parameter meaning. The description clarifies the output shape (trades vs. summary) that affects how includeTrades is used, but doesn't explain limit, resumeBeforeSignature, or source beyond schema. Baseline 3 is appropriate.

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

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

Specific verb+resource (DEX swap history for a wallet) and it enumerates exactly what's returned: sold, bought, venue and fee per trade, plus per-mint net position. Clearly distinct from siblings like get_transfers or get_transactions which return raw transfers/txs rather than normalized swaps.

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

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

Explicit use cases named: trading behaviour, wash-trading, PnL groundwork. But it doesn't warn against alternatives, e.g. that wallet_pnl or get_transfers exist, so an agent isn't told when to pick those instead. Clear context without exclusions.

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

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

Annotations already declare safe read semantics (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower; the description adds that results are paginated and that each entry carries owner and balance. It does not address auth requirements, rate limits, or how far back the enumeration goes, so it stops short of 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, zero filler, with the core purpose front-loaded ahead of the alternative-tool routing hint.

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

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

With no output schema, the description usefully compensates by naming the returned fields (owner, balance) and the pagination model. It is close to complete for a 4-param read tool, though cursor mechanics remain unexplained.

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

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

Schema coverage is 50%: mint and minAmountRaw are documented in the schema, but limit and cursor are bare. The description's 'paginated' wording gestures at the cursor/limit pair but adds no semantics for page size, ordering, or how the cursor is obtained. Baseline 3 for partially-covered params.

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

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

States a specific verb, resource and scope — 'paginated list of every token account for a mint with owner and balance' — and explicitly contrasts itself with the sibling analyze_token (top-20 only). An agent can distinguish it from the sibling without opening either schema.

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

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

Names the alternative tool (analyze_token) and the exact condition that selects this one instead: holder-distribution work beyond the top-20. Nothing is left to inference about when to reach for this tool.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered. The description adds genuine behavioral context beyond that: default signature-level return vs full transactions, and cursor-based pagination for iterating large result sets. It stops short of stating limits or 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?

Two tight sentences, front-loaded with the core capability followed immediately by the routing condition. No filler.

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

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

For a read-only history tool with full annotation coverage and no output schema, the description supplies purpose, filters, pagination model and sibling differentiation. Minor gaps remain around result shape and the unused 'slot' term, but nothing blocks correct invocation.

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

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

Schema description coverage is only 25% (address and full), so the description must carry the rest. It does imply the time filters ('slot/time'), status filter and cursor pagination, but says nothing about limit, sortOrder, or the default limit of 100, and 'slot' does not map to any parameter in the schema.

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

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

States a specific verb+resource ('Signature-level history for an address') plus its filter and pagination capabilities, and explicitly contrasts itself with transfers, which separates it from the get_transfers sibling without opening either schema.

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

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

Gives a clear when-to-use condition ('coverage of every transaction touching an address, not just transfers'), which excludes the transfer-only sibling. It does not address the very similar-sounding get_transactions sibling, leaving one routing ambiguity.

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 real value by disclosing the shape of the payload (logs, inner instructions, compute units, balances). It stops short of noting cost/rate limits or the heaviness of a raw fetch, which matters for a tool meant to be used sparingly.

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

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

Two tight sentences with the content summary front-loaded and the usage constraint second. Every clause carries information; nothing is padding.

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

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

With no output schema, the field list usefully describes what comes back, and the when-to-use rule is complete. The remaining gap is parameter guidance (commitment semantics), which an agent needs to invoke the tool correctly.

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

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

Schema description coverage is 0% and none of the three parameters are explained: 'commitment' (with its confirmed/finalized enum) and 'includeLogs' are never addressed. The mention of 'logMessages' only loosely implies the includeLogs default and adds no guidance on commitment levels, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Full raw jsonParsed transaction') and enumerates the distinguishing payload contents (logMessages, inner instructions, compute units, pre/post balances). It explicitly separates itself from the sibling get_transactions, so an agent can pick between them without opening either schema.

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

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

Gives an explicit when-to-use rule ('Use only when the enhanced parse in get_transactions is not enough') plus the concrete conditions that select it (custom programs, failure debugging). Both the alternative and the exclusion criterion are named.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the 100-signature batch ceiling and the rich parsed content returned. It omits rate limits or auth requirements, but with annotations doing the safety lifting this is solid.

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 efficient sentences, front-loaded with the tool's nature and return content, with no filler. It is well-sized for the amount it needs to convey.

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

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

With no output schema, the description carries the burden of describing return values and does so thoroughly (type, protocol, description, transfers, swaps, deltas). Combined with annotations covering safety, the definition is nearly complete, though the weak commitment/signature semantics is a residual 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 description coverage is only 33%; commitment (an enum with a default) and signatures carry no schema descriptions, so the description must compensate. It only restates the 100-signature limit and never explains what commitment means or how signatures are interpreted, leaving the key parameters under-specified.

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 (parse) and resource (up to 100 transaction signatures) and enumerates exactly what the parse yields (type, source protocol, transfers, swaps, balance deltas). The phrase 'human-readable parse' plus 'primary way to understand what a transaction actually did' implicitly distinguishes it from get_transaction_raw and investigate_transaction without opening their schemas.

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

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

The description clearly positions this as the default/primary tool for understanding transaction behavior, which gives strong usage context. However it never names an alternative or an explicit when-not condition (e.g., when to prefer get_transaction_raw or investigate_transaction), leaving the routing 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description usefully adds that results are parsed rather than raw and that filtering happens server-side, which is real context. However it claims a 'slot range' filter that does not exist among the parameters and says nothing about result volume or pagination for a feed with a 1000-row cap.

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, zero filler, and the capability statement is front-loaded before the routing advice. Every clause earns its place by conveying scope, filters, or selection guidance.

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

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

With no output schema and ten parameters, the description carries more burden than it does: it never characterizes the returned transfer records (fields, USD enrichment via usdAtTime, ordering), nor mentions the limit/pagination behavior. For a feed-style tool this leaves meaningful gaps an agent would need before calling it confidently.

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 60%, and the description enumerates filter categories (counterparty, direction, mint, time) that map onto real parameters, partially compensating. It omits solMode, sortOrder, usdAtTime and limit entirely, and advertises a 'slot range' filter with no corresponding parameter, which is mildly misleading about what can actually be filtered.

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

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

States a specific resource and scope: a parsed SOL + SPL transfer feed for a single wallet, with the filter dimensions enumerated. It distinguishes itself from raw-signature walking, but never names the concrete sibling it supersedes (e.g. get_transactions, get_transaction_raw), so an agent must still infer the boundary from the other tool's schema.

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

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

Gives a clear selection rule: 'the fastest primitive for fund-movement questions — prefer it over walking signatures.' That is an actionable when-to-use signal with a stated alternative approach. It stops short of a when-not condition or naming a sibling tool, so it is short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds genuinely new context: label provenance, per-label confidence, API-key-dependent Helius lookups, and the deposit-sweep heuristic. It still does not state what happens when labels are absent or how confident-but-conflicting labels are resolved, so it goes beyond annotations without fully covering 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?

The core purpose is front-loaded in the first clause, and the remaining enumeration of label sources is dense but each item is informative. It is a single long sentence that could be split for scannability, but there is little 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?

There is no output schema, and the description does address return content by noting that each label carries its source and confidence. For a two-parameter read-only lookup this is close to sufficient; the main remaining gap is that the address-list parameter and its limits are unexplained anywhere in the description.

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

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

With only 50% schema coverage, the description should compensate, and it does so only for checkDeposits by explaining what the deposit-address sweep check detects. The required 'addresses' parameter is left entirely to the schema, with no mention of the 50-address cap, format, or whether mixed/batch input is expected, so a significant gap remains.

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

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

The description opens with a specific question the tool answers ('Who is behind these Solana addresses') and enumerates the label sources it returns, so the agent knows this is an address-attribution/enrichment tool. It does not, however, explicitly distinguish itself from nearby siblings such as analyze_wallet or find_counterparties, leaving that boundary 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 only implied: you call it when you need to know who controls a set of addresses. The mention that Helius identity is available 'when the API key has access' is a useful conditional, but there is no statement of when to prefer this over analyze_wallet or trace_funds, and no 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 readOnly, idempotent, non-destructive, and openWorld. The description adds real behavioral context: it implicitly runs analyze_token per mint and profiles the fee payer, signaling an expensive multi-step analysis rather than a single lookup. It omits cost/latency caveats, so not 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 the analysis scope and ending with the usage trigger. Dense but every clause earns its place; the feature list is a touch run-on but not 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?

With no output schema, the description carries the return-value burden and does so at a high level by naming the four analysis components. Combined with annotations covering safety and partial param coverage, an agent has enough to invoke it correctly, though the exact response shape and cost are unspecified.

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 low (33%), so the description must compensate, and it does: 'every mint involved screened for rug risk' and 'a profile of the fee payer' map directly to the screenMints and profileFeePayer toggles. The signature param is self-evident, so the main ambiguity is resolved.

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 ('Deep dive on one signature') and enumerates concrete outputs: enhanced parse, net SOL/token delta per account, mint rug screening, and fee-payer profiling. This clearly distinguishes it from raw/list siblings like get_transaction_raw and get_transactions.

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 when a single transaction is the starting point of an investigation' gives a clear triggering condition. It does not name a cheaper alternative (e.g. get_transaction_raw) or say when NOT to use it, so it stops short of full when/when-not guidance.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, openWorld, non-destructive), lowering the disclosure bar. The description adds use-case framing but says nothing about pagination, result volume, or cost despite an 11-parameter query surface, so it contributes only modestly beyond structured fields.

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

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

Two sentences, purpose first then use cases, with no redundant restatement of the title. 'Flexible' is mild filler, but the sentence earns its place by mapping filters to real queries.

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 an 11-parameter tool with no output schema and no parameter descriptions, the description is under-specified: it doesn't explain pagination defaults (page 1, limit 100), result shape, or the boolean filters. Annotations cover the safety story, but query mechanics remain undocumented.

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

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

Schema description coverage is 0% across 11 parameters, so the description carries the explanatory burden. It names owner, creator, collection, compression, and token type, but omits burnt, frozen, creatorVerified, authorityAddress, and the page/limit pagination controls, leaving roughly half the surface uninterpreted.

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 (query) and resource (DAS assets) and enumerates the filter dimensions: owner, creator, collection, compression state, token type. It is clear what the tool does, but it never names or differentiates itself from close siblings like get_assets or get_asset_activity, so the agent must infer 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?

Three concrete scenarios are given (a scammer's mints, a collection's supply, every token a wallet created), which tells the agent the kind of question this tool answers. No when-not conditions or explicit alternative tools are named, so the routing against get_assets/get_token_holders is left to inference.

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

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

Annotations already establish that this is a safe, read-only, idempotent, non-destructive call, so the description need not repeat that. It adds value by disclosing that the payload covers retries and adaptive rate-limit state, indicating the server may be throttling itself, which is behavior an agent could not infer from annotations alone.

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 compact sentences: the first names and enumerates the metrics, the second states the diagnostic use. No filler and no repetition of the title.

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?

There is no output schema, but the description effectively previews the return contents by listing the metric families, and the absence of parameters removes the need for input guidance. A note on the shape of the response (e.g. counters vs. gauges) would make it 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?

With zero parameters there is nothing for the description to clarify, so the baseline of 4 applies. Nothing in the text misleads about inputs.

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: 'coin-scout transport stats', then enumerates the metrics (HTTP requests, batch compression, retries, cache hit rate, adaptive rate-limit state). This is clearly the server's own transport telemetry rather than blockchain data, which distinguishes it in spirit from siblings like solana_rpc and chain_status, 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?

'Use to explain slow responses or confirm caching is working' gives a concrete diagnostic trigger for calling the tool. It does not state exclusions or point to alternative tools for related questions, keeping it just short of the top score.

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 openWorld, so the safety profile is covered. The description adds real value beyond that by disclosing the forwarding allowlist (get*, is*, search*, minimumLedgerSlot, simulateTransaction), which the agent cannot infer from annotations. It stops short of saying how a rejected method surfaces (error vs. silent no-op) or whether DAS methods are subject to the same prefix rules.

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 the escape-hatch framing, then the allowlist constraint. Every clause carries information; nothing is redundant with the title or annotations.

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

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

For a two-parameter, fully described escape hatch with no output schema, this is nearly complete. The only missing piece is failure behavior for disallowed methods and whether the DAS allowlist is identical to the RPC one, both minor for a pass-through 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 schema already provides method examples and explains that params is positional for RPC and an object for DAS. The description adds no additional parameter syntax or format detail, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('call any read-only Solana JSON-RPC or Helius DAS method') and frames the tool's role as an escape hatch, which immediately distinguishes it from the dedicated siblings like get_account, get_transactions, and get_assets.

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

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

Gives an explicit selection rule ('when no dedicated tool fits') and an explicit exclusion list (sendTransaction, requestAirdrop, sendBundle are rejected), so an agent knows both when to reach for this tool and what will fail.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses that native and ERC-20 transfers are read, that values are converted to USD at time of transfer, that the largest recipients are expanded, and that traversal terminates at contracts and labelled addresses. It also surfaces an operational prerequisite — Ethereum works keyless via Blockscout while all other chains need ETHERSCAN_API_KEY — which is exactly the kind of environment detail annotations cannot carry.

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

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

Front-loaded with the core action, then usage context, behavioral traits, chains, and the API-key caveat — a logical order with no filler sentences. The long chain enumeration is dense but earns its place by pairing with the keyless-vs-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?

For a five-parameter read-only tracing tool with no output schema, the description covers inputs conceptually, chain support, credential requirements, and termination behavior. The remaining gap is the result shape — an agent is not told what the trace output looks like (e.g. a graph, per-hop lists, or USD totals) — which matters slightly more given there is no output 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 only 40%, and hops, branchFactor, and sinceUnix have no descriptions in the schema. The description partially compensates by conveying the traversal model (forward following, expansion of largest recipients, stopping conditions), which gives conceptual meaning to hops and branchFactor, but it never names them and says nothing about sinceUnix as a time window.

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 — follow funds forward from an address on an EVM chain — and positions itself against siblings by naming trace_funds and follow_bridge as the tools whose output typically feeds it. It also enumerates the supported chains, so an agent can tell immediately whether the tool applies.

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

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

Gives clear usage context: it is usually run on the destination address of a bridge crossing discovered by trace_funds or follow_bridge, which implicitly routes multi-chain tracing elsewhere. It does not spell out an explicit when-not-to-use case (e.g. Solana or non-EVM), though the chain list partially covers that by enumeration.

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 it as a read-only, idempotent, open-world operation. The description adds genuine context beyond that: the BFS traversal strategy, the default forward direction, and the fact that a case file and graph outputs (nodes, weighted edges, terminal sinks, circular flows) come back. It does not disclose runtime cost or result-size limits, which for a multi-hop graph query would be valuable.

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

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

Three sentences, each doing distinct work: what the traversal is, what it returns, and why it matters. The direction semantics are front-loaded and there is no filler.

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

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

With no output schema, the description usefully names the return shape, and it frames a 14-parameter graph tool well enough to invoke. The remaining gap is routing versus trace_evm and follow_bridge, which an agent facing near-duplicate fund-following siblings would benefit from.

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 64% across 14 parameters, and the richer parameters (branchFactor, followEvm, followBridges, minAmount) already carry their own descriptions. The prose only echoes hops and direction, both of which are fully documented in the schema, so it adds marginal meaning beyond structured fields. Baseline 3 is appropriate.

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

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

States a specific resource and operation: a breadth-first fund-flow graph from a wallet, with forward/backward direction and hop depth. An agent can immediately grasp what it produces. It stops short of distinguishing itself from the sibling trace_evm or follow_bridge, so it is clear but not sibling-differentiated.

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 'core tool for following stolen or laundered funds' implies the investigative context in which it should be picked, but there is no explicit when-not-to-use or alternative routing. With trace_evm and follow_bridge in the sibling list, the definition should say which chain or crossing case belongs to whom; it leaves that 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 read-only, idempotent, non-destructive, but the description adds real behavioral depth the annotations cannot: average-cost basis, USD valuation at swap time, and the special handling of unmatched sales. It does not disclose sampling limits or what swapLimit/top actually bound, so it is not exhaustive.

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

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

The core definition is front-loaded in the first clause, with edge-case behavior and field names following in order of importance. Dense but every sentence carries information; only the final 'check those for insiders' aside borders on redundant.

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

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

With no output schema, the description does the work of naming key return fields (unmatchedProceedsUsd, realizedPnlIfUnboughtFreeUsd, receivedWithoutSwap) and their interpretation, which is exactly what an agent needs. It leaves the meaning of top and swapLimit unexplained, a minor gap for a 4-parameter 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 50%: mint and address are documented in the schema, while top and swapLimit are not. The description usefully explains mint's downstream effect (receivedWithoutSwap), but says nothing about top or swapLimit, so it only partially compensates for the coverage gap.

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

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

States a specific verb+resource ('Realized and unrealized PnL per token from a wallet's DEX swaps') plus the valuation basis and the concrete questions it answers. It is clearly distinguishable from siblings like get_swaps (raw swaps) or analyze_wallet (broader profiling).

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 clear use contexts ('did this wallet profit from the rug', sniper/insider profit, overall trading results) and directs the agent to check unmatchedProceedsUsd for insiders when sales have no matching buy. It never names an alternative tool or states when not to use this one, so it stops short of full routing guidance.

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