wallet-tracker

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 the 100-token batch constraint and the default wallet_type, but does not describe what 'statistics' actually contains, rate limits, or behavior on invalid mints.

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 purpose sentence, then lists parameters compactly. Minimal waste, though the parameter list partially duplicates schema content.

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 annotations cover the safety profile. The description plus structured fields give an agent enough to call it correctly, though the nature of the returned statistics remains 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 the schema already documents all three parameters, including the blockchain list, wallet_type meaning, and defaults. The description largely restates those same enumerated values without adding syntax or format 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 resource (token statistics) and a clear scope (up to 100 tokens per request), which distinguishes it from the single-token get_token_stats sibling. However it doesn't explicitly frame the 'comparison' angle that the name implies, leaving a small gap.

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 usage contexts: 'shortlists' and following up on the most-traded analytics view. It doesn't name a specific alternative tool or list exclusions, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond that: the cost/round-trip advantage over repeated get_wallet_tracker calls, which is the main reason an agent would pick this tool. It does not mention rate limits or how results are trimmed for large requests, 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?

Front-loaded with the payoff (batch statistics for up to 100 wallets) followed by the cheaper-than alternative and then the parameters. It is appropriately short, though the trailing parameter legend duplicates information already in the schema, which is modest redundancy rather than waste.

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

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

With an output schema present, an agent does not need return-value documentation, and the annotations cover the safety profile. The description supplies purpose, trigger conditions, the strongest alternative, and every parameter name, leaving only cost limits and large-window trimming behavior undocumented in the prose.

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's parameter lines (blockchain values, address cap, wallet_type options, period options) largely restate what the schema already documents in more detail, including the enum-like value sets, and add no new syntax or format guidance.

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 operation and scope: statistics for up to 100 wallets in a single request, which is exactly the batch counterpart to the single-wallet sibling. It contrasts itself against get_wallet_tracker, but never explicitly frames the operation as a *comparison* of wallets, so the verb is slightly softer than the tool name implies.

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 the user names several wallets, or to follow up on a leaderboard" gives concrete triggering conditions and names the cheaper-alternative relationship to get_wallet_tracker. No explicit when-not or edge-case exclusions (e.g., what to do for a single wallet) are stated, so it stops 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 mark the tool as read-only and open-world. The description adds crucial operational context: callouts are a per-instance opt-in feature, returning feature_not_enabled otherwise, and an API key with a CabalSpy ID instance is required (no demo).

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

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

Front-loads the core definition and return metrics, then gives a use case and prerequisites. It is somewhat return-value heavy despite an output schema, but every sentence provides useful context and there is no filler.

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

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

For an eight-parameter analytics endpoint, the description covers purpose, scoring model, feature gating, authentication prerequisites, and intended use. With a complete schema and output schema present, no essential calling information is missing.

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

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

All eight parameters have schema descriptions, so the schema already carries syntax and ranges. The description explains the scoring concepts behind hit_x and periods but does not add parameter-level guidance beyond the schema.

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

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

Names a specific resource (best callers / leaderboard) on the user's CabalSpy ID instance and details the metrics returned. It implicitly distinguishes itself from general callout listings and platform leaderboards by emphasizing 'YOUR ... instance' and per-caller aggregation, though it does not explicitly name sibling tools.

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

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

Provides an explicit example query and states the period and instance context, plus the feature-gating condition. It does not explicitly compare to csid_callouts, csid_callout_stats, or csid_leaderboard, so when-not/alternative routing is absent.

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 burden and does so well: it discloses ordering (newest first), the feature_not_enabled failure mode, auth requirements and the tracking-phase lifecycle (first_day/extended/stopped with the $10k threshold). That is exactly the kind of context annotations cannot convey.

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

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

Front-loaded with purpose and filter modes, then return fields, then prerequisites; every sentence carries information. It is somewhat long, and the per-field return list borders on redundant given the output schema, but nothing is filler.

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

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

For a 7-parameter, zero-required, paginated read tool with an output schema and annotations, the description covers scope, filter combinations, ordering, failure modes and auth. An agent has everything needed to call it correctly and interpret an error.

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 chain+mint dependency and the 'external_id or csid_id, not both' rule, so the description mostly repeats it. It adds the high-level filter-mode framing but no new syntax or format detail, matching the baseline 3 for a fully documented 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 ('Callouts on YOUR CabalSpy ID instance, newest first') and explains the domain concept of a callout. It is clearly distinguishable from siblings like csid_callout_stats, csid_callout_leaderboard and csid_user_theses by being the raw callout listing.

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 mode selection: no filters = latest platform callouts; chain + mint = callouts of one token; external_id or csid_id = callouts of one user, each with the question it answers. Also states prerequisites (feature enabled per instance, own API key with a CabalSpy ID instance, no demo), so an agent knows when the call will fail.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely non-obvious behavior: the callout feature is opt-in per instance and otherwise returns feature_not_enabled, and a CabalSpy API key with a real ID instance is required (no demo). Nothing is said about rate limits or payload size, so it is strong but 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?

Front-loaded with the purpose, then metrics, then the usage question, then prerequisites — a sensible information hierarchy. The metric enumeration is long but each item is distinct output information; only the trailing auth note could be tightened.

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

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

