wallet-tracker

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the batch ceiling (100) and chain/wallet-type constraints, but does not disclose cost, rate limits, or any behavior beyond what annotations plus schema already convey.

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

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

Front-loaded with the scope statement, and the parameter list is compact. The three-line param block largely duplicates the schema enums verbatim, which is mildly wasteful but not bloated.

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

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

An output schema exists, so return values need not be explained, and the description covers batch size, supported chains, and wallet types. The remaining gap is that 'statistics' is never named, and no sibling is referenced for contrast.

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

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

Schema description coverage is 100% and the schema is in fact richer than the description (it documents which chains support which wallet types, and notes rh is Robinhood Chain). The description's parameter list is essentially a restatement of the schema, adding no new semantics.

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

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

The description opens with 'Statistics for up to 100 tokens in a single request', which conveys the resource (tokens) and batching scope but uses a noun phrase rather than a clear verb and never specifies which statistics are returned. It is distinguishable from single-token siblings only by the 'up to 100' batch limit, and it does not differentiate itself from compare_wallets by name.

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

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

It gives concrete usage contexts: 'Use for shortlists, or to follow up on the most-traded analytics view.' This tells the agent when the tool is appropriate, though it does not name a specific sibling (e.g. get_token_stats) as the non-batch alternative.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description contributes a cost-model trait (much cheaper than repeated get_wallet_tracker calls), which is genuinely useful behavior beyond structured fields, though it says nothing about output volume or trimming 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 opening paragraph is tight and front-loaded, but the four-line parameter legend duplicates structured schema content that the agent already receives, so roughly half the text does not earn 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 an output schema present, return-value explanation is unnecessary, and the description covers batching scope, cost rationale, and when to use it. Nothing critical is missing, though output volume/trimming expectations are only hinted at in the schema.

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

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

Schema description coverage is 100%, so per the rubric the baseline is 3. The description's parameter legend (blockchain/addresses/wallet_type/period) largely repeats what the schema already documents rather than adding syntax, format, or constraint detail.

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 operation (batch statistics for up to 100 wallets in one request) with a clear resource and scope, and explicitly distinguishes itself from the sibling get_wallet_tracker by naming it as the costlier 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?

Gives explicit when-to-use conditions ('user names several wallets', 'follow up on a leaderboard') and names the alternative it replaces, so the agent can route correctly without opening schemas.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the rest and does so well: it discloses the detection method, the confidence-scored output with its evidence (matching fees, block index, adjacency), and the Solana/Jito scope limit. It doesn't mention latency, rate limits, or coverage caveats (e.g., tokens with no Jito bundles).

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?

Purpose and routing guidance are front-loaded and the paragraph is tight overall. Minor redundancy: the Solana-only constraint is stated twice ('Solana only, because it depends on Jito bundles') and the mint line duplicates the schema.

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

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

With an output schema present, the description needn't enumerate return fields, yet it still summarizes what comes back (bundle, confidence, evidence). Purpose, scope, and trigger conditions are all covered for a one-parameter read-only tool.

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

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

Schema description coverage is 100% and the schema already documents the single 'mint' parameter identically. The trailing 'mint: the Solana token mint address' line merely restates it, adding no format or syntax 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 (check/detect) and resource (KOL wallets buying a Solana token via Jito bundles with side wallets), plus the consequence it uncovers (hidden position size). No sibling tool covers bundle detection, so the agent can distinguish it immediately.

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 names the triggering user questions (bundled launch, insider-heavy, sniped, manipulated) and states a hard applicability constraint (Solana only, due to the Jito dependency). It stops short of naming alternatives or when-not-to-use, but the sibling set has no overlapping tool, so this is close to complete.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that the description surfaces a real capability constraint the agent must know: wallet_type availability varies by chain (solana has kol/smart/whale, bnb/base/rh have kol and smart, eth has kol only), and the window is hard-capped at 24 hours. It does not discuss auth or rate limits, but the value added over the annotations is substantive.

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

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

Purpose leads, then a compact parameter listing — no filler sentences and every line carries information. The 24-hour cap, the single-token scope and the defaults are all front-loaded where an agent will see them.

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 4 parameters, one required, full schema coverage and an output schema present, the description need not explain return values. It supplies purpose, when-to-use and the chain/wallet_type constraints, leaving only minor gaps such as pagination or whether counts are 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 100%, so the schema already documents every parameter including defaults, ranges and the per-chain wallet_type matrix. The description largely restates the same parameter list, adding only the shorthand enumeration of chains and types — marginal value over structured data, so baseline 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?

