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 declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds the useful behavioral note that the call is "cheap" (low cost/latency) and suitable for health checks, but does not quantify or add much beyond that. With annotations carrying the safety burden, a 3 is appropriate.

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

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

Two tight sentences: the first front-loads what is returned, the second states when and why to use it. Every clause earns its place with 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 compensates by enumerating the exact returned fields (slot, epoch, block height, priority fee). For a zero-parameter read tool whose annotations cover safety, nothing needed to invoke it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies a no-argument call by listing only return values.

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

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

The description names the specific resource and its return payload: current Solana slot, epoch, block height, and recommended priority fee. This clearly separates it from transaction/account siblings. It stops short of explicitly naming an alternative sibling, so it lands 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?

"Use it to anchor timestamps and confirm the RPC is healthy" gives a concrete when-to-use condition and frames it as an orientation step. There are no explicit exclusions or named alternatives, so it is clear context without full 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 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 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/openWorld/non-destructive, so safety is covered. The description adds real value beyond them by disclosing supported protocols and the shape of the result (cross-chain hash, recipient, amounts). It omits latency/rate-limit or failure behavior for unreachable chains.

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 action, then the input modes, then the sibling routing note. 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 returned fields and both input paths, which is what an agent needs to call it correctly. It is slightly thin on what happens for unsupported chains or empty scans.

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%, near the high band where the schema does the heavy lifting. The description clarifies the two input modes (signatures vs address scan) but does not explain scanLimit's meaning or the 'case' parameter, leaving some gap the schema alone fills.

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 where funds went when they left Solana ... through Wormhole, deBridge or Mayan') and names the concrete outputs (other chain, recipient, amounts, cross-chain tx hash). It also distinguishes itself from the sibling trace_funds, so an agent can route 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 two concrete invocation modes ('Pass signatures, or an address to scan its recent history for bridge transactions') and notes that 'trace_funds already resolves the crossings it meets,' which implies when this dedicated tool is warranted. It stops short of an explicit when-not-to-use rule, so not 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/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 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered externally. The description adds the metric categories and the diagnostic intent, which is useful context beyond the annotations, but says nothing about scope (whole server vs. current session), cost, or freshness of the counters.

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 filler. The metric inventory comes first and the actionable 'use to...' guidance second, which is the right front-loading for a diagnostic tool.

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

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

There is no output schema and no parameters, so the description carries the burden of describing what comes back — and it does so by listing the five metric families. An agent knows what it will get and why to call it. Minor gap: no indication of whether the stats cover the whole service or the current session.

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; the baseline for a no-parameter tool applies. No parameter guidance is needed or missing.

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

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

The description names the specific resource ('coin-scout transport stats') and enumerates exactly which counters are exposed (HTTP requests, batch compression, retries, cache hit rate, rate-limit state). That clearly separates it from every sibling tool, which all return chain/wallet data rather than server diagnostics. It is a noun phrase rather than a verb+resource, so it stops just short of the top mark.

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 an explicit trigger: 'Use to explain slow responses or confirm caching is working.' That tells the agent when this tool is the right choice for a diagnostic question. It does not name any alternative or state when not to use it, but no sibling covers server transport stats, so the omission is minor.

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 value beyond them by disclosing that write methods are actively rejected, which is real behavioral information about 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?

Two sentences, zero waste, with the escape-hatch framing and the exclusion rule front-loaded in a single readable line.

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 generic passthrough tool with no output schema, the description covers purpose, scope, and the write-method exclusion well. It could briefly note that return shape varies by method, but nothing essential to invoking it is missing.

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

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

Schema coverage is 100%, and the schema itself explains the array-vs-object convention and gives example methods. The description adds no parameter meaning beyond the schema, 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+resource ('call any read-only Solana JSON-RPC or Helius DAS method') and frames itself as an escape hatch, which cleanly distinguishes it from the many dedicated siblings like get_account and get_balances.

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 condition ('when no dedicated tool fits') and an explicit when-not: write methods such as sendTransaction and requestAirdrop are rejected. An agent knows to prefer dedicated tools and fall back here only for uncovered methods.

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/non-destructive, so the safety bar is low. The description adds real behavioral value beyond that: breadth-first expansion, USD valuation via DefiLlama at transfer time, and resolution of bridge transactions to destination chain/address. It omits cost, latency, and result-size caps, which matter for a multi-hop graph expansion.

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, no filler. The mechanism and return shape are front-loaded before the use case, so the agent gets the what before the why.

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 13 parameters, no output schema, and mid coverage, the description does the important work of describing return contents and traversal semantics. It leaves node/edge sizing limits (maxNodesShown, maxEdgesShown, perNodeTransfers) unexplained and gives no guidance on choosing hops, which is the main tuning decision for this 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 62%, a middle band where the schema carries most parameter meaning. The description adds concept-level semantics for direction ('forwards = where money went, backwards = where money came from') and hop depth, but says nothing about branchFactor, perNodeTransfers, or the case-save parameter. Baseline 3 fits.

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 ('Breadth-first fund-flow graph from a wallet') plus scope (forwards/backwards, up to N hops), which clearly separates it from siblings like get_transfers or find_counterparties. It also enumerates what comes back (nodes, weighted edges, terminal sinks, circular flows), so an agent knows the shape of the result 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?

Names the primary use case ('following stolen or laundered funds'), which is real context, but never says when to prefer a sibling — e.g. get_transfers for a flat transfer list, follow_bridge for a single bridge hop, or analyze_wallet for general profiling. Usage is implied by the scenario rather than explicitly routed.

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.