Covers the three things an agent would otherwise get wrong: which identity field to send, that the feature may be disabled, and that a non-demo key is needed. An output schema exists, so re-describing the returned metrics is slightly redundant but not harmful; no pagination or empty-result guidance is given.

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 each parameter already documents itself, including the mutual exclusivity of external_id and csid_id and the instance fallback. The description restates the external_id/csid_id rule but adds no format or defaulting detail beyond the schema, so baseline 3 applies.

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

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

Names a specific verb+resource at a precise scope: the callout track record of ONE user on YOUR instance, per period. The enumerated metrics (count, average, median, best, summed peak multiple, hits, hit rate, live average, all-time count) make it unmistakable against siblings like csid_callouts (a list) and csid_callout_leaderboard (cross-user aggregate).

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 selection trigger quoted as "How good are this user's calls?" and states the identity input rule (pass external_id or csid_id). It does not explicitly exclude the neighbouring leaderboard/list tools, so the agent must infer that from the purpose line.

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

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

Goes well beyond the readOnlyHint annotation by disclosing non-obvious behavior: standings recompute every 5 minutes and become final once ended, and it requires your own CabalSpy API key with a CabalSpy ID instance (no demo). That freshness and auth context is exactly what annotations can't 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-loads the core listing/detail split before drilling into 'kind' metrics and auth. It is fairly dense and the trading/callouts metric enumeration is lengthy, but it earns its place by enabling correct interpretation of standings.

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

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

An output schema exists, so return values needn't be explained, and the description covers auth, freshness, and both modes. What's slightly under-covered is anything beyond the status enum and limit caps already in the schema, but overall it's complete enough 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 the baseline is met, and the description still adds meaning beyond the schema by explaining competition_id's dual role (list vs rules/standings) and that it must come from a prior call.

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 resource (competitions of your white-label platform) with a clear dual mode: listing versus detail. It distinguishes itself from sibling leaderboard tools by scoping to YOUR platform's competitions. It doesn't name an explicit alternative, keeping it below a 5.

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

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

Provides concrete sample questions ('Who is leading the competition?', 'Which competitions are running?') and explains that omitting competition_id lists while supplying it returns rules and standings. No explicit when-not-to-use or sibling routing, 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.

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the 120-second execution window and that a pending instruction past it reads as 'expired', that CabalSpy never holds keys or trades, the consent_required failure mode, and the API-key/instance requirement. This is rich context annotations alone would not 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?

The two view= blocks are well-structured and front-loaded with the concept, and each sentence carries operational meaning. It is somewhat long, and it enumerates return fields that the output schema already covers, which is minor waste.

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

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

For a read-only, dual-mode tool with 100% schema coverage and an output schema, the description supplies the missing operational context: expiry semantics, consent gating, and instance/API-key prerequisites. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents all seven parameters, including the view enum values and status options; the baseline is 3. The description adds mode intent (which view to pick for which question) but no syntax or format 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?

The description opens with a concrete verb+resource ('Copy trading on YOUR CabalSpy ID instance') and clearly splits the tool into two modes, view=instructions and view=settings, each described in its own paragraph. It falls just short of 5 because differentiation from sibling tools is not addressed, though no sibling covers this resource.

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

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

It gives a concrete triggering question ('Which copy trades failed today?') and states the dependency of view=settings on external_id/csid_id. It also names a precondition (users need the 'trade_feed' consent, otherwise consent_required). It stops short of explicitly saying when NOT to use it or naming an alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds meaningful behavioral context: badges are 'reviewed' (real X account with reach, wallets proven on-chain), entries are ordered 'newest badge first', and each entry contains specific fields (X handle, followers, verified wallets, 7-day activity). It stops short of describing exact response structure, but with an output schema present that is acceptable.

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 resource definition, then example queries, then the sibling differentiation. Every sentence 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?

Complete for a read-only paginated list tool. Annotations cover safety, output schema covers the response format, the description covers scope, ordering, and field content, and the sibling relationship to get_leaderboard is explicitly handled.

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

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

Schema coverage is 100%, so all three parameters (chain, limit, cursor) are fully documented in the schema. The description lists the valid chain values again, which is repetition rather than added meaning. Baseline 3 is correct when the schema does the heavy lifting.

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

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

Specific verb+resource: returns KOLs with verified CabalSpy ID badges. It also distinguishes itself from the most likely confused sibling, get_leaderboard, by naming it explicitly for performance rankings.

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

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

Explicit when-to-use is given with example queries ('Which KOLs are verified on Base?' or to get wallets of verified influencers), and the alternative for performance rankings is named. This is the full when/when-not guidance requested.

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 safety is covered. The description adds real context beyond that: it is a live feed of 'verified holders', and crucially it discloses an auth prerequisite ('your own CabalSpy API key with a CabalSpy ID instance (no demo)'). It doesn't discuss rate limits or pagination semantics, 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?

Front-loads the purpose, then usage cases, then sibling routing, then the auth caveat. Every sentence earns its place with no redundancy; the whole thing is short and scannable.

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

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