The description states a specific measurement ('how many trades happened and how much value moved over a window of up to 24 hours, plus how many distinct wallets') — verb, metric set and resource are all concrete. It also explicitly positions itself against trade-level tooling ('rather than for the individual trades'), so an agent can separate it from get_recent_trades without reading 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?

It gives a clear selection rule: use it to gauge how busy a market or a single token is, not to inspect individual trades. That is a genuine when/when-not pair, though it never names the concrete alternative tool (get_recent_trades) the way a 5 would.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the aggregate-scope framing but no behavioral context such as rate limits, data freshness, or trimming behavior (the trimming warning lives only in the schema). With annotations carrying the burden and an output schema present, this is adequate but thin.

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

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

The purpose sentence is well front-loaded, but the following four lines duplicate the parameter enumerations that the schema already provides verbatim, so a meaningful portion of the text does not earn its place. Structure is orderly but redundant.

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

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

An output schema exists, so return values need not be explained, and the schema fully documents parameters. The description covers the modes and usage scope, leaving it complete enough for an agent to select and call it. Only the naming of alternative tools is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, and it does so more richly than the description (context-window trimming warnings for limit/period, per-chain wallet availability for blockchain). The description merely restates the option lists with defaults and adds no syntax or format detail beyond the schema. Baseline 3 is correct.

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

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

The opening sentence names the resource ('tracked wallets') and the four aggregate modes with a specific meaning for each (volume_trend, most_traded, win_rate, top_performers). It also scopes itself against siblings ('overall picture rather than one wallet or token'), implicitly distinguishing it from get_wallet_tracker/compare_wallets. It stops short of naming the alternative tools, so it is clear but not fully 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?

'Use for the overall picture rather than one wallet or token' gives an implied when-to-use boundary. However it never names the alternative tools (compare_wallets, get_wallet_tracker, get_leaderboard) or states when NOT to use this tool. The guidance is present but 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds that the payload includes coverage metadata (chains, wallet types, periods, limits, per-chain wallet counts). It does not discuss rate limits or freshness of the coverage data, but for a read-only diagnostic this is solid context beyond the annotations.

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

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

Two sentences, no filler, with the coverage scope front-loaded and the usage hint immediately after. Slightly list-like formatting rather than a crisp verb phrase, but nothing is wasted.

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

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

An output schema exists so return values need not be explained, and both the content scope and the diagnostic use case are stated. For a zero-parameter status tool this is nearly complete; only freshness/staleness of the coverage snapshot is unaddressed.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate and it does not misstate any input.

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

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

States a concrete verb+resource (service health and current coverage) and enumerates the scope it reports: chains, wallet types, periods, limits, and wallets tracked per chain. It is clear what the tool answers, though it does not explicitly distinguish itself from siblings like get_started or get_analytics.

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 concrete triggering condition: 'Useful when a query returns nothing and it is unclear whether the data exists at all.' That is a real when-to-use cue, but it names no alternatives or contrasting conditions (e.g. when data absence is expected).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds domain constraints (whale is Solana-only, eth is kol-only) but nothing about result size limits, trimming, or freshness of rankings – and the trimming behavior is only mentioned in the schema, not the description.

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?

Purpose and examples come first, followed by a compact parameter list. It is well front-loaded, though the parameter bullets duplicate what the schema already states, which slightly dilutes the value of the text.

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

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

With full schema coverage, an output schema, and read-only annotations, the description supplies enough to call the tool correctly. The main remaining gap is routing guidance relative to the many sibling wallet/token tools.

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

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

Schema description coverage is 100% and the schema already documents every parameter's meaning, defaults, and bounds (limit max 200, period windows, blockchain list). The description largely restates this, adding only the cross-parameter validity constraint, so the baseline of 3 applies.

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

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

States a specific resource and ranking behavior: 'Top tracked wallets ranked by performance for a chain, wallet type and period.' This is clearly distinct from siblings like list_wallets (enumeration) or compare_wallets (pairwise comparison), and the concrete query examples ('best Solana KOLs today') pin down the intent.

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

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

Provides real usage contexts via example queries and enumerates the valid domains for each filter, which helps an agent recognize appropriate calls. However it never states when NOT to use it or names a competing sibling such as list_wallets or get_wallet_tracker, so routing guidance is incomplete.

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

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

Annotations only cover read-only/open-world, so the description usefully adds that the metric is *realized* (not unrealized), that granularity is daily and monthly, and that history is scoped to the wallet's tracked range. It omits auth, rate limits and pagination, but adds real context beyond the annotations.

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

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

The core sentence is front-loaded and tight, but the two trailing lines that re-list blockchain values and describe the address merely duplicate schema content that is already fully documented.

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

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

With an output schema present, return values need not be explained, and the description adequately conveys what the tool produces and when to reach for it for a simple two-parameter read tool. Only the absence of any alternative routing keeps it from a 5.

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

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

Schema description coverage is 100% and the schema defines both parameters in more detail than the description (including chain-specific wallet-type and Base58 vs 0x addressing rules). The description's restatement of the blockchain list and address adds nothing new, so baseline 3 applies.

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

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

The description names a specific metric and resource: daily and monthly realized PnL for a wallet over its tracked history. That is clearly distinct from siblings like get_token_stats or get_wallet_history, though no sibling is named explicitly.

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

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

"Use for when a wallet made or lost money, and for spotting streaks" gives a genuine use case, but there is no when-not guidance and no alternative tool named for related PnL or performance questions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and open-world profile is covered. The description's added value is the real-time/freshness characteristic ('what tracked wallets are buying and selling right now') and the 60-minute recency ceiling, but it says nothing about rate limits, latency, or result trimming beyond what the schema already notes.

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?

Purpose is front-loaded in the first sentence and the parameter block is compact and scannable. The per-parameter lines mostly duplicate the schema, which is slightly wasteful but keeps the definition self-contained for an agent reading only the description.

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

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

An output schema exists, so return values need no explanation, and annotations cover the read-only/open-world profile. Combined with full schema coverage, the description supplies enough for correct invocation, missing only guidance on sibling selection and behavior under load.

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

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

Schema description coverage is 100%, so every parameter is already documented, including enum-like values for blockchain and wallet_type and the minutes/limit bounds. The description's parameter block largely restates the schema, adding no format, precedence, or interaction detail beyond it.

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

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

States a specific verb and resource — a live feed of tracked-wallet buys and sells — and pins the scope with 'right now' and 'across every token or filtered to one'. That real-time framing cleanly separates it from historical siblings like get_wallet_history and get_token_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?

Gives a concrete invocation context ('what are KOLs buying at the moment') plus the choice between all-token and single-token scope, which maps to the mint parameter. It stops short of naming a competing sibling or stating when not to use this instead of the history/transaction tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds only parameter values and defaults, with no extra behavioral context such as result trimming behavior (which the schema mentions) or how history is aggregated.

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

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

The purpose sentence is front-loaded and each parameter line is terse. However, the parameter block largely duplicates the schema, so a few lines do not earn their place independently.

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

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

An output schema exists, so return values need not be explained. With the purpose, usage context, and all five parameters covered, an agent has everything needed 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 100%, so the schema already documents every parameter including valid values and defaults. The description restates the same enum-like values without adding new syntax, constraints, or interpretation beyond the schema.

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

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

The opening line states a specific verb+resource: retrieving past signals to check whether a kind of signal has worked historically. It implicitly distinguishes itself from the live get_signals sibling via 'before acting on a live one', though it never names that sibling 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?

It gives a clear usage context (validating historical performance before acting on a live signal), which is more than implied. It stops short of naming alternatives or explicit exclusions, so it lands below 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 only declare readOnlyHint and openWorldHint. The description adds material behavior the annotations cannot: the endpoint reports more results but returns no usable cursor, so the caller must raise limit instead of paginating, plus the eth unavailability caveat. That is exactly the kind of non-obvious operational detail that prevents failed calls.

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 prose is front-loaded and the pagination warning is well placed, but the trailing parameter list duplicates field documentation already fully present in the schema, which is dead weight for an agent that reads both.

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

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

With an output schema present, return values need not be explained. The description still covers the pagination limitation, chain-level feature availability, mode semantics, and sensible limit advice, leaving nothing an agent needs in order to call this correctly.

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

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