An output schema exists, so return-shape explanation is unnecessary, and the description still summarizes the key returned fields. Auth requirements and sibling routing are both present. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% with every parameter (limit, scope, users, cursor, instance, blockchain) clearly documented in the schema itself. The description adds no parameter-level syntax or format detail beyond what the schema provides, 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 resource and scope: 'newest theses across all tokens: a live feed of what verified holders are posting', and names the returned fields (token, stance, author, position). It explicitly differentiates from the sibling csid_token_theses ('For one token use csid_token_theses'). An agent can distinguish this from related tools without opening schemas.

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

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

Gives concrete use cases ('What are verified traders talking about right now?' / 'discover tokens with fresh conviction') and routes the agent to the correct alternative for the single-token case. Both when-to-use and when-to-use-something-else are covered.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds real operational context: the Enterprise plan requirement for global scope, that no demo instance works, and that longer periods return data that 'gets trimmed harder.' It stops short of describing response shape or pagination, but that is reasonable given the output schema exists.

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 ranking definition and the sibling routing are front-loaded and the API-key note is correctly placed last. The scope explanation is stated twice (once inline, once again in the alternatives sentence), which is mild redundancy but not wasteful enough to hurt 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?

For a 7-parameter ranking tool with an output schema and annotations present, the description covers the essential non-structured facts: plan gating, instance requirements, and the period/trimming trade-off. Return values are legitimately left to the output schema, though pagination via cursor gets no mention here.

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

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

Schema description coverage is 100%, so sort, limit, period, cursor, instance and blockchain are all fully documented in the schema. The description reinforces scope semantics ('covers the users of YOUR CabalSpy ID instance' vs. global), but that meaning already lives in the schema's scope description, so it adds little beyond the baseline.

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

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

The description states a specific verb (ranks) and resource (CabalSpy ID verified traders) and enumerates the metrics used for ranking (volume, realized PnL, win rate, trade count). It explicitly distinguishes itself from the sibling get_leaderboard, which covers KOLs and smart money rather than your own instance's users.

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

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

It gives a concrete selection example ("Who are the best traders on my platform this week?"), names the alternative tool (get_leaderboard) with the condition that routes to it, and states the Enterprise-plan prerequisite for scope='global'. Prerequisites about the required CabalSpy ID instance and API key are also spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-structured context: it requires your own CabalSpy API key, a CabalSpy ID instance, and specifically no demo environment. It does not discuss trimming behavior or pagination limits, but those live in parameter descriptions.

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 blocks: what it returns, when to use it vs the alternative, and the prerequisites. The scoping information and the sibling exclusion are front-loaded with zero filler sentences.

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

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

Output schema exists so return values need no explanation, all 7 parameters are schema-documented, and the description covers the non-obvious operational prerequisites (API key, instance, no demo). An agent has everything needed to decide between this and csid_leaderboard and to call 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% and each of the 7 parameters (sort, limit, cursor, period, instance, blockchain, verified_only) is documented in the schema, including defaults and the blockchain enumeration. The description adds nothing about parameter format or interaction 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 ('Ranking of the users of YOUR platform ... by their trades on one chain') and enumerates the metrics returned (realized PnL, volume, win rate, trade count) plus the identifier (external_id). It explicitly distinguishes itself from the sibling csid_leaderboard by user population, so an agent can pick correctly 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 concrete use case in natural language ('Who are the top traders on my platform this week?') and an explicit routing rule: use csid_leaderboard instead when users sign in with CabalSpy ID themselves. It also states the prerequisite condition (users imported into a CabalSpy ID instance), covering when-not as well as when.

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 useful operational context: the white-label import prerequisite, the required CabalSpy API key with a CabalSpy ID instance, and the absence of demo support. It does not add much about response trimming or pagination, but the output schema covers return shape.

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

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

The definition is front-loaded with what the tool returns, then immediately covers the use case, sibling alternative, and auth prerequisites. Every sentence contributes routing or prerequisite information, 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?

Given the presence of an output schema and useful annotations, the description is complete enough to call the tool correctly. It covers scope, required context, auth prerequisites, and the key sibling distinction without needing to explain return fields in detail.

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

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

Schema description coverage is 100%, so all three parameters are already documented. The description reinforces that lookup is by the caller's own external user id, but adds no syntax, constraints, or format details beyond the schema.

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

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

The description states a specific resource ('One user of YOUR platform (white-label)'), the lookup key ('your own user id'), and the exact payload returned: display name, wallets, badges, per-chain stats, latest trades and theses. It also explicitly distinguishes itself from csid_profile, so an agent can route correctly without opening schemas.

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

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

It gives an explicit example query and an explicit exclusion: only for platforms importing users into a CabalSpy ID instance; for CabalSpy ID users who signed in themselves, use csid_profile. It further states the required API key/instance setup and that demo is not supported.

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 genuinely non-obvious behavior: the keyless demo only works with sandbox identities and suggests a test handle. It stops short of noting auth requirements 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 what the tool returns, then when to use it, then the selector constraint and demo caveat. Every sentence 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?

An output schema exists, so return values need no explanation. For a 4-parameter read tool, the description covers purpose, usage, selector semantics, and environment caveats completely.

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 itself already states the 'pass exactly one of' constraint in the username field. The description's parameter section largely restates the schema (one-of selector, address returns owner), adding little beyond structured data, 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 resource (CabalSpy ID profile of a crypto trader) and enumerates the returned fields (X account, Telegram, KOL badge, verified wallets, 7-day activity), which lets an agent distinguish it from siblings like csid_kols or csid_leaderboard. The verb+resource is unambiguous.

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

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