Schema description coverage is 100% and the schema already documents defaults, ranges, mode meanings, and chain/wallet-type compatibility. The description's parameter block largely restates those entries without adding format or edge-case guidance, so it meets the baseline but does not beat it.

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

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

The opening sentence states a specific resource and scope: tokens where multiple tracked wallets acted in the same window. The mode definitions ('cluster' = multiple wallets bought the same token, 'entry' = fresh positions, 'exit' = selling out) let an agent distinguish this from history- or trade-oriented siblings at a glance.

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 use case ('what should I be looking at right now') and a hard constraint (smart money signals unavailable on eth), which steers tool choice. It stops short of naming an alternative such as get_signal_history for past signals, so the when-not-to-use side is left implicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: the API works keylessly in demo mode, a free key grants 1000 requests, and this tool is the recovery step after auth/demo-limit failures.

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 most important instruction — call this first without a key — is front-loaded, and the enumeration of contents (pricing, docs, coverage) is compact. The list of covered topics is slightly padded but each item tells the agent something it can retrieve.

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

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

An output schema exists, so return values need not be described. For a zero-param onboarding tool with annotation coverage, the description supplies everything needed: what it contains, when to call it, and the error states that should route back to it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No argument syntax 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 a concrete resource — onboarding content: the keyless demo, free API key, pricing, docs and data coverage. Across a sibling set of 20 data-fetching tools, it is unmistakably the meta/onboarding entry point, so an agent can distinguish it without opening the schema.

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

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

It states exactly when to call it: 'Call this first if you do not have a key yet, or if another tool returned an auth error or demo_limit_reached.' That is a precise trigger condition plus a failure-recovery path, with no inference required.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds the sort order and the USD/market-cap enrichment, but says nothing about pagination, freshness, or whether 'tracked' wallets are a limited subset. With annotations carrying the safety burden, this is adequate but not rich.

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 purpose sentence followed by a compact parameter block; every line is short and scannable. The parameter list partly duplicates the schema, which slightly dilutes the value of each line, but nothing is verbose.

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

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

Output schema exists and annotations cover safety, so the description need not explain return values. It conveys operation, trigger, and constraints, leaving only minor gaps (subset of wallets tracked, freshness) that an agent could infer. Complete enough for 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 100%, so the baseline is 3; the schema already documents each parameter including the chain-specific wallet_type availability and the limit trimming behavior. The description's per-parameter lines ('wallet_type: restrict to kol, smart or whale', 'limit: how many holders') largely restate the schema rather than adding new meaning.

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

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

Specific verb+resource ('tracked wallets holding a token'), with clear output semantics (sorted by balance, market cap and price in USD) and chain scope. It explicitly distinguishes itself from a trading-history tool ('who is still holding, rather than who ever traded it'), so an agent can separate it from get_token_transactions/get_recent_trades without opening a schema.

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

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

Gives a clear usage trigger ('when the user asks who is still holding') and a contrast case ('rather than who ever traded it'). It stops short of naming the sibling tool that handles trades, so the routing is inferable but not fully explicit.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond them by disclosing the endpoint quirk that USD market cap returns empty even on Solana, plus the wallet_type merging behavior. It does not cover auth, rate limits, or pagination, which keeps it out of 5 territory.

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 capability summary is front-loaded and tight, and the market-cap caveat is placed before the parameter recap so the key limitation is not buried. The trailing parameter block duplicates what the schema already states, which is minor waste but keeps the definition slightly longer than necessary.

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

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

An output schema exists, so return-value documentation is not required, yet the description still gives a useful sketch of the response shape. The market-cap caveat closes the main ambiguity an agent would hit. Remaining gaps (pagination, chain-specific wallet_type constraints already in schema) are minor.

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

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

Schema description coverage is 100%, so the schema already documents blockchain, mint, and wallet_type with chain-specific wallet support. The description largely restates these (blockchain list, mint definition, wallet_type omission semantics) rather than adding new meaning, so the 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?