Gives concrete usage intent ('check who someone is and whether a trader really owns the wallets they claim') plus two illustrative example queries, which is strong context. However, it never names an alternative or a when-not-to-use condition, even though the address mode overlaps with the csid_wallet_owner sibling.

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 real behavioral context beyond that: replies are ordered oldest first, cursor paginates the replies, and it requires your own CabalSpy API key with no demo access. It omits rate-limit or error behavior, 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 short paragraphs, front-loaded with the resource and its content, then usage and the auth prerequisite. Every sentence carries information and there is no 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?

An output schema exists, so return values need not be described, and the description covers the drill-down usage, auth requirement, ordering, and pagination. It is complete enough to invoke correctly, though it could note behavior when the thesis_id is invalid or absent.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including cursor defaults and limits. The description reinforces that cursor 'pages through the replies', which is a small value-add but does not add syntax or formats beyond the 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?

States a specific verb and resource ('One thesis in full with its discussion') and enumerates the returned content (body, stance, author, position, reactions, replies). This clearly distinguishes it from the list-oriented siblings like csid_latest_theses and csid_token_theses, which return many theses rather than one in full.

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 context: 'Use after another csid_ tool when the user wants to read a thread,' which positions it as a drill-down following a list call. It does not name a specific alternative or state when-not to use it, so it stops 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 readOnlyHint and openWorldHint, but the description adds real context beyond them: it requires the caller's own CabalSpy API key with a CabalSpy ID instance and explicitly says demo accounts will not work. It also discloses that results are cursor-paginated via next_cursor and that each thesis carries the author's live position (holding/sold, invested, PnL).

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 purpose and return shape, then layers usage examples, the auth prerequisite, and the pagination instruction. Mostly economical, though the example call and the 'Page with the returned next_cursor' line could be tightened.

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

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

For an 8-parameter read tool with a full output schema and read-only/open-world annotations, the description covers the remaining agent-facing gaps: the auth prerequisite, the pagination loop, and what a returned thesis contains. 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?

Schema description coverage is 100%, so blockchain, mint, sort, scope, stance, cursor, instance and limit are already documented at the field level. The description only echoes an example blockchain/mint pair and repeats the sort choice as 'latest (or top)', adding no syntax or semantics beyond the schema.

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

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

States a specific verb and resource ('What do verified holders think about a token?') and names the exact payload: a bull/bear summary plus latest or top theses. It further defines a 'thesis' as a short post only holders of the token in a verified wallet can write, which cleanly separates it from siblings like csid_thesis or csid_latest_theses.

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 concrete usage triggers ('What do holders say about $BONK?', 'Is sentiment on this token bullish?') so an agent can map a natural-language sentiment question onto this tool. It does not, however, state when to prefer the neighboring csid_latest_theses or csid_user_theses, or name any exclusion.

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 genuinely useful context beyond that: the result is ordered newest-first, and it requires your own CabalSpy API key tied to a CabalSpy ID instance (no demo), which is a real precondition an agent must know.

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

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

Three sentences, front-loaded with what the tool returns before the use case and the auth requirement. No filler; the example question is the single flourish and it earns its place by clarifying intent.

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

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

Output schema exists, so return fields need not be explained, and the description still sketches the shape (token, position, ordering). Auth prerequisites and the user-scoping are stated; only explicit routing to competing siblings is left implicit.

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

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