The first sentence names the resource (a token's trader/holder composition) and enumerates concrete outputs: KOL/smart-money/whale counts, bought vs sold, buying pressure, entries, and per-trader positions. It then frames itself as 'the main tool for "is anyone notable in this token"', which cleanly separates it from generic siblings like get_token_transactions or get_recent_trades.

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

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

It states the primary use case explicitly and routes one alternative: market cap comes back empty here, so use get_token_holders instead. That is a genuinely useful when-not/alternative signal. It stops short of covering other nearby choices (e.g. get_token_holders for pure holder lists outside the notable-wallet framing).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds result ordering (most recent first) and the default limit, but says nothing about pagination, rate limits, or truncation beyond what the schema already notes.

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?

Opening sentence is front-loaded with purpose and ordering, and the use-case line adds value. The trailing per-parameter list duplicates schema content, slightly diluting conciseness.

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

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

With an output schema present, return values need not be described; the description covers ordering, defaults, and chain/wallet-type caveats. An agent has enough to call it correctly, though exclusions vs. sibling trade-listing tools remain unstated.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, including enum-like values and the merge behavior for wallet_type. The description largely restates that, so the baseline 3 is appropriate.

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

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

States a specific verb+resource: individual buys and sells by tracked wallets in one token, most recent first. It is clear about scope (one token) and ordering, though it does not explicitly contrast with the overlapping sibling get_recent_trades.

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

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

Gives a concrete use case – reconstructing the sequence of events, e.g. whether KOLs bought before or after a price move – which tells the agent when this tool is valuable. It stops short of naming alternatives or stating when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral constraints beyond the annotations: the 30-day lookback window, the ranking criterion (overlap), and the fact that only tracked wallets are considered. It does not contradict the annotations.

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

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

The core explanation is two front-loaded sentences that earn their place. The trailing parameter legend is partially redundant given full schema coverage, but the overall definition stays short and readable.

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

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

With an output schema present, the return format need not be described here. Annotations cover the safety profile, all three parameters are documented, and the description supplies the key scoping behavior (tracked wallets, 30-day window, ranked by overlap). Complete enough for 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 coverage is 100% and the schema already contains richer parameter documentation, including chain-specific wallet-type notes and base58 vs hex address formats. The description's parameter legend repeats the schema without adding syntax or edge-case meaning, so baseline 3 is correct.

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

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

The description clearly states what the tool returns: other tracked wallets that traded the same tokens as a source wallet over the last 30 days, ranked by overlap. This distinguishes it from siblings like compare_wallets and get_wallet_tracker, though it opens with a noun phrase rather than a verb and never explicitly contrasts itself with those alternatives.

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

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

It provides an implied use case — 'finding groups that move together, which can indicate coordination' — but gives no explicit when-to-use/when-not-to-use guidance and does not name or route to alternative sibling tools.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description only needs to add traits the annotations cannot. It does: pagination lives inside the payload and next_cursor must be followed until null, and oversized limits get trimmed, both of which materially change how an agent should loop and size calls.

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 purpose sentence, a short pagination caveat, then a compact parameter glossary; every line is scannable and nothing rambles. Modest redundancy with the 100%-covered schema parameters slightly dilutes the value of the parameter block.

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

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

With an output schema present, return values needn't be explained, and the description covers purpose, historical-vs-current scope, and the non-obvious cursor-in-payload pagination loop. The only genuine gap is the inconsistent limit range, which leaves the agent with contradictory guidance on a parameter it must set.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description largely restates the schema's blockchain/address/cursor definitions. Worse, it states limit is '1-1000 (default 50)' while the schema caps maximum at 200, a conflicting bound that could mislead an agent into requesting an out-of-range value.

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 (lifetime trading history of a wallet) and enumerates the three payload components: aggregate stats, per-token overview, and individual trades. The contrast 'rather than how it is doing now' implicitly separates it from the holdings/tracker siblings, so an agent can route without opening a schema.

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

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

Explicitly frames use as historical-trade lookup versus current-state tools ('Use for what a wallet traded historically, rather than how it is doing now'), which is clear when-to-use guidance. It stops short of naming the specific alternative sibling (e.g. get_wallet_holdings), so the routing is inferred rather than explicit.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds genuinely useful behavioral context: latency ('often over a second') and the async warm-up semantics where a 'loading' flag means data is incomplete and the call should be repeated. That retry guidance is not derivable from 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?

Front-loaded with the core purpose and latency/retry notes, all of which earn their place. The trailing 'blockchain: ...' and 'address: ...' lines are redundant with the schema and slightly dilute an otherwise tight description.

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

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

With an output schema present, return values needn't be explained, and the description covers purpose, latency, and the loading-retry edge case. The only gap is the absence of explicit sibling routing, which the usage dimension already flags.

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

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

Schema description coverage is 100% and the schema entries are actually richer than the description (per-chain wallet-type breakdown, Base58 vs 0x address formats). The description's trailing parameter lines restate the schema without adding meaning, 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 and resource ('current onchain token holdings of a wallet') and immediately distinguishes it from siblings by contrasting live reads with data 'derived from tracked trades.' An agent can tell it apart from get_wallet_tracker or lookup_wallet without opening a schema.

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

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

The live-vs-derived framing implies when this tool is preferable, and the 'slower than the other wallet tools' note warns of a cost tradeoff. However, it never explicitly names an alternative or states a when-to-use condition, leaving the agent to infer the choice.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: longer periods return more data and are trimmed harder, which sets expectations about result truncation.

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

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

Front-loads the core purpose in one clause, then lists metrics, then per-parameter notes. Every line earns its place with no filler or repetition.

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

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

With an output schema present, return-value documentation is not required, and the description covers purpose, chains, and period trade-offs. It could say more about what 'trimmed' concretely means, but nothing critical to invoking the tool is missing.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema, including the same period enumerations and the rh/Robinhood Chain note. The description restates these rather than adding new semantics, so the baseline of 3 applies.

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

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

Names a specific resource (period statistics for ONE wallet) and enumerates the concrete metrics returned (realized PnL, win rate, volume, trade counts, active tokens, win-rate distribution). The 'ONE wallet' scoping and 'how is this trader doing' framing cleanly separates it from the compare_* and history/holdings 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?

Gives explicit usage context ('the main tool for how is this trader doing') and concrete period-selection guidance ('prefer the shortest period that answers it'). It does not, however, name any alternative tool or state when NOT to use it versus close siblings like get_wallet_history or get_pnl_calendar.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the classification is known. The description adds genuinely non-redundant behavior: the result set is unbounded in size (thousands) and paginated via cursor from the previous response, which is not visible in the annotations.

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

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

Purpose and the key limit constraint are front-loaded, and the trailing parameter block is terse. That block partially restates what the schema already documents, which is mild redundancy rather than bloat.

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

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

An output schema exists, so return values need no explanation. The description covers discovery scope, the size/pagination behavior, and the required limit, though it omits the chain-wallet_type compatibility rules (e.g., whale is Solana-only) that the schema does carry.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a usage directive on limit ('Always pass a limit') and compresses the valid blockchain/wallet_type values into a quick reference, slightly exceeding the schema's contribution.

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 uses a specific verb and resource ('Browse the wallets CabalSpy tracks') and scopes it by chain and wallet type, making the enumeration role clear against per-wallet siblings like lookup_wallet. It never names an alternative tool explicitly, so differentiation is functional rather than stated.

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 answer which KOLs or smart money wallets are covered at all' gives a concrete use case, and 'Always pass a limit; the full list runs into the thousands' is actionable guidance. No when-not condition or named alternative is provided, so it stops short of a full routing rule.

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?

With readOnlyHint and openWorldHint already covering the safety profile, the description adds a genuinely non-obvious behavioral caveat: on EVM chains only the first match is returned, so the reported chain may not be the intended one. That is real operational context the annotations cannot convey. It stops short of noting coverage gaps (e.g. untracked addresses) or rate limits.

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

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

Front-loads purpose, then the caveat, then the parameter — good ordering and no filler. The final line restating the address parameter is redundant given the 100%-covered schema, a minor wasted sentence.

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

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

For a single-parameter read tool with an output schema present, the description covers purpose, the entry-point usage cue, and the one behavioral gotcha. An agent has everything needed to select and call it correctly without duplicating return-value documentation.

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's own description (Base58 on Solana, 0x-hex on EVM) is more informative than the description's restatement 'the wallet address to look up'. Baseline 3 applies since the schema fully carries parameter meaning and the description adds nothing.

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 ('identify a wallet address') and enumerates exactly what is returned (name, Twitter, Telegram, wallet type, chain). Clearly separable from siblings like list_wallets and get_wallet_tracker, which enumerate or track rather than resolve a single pasted address.

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?

'Start here when a user pastes an address and asks who it is' gives an explicit trigger condition and positions the tool as the entry point. It does not name a when-not case or a sibling to prefer for other intents, but the usage context is unambiguous.

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