Schema description coverage is 100%, so limit, cursor, csid_id, instance, and username are all already documented in the schema. The description references the username form only via the example handle and adds no syntax or format detail beyond the structured fields; 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: 'All theses one CabalSpy ID user has posted, newest first, with token and the position they hold.' The user-scoping and newest-first ordering clearly separate it from token-scoped siblings like csid_token_theses and the global csid_latest_theses.

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 with a sample question ('judge a caller's track record: What has @CabalSpySol been bullish on, and did it work out?'), which tells the agent when this tool fits. It stops short of explicitly naming which sibling to use instead for token-level or global queries.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-scope are covered. The description adds real behavioral context beyond that: the not-found case returns verified=false rather than erroring, and multiple addresses collapse into a single batch request. Missing only secondary traits like rate limits or cost of large batches.

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

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

Front-loaded with the one-line answer to the core question, then usage, then sibling differentiation. Slightly verbose with the rhetorical opener and the parenthetical field list, but every sentence carries usable information; nothing is wasted on 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 an output schema present, return-value documentation is not needed, and the description covers purpose, triggers, alternatives, the negative case, and batch behavior. For a one-parameter read tool this is close to complete; only limits on batch size/rate behavior 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 coverage is 100% and the single parameter is fully documented (format, count, mixed chains, example), which sets a baseline of 3. The description adds batching semantics not present in the schema — that several addresses count as one batch request — which is meaningful for planning multi-address calls.

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 ('Who owns a wallet? Returns the CabalSpy ID user who proved ownership') and enumerates the identifying payload (X handle, KOL badge, verified chains) plus the verified=false fallback. It explicitly distinguishes itself from the sibling lookup_wallet, 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?

Names concrete use cases ('user pastes an address and asks who is behind it', 'find verified traders among a token's holders') and names the alternative tool (lookup_wallet for CabalSpy's own labels), making the when-to-use and when-to-prefer-the-sibling 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 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. The description adds the 24-hour window cap, but that constraint is also in the schema, and it says nothing about aggregation behavior, caching, rate limits, or what happens when the window has no data.

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

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

The purpose is front-loaded in the first sentence and the usage caveat follows immediately. The trailing parameter list duplicates the schema and is the only mildly wasteful element, but overall it is tight and skimmable.

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 shape needn't be described, and the annotations carry the safety profile. Purpose, usage boundary, and parameter enumeration are all present; only the aggregation semantics (e.g. how the window is computed, empty-window behavior) are absent.

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

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

Schema description coverage is 100%, so every parameter is already documented with types, defaults, and bounds. The description's parameter block (blockchain options, wallet_type values, hours cap, mint restriction) largely restates the schema without adding new semantics, so the baseline 3 applies.

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

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

The description states concretely what is returned — trade count, value moved, and distinct wallet count over a bounded window — which is more informative than the bare name 'get_activity_metrics'. It also implicitly distinguishes itself from the per-trade sibling by saying it is not for 'the individual trades.' It stops short of a crisp verb+resource statement, but an agent can tell what this produces.

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 guidance: 'Use for how busy the market or a single token is, rather than for the individual trades' gives both the appropriate context and an exclusion that routes the agent away from a trade-listing tool. It does not name the alternative tool (e.g. get_recent_trades) outright, so the routing relies on 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 and openWorldHint=true, so the safety profile is covered. The body text adds only the aggregation scope and parameter defaults; it says nothing about rate limits, auth requirements, or result trimming (that detail lives only in the schema descriptions). Adequate but not additive.

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

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

Front-loaded with the purpose and mode enumeration, and every sentence is short. The trailing parameter list is largely redundant with a 100%-covered schema, which costs it a point, but nothing is padded or buried.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. With modes, defaults and the aggregation scope all stated, an agent has enough to invoke it correctly; only explicit sibling routing is absent.

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

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

Schema description coverage is 100%, so the schema already carries the semantics, and it is in fact richer than the description (per-chain wallet-type availability, trimming guidance for limit/period). The description's parameter list largely restates 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?

Opens with a specific verb+resource ('Four aggregate views over the tracked wallets') and then enumerates each mode's meaning (volume_trend, most_traded, win_rate, top_performers). The closing line 'Use for the overall picture rather than one wallet or token' separates it from single-entity siblings like compare_wallets and get_wallet_tracker.

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 scopes the tool to aggregate/overall views rather than one wallet or token, which gives clear selection context. It does not, however, name the specific sibling tools (e.g. lookup_wallet, get_wallet_tracker, compare_wallets) that handle the per-entity case, so the routing is implied rather than spelled out.

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

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

Annotations already 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 only declare readOnlyHint and openWorldHint, and the description adds real context beyond them: newest-first ordering, fixed picks per tier, the ~2-day measurement window behind 'pending', and the return payload composition. It stops short of stating pagination or rate-limit behavior, but the pending-status caveat is the kind of thing that prevents an agent from misreporting a result.

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 get_signals routing are front-loaded in the first two paragraphs, which is the right ordering. The trailing parameter recap largely duplicates the schema and could be cut, but overall the text is tight and each paragraph has a distinct job.

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

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

An output schema exists, yet the description still summarizes the returned fields and performance metrics, and it covers scoping (tier, chain, time window) and paging (cursor) sufficiently to call the tool correctly. Nothing an agent needs is missing for a read-only, open-world listing tool.

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

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

Schema description coverage is 100%, so all six parameters are already documented. The description restates the same enums, defaults, and ISO 8601/Unix time formats without adding syntax or edge-case guidance (e.g. behavior when since > until), so it clears the baseline but adds little.

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 ('curated CabalSpy calls ... newest first') and enumerates what each call contains (token, market cap at call, KOL/Smart Money wallets, trading links, 24h performance). It also explicitly distinguishes itself from get_signals, so an agent can pick correctly 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 concrete use cases ('what did CabalSpy call', 'how did the call on this token do') and an explicit alternative with its selection condition: 'for wallet clusters with your own thresholds use get_signals instead.' It even pre-empts a likely misread by explaining that performance.status 'pending' is not a bad result.

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

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

Annotations already mark this as read-only and open-world, and the description adds substantial behavioral context beyond them. It explains the counting methodology, excludes calls without price data, marks recent calls as pending, and clarifies that only the first call per token/tier/day counts.

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

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

The description is front-loaded with the tool's purpose and then provides useful methodology and usage notes. It is generally efficient, though the parameter list near the end largely duplicates the schema and could be trimmed.

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

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

An output schema exists, so the description need not explain return formatting. Given the annotations, complete schema coverage, and the description's explanation of aggregation rules and pending behavior, an agent has enough information to call this tool correctly.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description restates the allowed values and defaults for period, blockchain, and tier, but does not add meaning beyond what the schema already provides.

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

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

The description states a very specific resource: performance statistics for curated CabalSpy calls, grouped per chain and tier. It enumerates the exact metrics returned, including call counts, hit rates for 2x/5x/10x, median peak multiple, time to peak, and best calls, which clearly distinguishes it from a raw calls listing such as get_calls.

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 usage examples: "Use this for 'how good are CabalSpy calls' or 'which tier works best'." It does not name alternative sibling tools or state when not to use this tool, so it falls short of a 5, but the intended context is clear.

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

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

readOnlyHint=true and openWorldHint=true already tell the agent this is a safe, live-data read, so the description need not restate safety. It adds some scope context (whale is Solana-only, defaults) but nothing about result shape, freshness, or trimming beyond what the schema already covers.

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 statement is front-loaded, followed by usage examples, then a compact parameter legend. It is appropriately sized, though the parameter enumeration duplicates schema content and takes space without adding value.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. Required/optional params, defaults and enum values are all available; the definition is complete enough to invoke correctly, missing only sibling-level routing.

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 (including valid enum values and defaults) are already documented. The description's parameter list largely restates the schema, adding no syntax or semantic detail beyond it – 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 – "top tracked wallets ranked by performance" – scoped by chain, wallet type and period. It is clearly a ranking/leaderboard over wallets rather than a plain wallet listing (list_wallets) or token comparison (compare_tokens), though it never names a sibling to draw that boundary 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?

Concrete example queries ("best Solana KOLs today", "top whales this week") make the intended use case easy to match against a user request. No when-not guidance or explicit alternative tool (e.g. csid_leaderboard, list_wallets) is given, so the agent must infer the boundary.

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 safety is covered. The description adds genuinely useful semantic context — the data is realized (not unrealized) P&L and is bounded by 'tracked history' — but says nothing about latency, rate limits, or how the two granularities are combined in the response.

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 of real content are front-loaded, but the trailing blockchain/address lines duplicate the schema verbatim and add no value an agent doesn't already have. Removing them would lose nothing.

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 read-only safety is covered by annotations. Between the description and schema, granularity, scope of history, and both required inputs are all accounted for; only the choice against sibling analytics tools is left open.

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 are already fully documented; the description simply restates them, and its blockchain list is actually less informative than the schema's (it omits the wallet-type detail captured there). Baseline 3 for a schema that does the heavy lifting.

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

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

States a specific verb+resource: realized P&L at daily and monthly granularity for a wallet over its tracked history. That is clearly distinguishable from lookup_wallet or get_wallet_holdings, 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?

The second sentence gives a use case ('when a wallet made or lost money', 'spotting streaks'), which is implied guidance rather than explicit when-to-use/when-not-to-use. No alternatives such as get_activity_metrics or get_wallet_history are mentioned, so routing depends on 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 and openWorldHint=true, so the safety profile is covered. The description adds the real-time/'right now' character of the feed, which is genuine behavioral context, but says nothing about refresh cadence, data latency, or cost. Adequate but thin beyond 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 is front-loaded in the first sentence, followed by a compact one-line-per-parameter legend that scans fast. The parameter list duplicates schema text, so a little of it does not earn its place, but nothing is 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-value explanation is not required, and the description covers the tool's real-time semantics plus every parameter. It leaves minor gaps (pagination/refresh behavior, what set of wallets counts as 'tracked'), but nothing that would cause a mis-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 schema already documents all five parameters in detail (including the richer per-chain wallet-type availability and the 'rh is Robinhood Chain' note). The description's parameter legend largely restates the schema and adds no syntax or format meaning the agent could not already read. 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 resource and its defining trait ('the live feed: what tracked wallets are buying and selling right now'), which is a real functional distinction from historical siblings like get_wallet_history or get_token_transactions. It stops short of naming any sibling explicitly, so differentiation is inferable 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?

It gives a concrete usage cue, 'Use for "what are KOLs buying at the moment"', which tells the agent the intent this tool serves. There is no when-not guidance and no named alternative to route against, so it stays at clear-context level rather than 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the notion that results are historical snapshots used for validation, but says nothing about auth needs, recency of data, or rate limits beyond what annotations and schema provide.

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

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

The opening sentence is well front-loaded and earns its place, but the subsequent parameter legend repeats content already fully present in the schema, so part of the text does not add value.

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

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

With an output schema present, return values need not be explained, and the description plus annotations cover purpose, valid inputs, and safe-read behavior. It is complete enough for an agent to select and call the tool correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description's parameter legend largely duplicates the schema's value lists and adds no syntax or format meaning beyond it, making the baseline 3 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 names a specific resource — past signals — and frames the scope as historical lookup versus 'acting on a live one', which implicitly separates it from get_signals. It does not explicitly name the sibling tool, so it stops just short of a 5.

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

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

It gives a clear use case: check whether a signal kind has worked historically before acting on a live one. There is no explicit when-not or named alternative, but the triggering context is genuinely useful and unambiguous.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavior beyond them: only the first page is reachable and no usable cursor is returned, plus eth has no smart-money data. It does not mention auth requirements or rate limits, but the pagination caveat is a high-value disclosure.

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, mode semantics, and the key limitations are front-loaded before the parameter list, and prose is tight. The trailing parameter enumeration is partly redundant given full schema coverage, which keeps it from a 5.

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 covers purpose, mode semantics, the pagination constraint, and the eth limitation. It is close to complete for a 7-param filtered-list tool, with only minor gaps around defaults/constraints already handled by the schema.

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

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

Schema description coverage is 100%, and the schema descriptions are actually richer than the prose list (e.g., min_wallets '0 uses the server default of 3', limit trimming guidance). The description's parameter list largely restates the schema, so 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 description gives a specific verb+resource: tokens where multiple tracked wallets acted in the same window, and unpacks the three modes (cluster/entry/exit). The phrase 'what should I be looking at right now' implicitly separates it from the get_signal_history sibling by signaling current/latest signals, though it never names the 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 clear usage context ('Use this for "what should I be looking at right now"') and an explicit when-not condition ('Smart money signals are unavailable on eth'). It also tells the agent how to handle result size (raise the limit rather than paginate). It stops short of naming alternative tools for historical lookups.

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 and openWorldHint, so the safety profile is covered. The description adds useful non-obvious context the annotations lack: result ordering (by balance), the USD market cap/price fields, and per-chain wallet-type availability (solana has kol/smart/whale; others only kol/smart).

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

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

Front-loaded with purpose and usage in the first two sentences, followed by a compact per-parameter reference block. Every line is short, though the parameter block partly duplicates the schema rather than adding value.

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

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

With two required params, full schema coverage, and an output schema present, the description needn't explain return values. It still notes ordering and the key output fields, and the chain/wallet-type interaction, so an agent has everything needed to call 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 every parameter is already documented in the schema. The description mostly restates those same facts (chain list, default limit 25, wallet_type options) rather than adding new meaning. Baseline 3 applies.

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

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

States a specific verb+resource: tracked wallets holding a token, sorted by balance, with market cap and price in USD. The clause 'who is still holding, rather than who ever traded it' cleanly separates it from trade/transaction-oriented siblings like get_recent_trades or 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?

Explicitly frames the triggering question ('who is still holding') and contrasts it with 'who ever traded it', which routes the agent away from transaction tools. It does not name the exact sibling to use instead, keeping it 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 readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine behavioral context beyond that: the market-cap field comes back empty on this endpoint even for Solana, which the agent would otherwise not know. It stops short of disclosing pagination or result-size 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 lead paragraph is strong and front-loaded, but the following parameter lines duplicate what the 100%-covered schema already documents, so they don't earn their space. The market-cap caveat is a useful carve-out but the overall block is longer than needed.

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. Between the purpose statement, the use-case anchor, the market-cap caveat, and the (redundant) param notes, an agent has what it needs to call this correctly; only edge cases like pagination or empty-result handling are unaddressed.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely restates the schema (blockchain options, mint mapping, wallet_type restrict/omit) without adding syntax, format, or edge-case meaning beyond 'omit to merge all types', which the schema already states.

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

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

The description opens with a concrete verb+resource ('Who is trading a token') and enumerates the exact metrics returned (KOL/smart/whale counts, bought/sold, buying pressure, entry times, individual positions). It explicitly differentiates from the sibling get_token_holders by noting the market-cap gap, so an agent can tell the two apart.

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 primary use case ('The main tool for "is anyone notable in this token"') and routes one specific field (market cap) to get_token_holders. However, it doesn't address the other nearby siblings (compare_tokens, get_token_transactions) or state when not to use it, so guidance is clear but 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 already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavior: results are individual transactions ordered newest-first, limited to tracked wallets, and wallet_type can be merged when omitted.

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

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

Front-loads the purpose and usage before listing parameter notes in a scannable structure. The parameter list duplicates the schema, but the description remains short and easy to parse.

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

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

Output schema exists, so return values need not be explained. The description covers scope, ordering, and usage context; only minor details like maximum result size are 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%, so all four parameters are already documented. The description largely repeats schema-level information about blockchain, mint, wallet_type, and limit without adding syntax, constraints, or edge-case 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?

States a specific verb and resource: individual buys and sells by tracked wallets in one token. The ordering 'most recent first' and scope 'in one token' distinguish it from broader trade/history 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 a clear use case: 'Use for the sequence of events, for example whether KOLs bought before or after a price move.' It does not name alternatives or when-not-to-use conditions, 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.

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description nonetheless adds real behavioral context beyond them: a fixed 30-day lookback window, a restriction to 'tracked' wallets only, and the fact that results are ranked by overlap. It omits any note on pagination or truncation behavior, but that is also covered in the schema's limit field.

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 two sentences are tightly front-loaded and earn their place. However, roughly half the text is a redundant parameter glossary that duplicates a fully documented input schema, which dilutes an otherwise efficient 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 need not be explained, and the description covers what is returned, the time window, and the ranking basis. What is missing is routing guidance against the many sibling wallet/token comparison tools, which an agent would need to pick this tool 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 100%, so the baseline is 3. The description's parameter lines are essentially a re-listing of what the schema already documents (blockchain enum values, address, limit default) and add no new semantics such as address format or the trimming caveat, which live only 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?

The description states a precise resource and scope: 'Other tracked wallets that traded the same tokens as this one over the last 30 days, ranked by overlap.' That is far more specific than a restatement of the name and tells the agent exactly what population is returned. It does not, however, name or differentiate itself from adjacent siblings such as compare_wallets or get_wallet_tracker, so it falls short of a 5.

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

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

'Useful for finding groups that move together, which can indicate coordination' gives an implied use case, which is better than nothing. There is no explicit when-to-use vs when-not, no named alternative (e.g. compare_wallets for wallet-to-wallet comparison), and no prerequisites such as requiring the wallet to be tracked first.

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

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

Annotations already cover readOnly/openWorld, so the bar is lower, and the description adds genuinely non-obvious behavior: pagination is embedded in the payload rather than alongside it, requiring next_cursor to be followed until null. It also notes that large limits 'get trimmed anyway', disclosing a practical response-size constraint.

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 tool's purpose, then pagination semantics, then a tight parameter glossary. Minimal waste, though the parameter block largely duplicates schema descriptions.

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 still adds the pagination-format caveat that is essential for correct iteration. Only the limit-range inconsistency keeps this from being fully complete.

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

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

Schema coverage is 100%, so baseline 3 would apply, but the description undercuts the schema by stating limit is '1-1000' while the input schema caps it at maximum 200 — a direct conflict that could lead an agent to pass invalid values. Otherwise it mostly restates what the schema already documents about blockchain and cursor.

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?

It names a specific verb+resource ('Lifetime trading history of a wallet') and enumerates the three payload parts an agent gets back (aggregate stats, per-token overview, individual trades). The clause 'rather than how it is doing now' distinguishes it from current-state siblings like get_wallet_holdings, 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?

It gives a clear temporal selection rule ('what a wallet traded historically, rather than how it is doing now') plus a concrete pagination procedure for full exports. It stops short of naming the alternative tools an agent should pick instead for present-tense 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 only cover readOnlyHint and openWorldHint, but the description adds genuinely useful operational context: the call is slow (often over a second) and the payload can be returned in a warm-up state flagged by 'loading', with an explicit retry instruction. It does not mention auth requirements or rate limits, so it stops short of full disclosure.

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

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

The core purpose, latency warning and loading behavior are front-loaded in three tight sentences. The trailing 'blockchain' and 'address' lines duplicate the schema verbatim and are the only wasted space.

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

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

An output schema is present, so return-value shape need not be explained, and both parameters are fully covered by the schema. The remaining gap is that it never states what an agent should use instead when it needs faster or historical wallet data, which matters given the large sibling 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%, with both 'address' and 'blockchain' fully documented in the schema, so the baseline is 3. The description's restatement of the chain list and address definition adds no meaning beyond the schema; the only extra is the wallet-type note that actually lives in the schema, not here.

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

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

The description names a specific verb and resource ('Current onchain token holdings of a wallet') and immediately draws the defining distinction from sibling wallet tools: data is read live rather than derived from tracked trades. An agent can tell this apart from get_wallet_history or get_wallet_tracker 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?

It signals that this is 'slower than the other wallet tools' and gives retry guidance when 'loading' is true, which implies a usage context. However, it never names the alternatives or states the condition under which an agent should prefer them, so the when-to-use decision 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 and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond that: longer periods return far more data and are 'trimmed harder', which warns the agent about result truncation. It still says nothing about auth or rate limits, but the trimming datum is genuine added value.

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

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

Front-loads the purpose in the first sentence, then the one-line-per-parameter layout is scannable and wastes little. Slightly verbose in repeating the period caveat that also lives in the schema, but nothing is padded.

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

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

An output schema exists, so return-shape explanation is unnecessary. With required params, enums-in-description and the trimming caveat all conveyed, the definition gives an agent everything needed 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 100%, so the schema already documents all three parameters in detail (including the same period/trimming note and address format). The description restates blockchain, address and period without adding syntax or constraints the schema lacks; 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 ('Period statistics for ONE wallet') and enumerates exactly what is returned: realized PnL, win rate, volume, trade counts, active tokens and win-rate distribution. The 'ONE wallet' emphasis and 'main tool for how is this trader doing' framing meaningfully distinguish it from the multi-wallet sibling compare_wallets.

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

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

Usage is implied by 'The main tool for how is this trader doing', but there is no explicit statement of when to prefer this over get_wallet_history, get_pnl_calendar, or compare_wallets. The period advice ('prefer the shortest period that answers it') is a useful calling guideline but is scoped to one parameter rather than the tool-level decision.

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 genuine behavioral context beyond that: the result set is very large ('runs into the thousands'), the caller should always bound it with a limit, and pagination proceeds via a cursor from the previous response. It does not discuss rate limits or trimming behavior, which the schema mentions instead.

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 and usage sentence are front-loaded, and the parameter list is terse. However, the parameter block duplicates information already present in the 100%-covered schema, so it is slightly redundant rather than fully earning every 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?

An output schema exists, so return-value explanation is not required. Given the tool's simplicity, the description covers the key facts an agent needs: what is listed, the chain/type filter, the scale warning, the mandatory limit, and cursor-based pagination. Nothing material is missing 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 all four parameters (including allowed blockchain values, wallet_type meanings, limit default, and cursor usage) are already documented in the schema. The description largely restates those same values rather than adding new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Browse the wallets CabalSpy tracks') and scopes it by chain and wallet type, which separates it from per-wallet siblings like lookup_wallet or get_wallet_tracker. The phrase 'which KOLs or smart money wallets are covered at all' further signals the browse/coverage intent. It stops short of naming a sibling alternative explicitly, so it is clear but not maximally 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?

It gives a concrete use case ('answer which KOLs or smart money wallets are covered at all') and an operational instruction ('Always pass a limit; the full list runs into the thousands'). There is no explicit when-not guidance or named alternative, so it is clear context rather than a full decision 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.