CryptoSocials

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

Annotations cover only the safety profile (readOnly, non-destructive, not idempotent, closed world), yet the description discloses semantics far beyond them: totals sum lifetime counters of in-window posts rather than engagement earned in that window, known repost target counters are excluded from the reposter's totals, missing numeric data means unknown not zero, and views are not unique people or coin-attributed reach.

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 usage and efficient in that every sentence carries signal, but the text is a dense wall of long, clause-heavy sentences with heavy jargon and no formatting or grouping, which slows an agent's extraction of the operative constraints.

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 19-parameter aggregation tool with no output schema, the description covers the high-risk semantics (window limits, archive vs live, totals interpretation, zero-vs-missing, ordering families). Some parameters (limit, cursor, text, has_media, asset_id sourcing) are left entirely to the schema, and no return shape is sketched beyond 'numeric availability is returned per metric'.

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 68%, and the description meaningfully supplements the remaining gaps: it explains the three metrics modes, notes coverage adds diagnostics, defines engagement's dependency on group_by=author, distinguishes summed *_desc from max_*_desc ordering, and clarifies include_related_assets=true adds co-mentioned asset groups while the default returns known zeros.

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

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

The description names the resource (discussion posts, participation, a coin's community) and the operation (ranking/counting by posts, views, likes, reposts), and 'Counts cover the complete filtered window before group pagination' clarifies it produces aggregated counts rather than raw posts. It does not explicitly name sibling tools like search_posts or get_posts, so differentiation is implied 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?

Opens with explicit when-to-use triggers (ranking discussion, comparing participation, examining community), and gives conditional guidance: 'Engagement requires metrics=engagement and group_by=author', 'archive is the default', and 'evidence_scope=live retains exactly one asset and seven days'. No alternatives are named, so the agent must infer that a raw post search belongs elsewhere.

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 (readOnly=true, destructive=false), yet the description adds real behavioral content: union totals across the full window, per-identity baseline/current counts, identities and absolute/percentage change, explicit handling of selected zeros, unavailable identities, and undefined zero baselines. It also warns that sentiment is not inferred and collection coverage is not equalized — genuine caveats not derivable from annotations or schema.

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

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

The trigger condition is front-loaded, followed by return contents, then caveats — a sensible order with no padding. The wording is dense and occasionally telegraphic ("zero baseline is undefined"; "full-window union totals"), which costs a little readability but every sentence carries distinct information.

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

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

With no output schema, the description correctly takes on the return-value burden and describes totals, per-identity counts, identities and change measures. For a tool whose two arguments are large nested filter objects, it could say more about how the two windows must be kept comparable and how paging behaves, but nothing an agent needs to avoid calling it wrongly is missing.

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

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

The nested schema carries detailed descriptions for cursor, date bounds, ID sources and filter semantics, but the reported coverage signal is 0% for the top-level structure. The description clarifies that both periods should target the same assets/authors/topic and explains result semantics around zeros, but it adds no guidance on the many nested filter parameters (chain_ids, evidence_class, post_types) that an agent must populate. Baseline 3 reflects partial compensation rather than full coverage.

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

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

The opening sentence gives a specific verb (compare), a specific resource (discussion volume / activity), and the scope (two periods for the same assets, authors or topic). An agent can distinguish this from siblings like aggregate_posts or discover_activity without opening the schema, and the description also states what it does not do.

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 comparing how discussion volume changed between two periods..." states the trigger condition clearly, and "Read posts separately to assess views" routes one adjacent need elsewhere. It stops short of naming concrete sibling tools (e.g. search_posts, aggregate_posts) or stating explicit when-not conditions, so it is strong context without full alternative mapping.

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

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

Annotations already declare the read-only, non-destructive, non-idempotent profile. The description adds genuine behavioral context beyond them: what metrics=counts vs coverage returns, and the important caveat that this is not a complete source history or a live watermark, which sets expectations about data completeness.

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 tightly written sentences, front-loaded with usage guidance, then output modes, then exclusions. No filler; each sentence carries distinct information.

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

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

For a 13-parameter read-only tool with no output schema, the description usefully explains what is returned (post/author counts, coverage diagnostics) and disclaims completeness limits. Given the schema carries most filter detail, this is nearly sufficient, though the complex filtering surface could use slightly more framing.

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 69%, and the schema already documents most parameters (including the detailed full_text_query and chain_ids semantics). The description adds meaning only for the metrics parameter, explaining the difference between counts and coverage, but does not compensate for the remaining undocumented filters.

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 purpose — checking what readable evidence exists for a UTC period and scope — and clarifies its two output modes (counts vs coverage diagnostics). It is clear what the tool does, but it does not distinguish itself from siblings such as aggregate_posts or get_usage, leaving the agent to infer the boundary.

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

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

It gives an explicit when-to-use condition ('checking what readable evidence exists for a requested UTC period and scope') plus clear when-not guidance ('not a mandatory first call, complete source history or a live collection watermark'). It stops short of naming a specific alternative sibling to use instead.

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

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

Annotations already establish the safety profile (readOnly, non-destructive, not idempotent), and the description adds real context beyond them: no automatic baseline or category labels, the shape of returned data (population status, counts, reusable IDs, one relevance source), per-page credit consumption, and a stopping rule for leading-N ranking. The ranking_bound passage is cryptic and references a parameter that does not appear in the schema, which slightly muddies rather than clarifies.

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-loading the 'Use when' clause is good, and most sentences carry information. However the ranking_bound sentence is a dense conditional that is hard to parse, and several phrases ('one relevance source per returned candidate', 'candidate population status') pack multiple concepts without unpacking them, so the paragraph reads as compressed rather than efficient.

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

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

With no output schema, the description does carry return-value information and explains credit consumption, which is appropriate coverage. But for a tool with three nested filter objects and no documented ordering/grouping semantics, key behaviors needed to call it correctly — what each order mode means, how group_by changes results — are missing from both structured data and 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 coverage is only 29% across 7 params, so the description must compensate. It does add high-value semantics for the most confusing part — the separation of discovery-only text from current/baseline measurement filters for whole-project vs topic-scoped activity — plus cursor continuation guidance. But it leaves order, group_by, limit behavior, and most filter parameters unexplained in both schema and description.

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

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

The opening sentence states a concrete verb-and-resource pair: find assets/authors matching a topic and compare discussion across current/baseline windows. It is clear what the tool produces, though it never names the obvious siblings it competes with (compare_activity, aggregate_posts, search_posts), so an agent must infer the boundary itself.

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 genuine when ('finding projects or voices matching a topic and comparing their discussion'), an explicit when-not ('not an exhaustive thematic or narrative census'), and routes follow-up to a named sibling ('read missing decisive wording/relations with get_posts'). It does not, however, contrast against the sibling tools that overlap most (compare_activity, aggregate_posts), leaving the selection boundary partly 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 cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description focuses on behavior: the first-page summary measures all matching posts and returns exact totals, top authors and highest single-post views, and it warns the result is not a live quote. It stops short of detailing pagination/cursor lifecycle or error behavior beyond what the schema states.

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

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

Front-loaded with the triggering condition and dense with useful information, but the middle section drifts into generic agent-operating advice ('await at most two independent calls together; retain complete results and emit requested summaries') that is not tool-specific and crowds the tool-relevant routing sentences. Several sentences are long and multi-clause.

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 19 parameters and no output schema, the description compensates well by describing the returned fields and the first-page summary semantics. It remains incomplete on how the many filter parameters interact (chain_ids + asset_type, exclude_post_types) and on pagination behavior for large result sets.

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 79% (high), so baseline is 3, but the description adds real meaning for projection=market ('full retained text plus publication-time estimates and separate ingestion captures') that the schema's one-line enum gloss doesn't convey. It does not clarify the overlap between the schema's detail=market and the description's projection=market, which risks confusion.

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

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

The opening sentence states a specific verb and resource ('investigating what people said about a particular asset over a chosen period') and enumerates the payload shape (identity, posts, whole-window activity counts, engagement_summary). It explicitly distinguishes itself from siblings get_assets and get_market_history, so an agent can route 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 explicit branching: prefer get_assets for many coins, use the first-page summary instead of scanning every post for rankings, choose projection=market for claims, and reuse series_id with get_market_history. It also explains what projection=market returns versus what this result is not ('not a current quote or candle curve').

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 annotations by disclosing cost ('one fixed get_asset credit tariff per successful batch'), sampling limits (0-5 posts per asset, default 3, 2 for 17-20 assets, at most 50 total), non-exhaustiveness, absence of retention slots/cursors, per-item not_found semantics, and 'no upstream provider calls'. These are the behavioral facts an agent needs and none are derivable from the structured fields.

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

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

Front-loaded with the verb/resource/return shape and the sibling comparison, then facts in priority order. It is dense and packs several clauses (caps, sampling caveat, retention, result-handling advice) into a short block, with the trailing 'Retain full results in program state...' sentence the only mild overreach.

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 13-parameter, nested-input tool with no output schema, the description covers batch scope, cost, sampling bounds, partial-failure behavior, and when to use a narrower sibling. Filter-parameter semantics are delegated to a mostly-decent schema, so the definition is complete enough without being exhaustive.

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

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

With 62% schema coverage the schema carries much of the load, but the description adds value the schema cannot: posts_per_asset defaults (3, dropping to 2 for 17-20 assets) and the 50-post aggregate cap, neither of which appears in the schema. Other filters (chain_ids, asset_type, evidence_class) rely on schema descriptions, so it isn't exhaustive.

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 (read) and resource (1 to 20 selected coins) plus exactly what is returned: dated identity, market-cap fields, whole-window activity, and a bounded newest post sample. It explicitly distinguishes itself from the single-item sibling ('Prefer this to a burst of individual get_asset calls'), so an agent can route without opening a schema.

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

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

Gives explicit when-to-use (batch of 1-20 assets), when-not (deeper selected evidence uses get_asset/get_posts), and a configuration shortcut (posts_per_asset=0 when only identity and counts are needed). Both the alternative tool and the condition that selects it are named.

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

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

Annotations already carry the safety profile (readOnly=true, destructive=false, openWorld=false), so the description focuses on semantics that structured fields can't convey: that whole-window counts and engagement_summary come from exact latest-counter totals and should be reused 'instead of summing a returned post page'. It also sets expectations by stating 'no accuracy score is supplied' and explains the consequence of a missing ID. No pagination or retention behavior is restated here, but the schema and mode/limit params cover that.

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

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

Front-loaded with the routing rule ('Use when...') and dense with non-redundant content across six tight sentences. The closing analytical instruction about assessing claims against price history is more interpretive guidance than invocation guidance, but it is short and useful.

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 19 parameters, nested text objects and no output schema, the description is expected to carry a lot, and it does explain the returned surface (identity, profile, posts, counts, engagement_summary) and the sampling window semantics. Pagination, retention and the 366-day window are left entirely to the schema, which is acceptable but leaves the definition slightly thin for a tool this complex.

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?

At 79% schema coverage with 19 parameters, the schema does most of the work, so the baseline would be 3. The description adds real meaning for the required author_id, which has no schema description at all, by specifying it must be the internal ID from search_authors and not a handle or X user ID, and it clarifies that reported counts are whole-window rather than page-derived.

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

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

The description names the resource ('author') and spells out what the call returns: author identity, latest stored profile, posts, whole-window counts and first-page engagement_summary. It also frames the use case ('checking a Crypto Voice's claims, changes of view or discussion of an asset over time'), so the agent knows what job it serves. It stops short of stating how it differs from the sibling get_profile/get_posts, which is the only 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?

Clear when-to-use framing plus an explicit prerequisite chain: take the internal author_id from search_authors rather than an X handle or X user ID. It also names the fallback for the failure case ('A missing internal ID cannot record a handle for coverage review; use search_authors with the exact @handle'). No explicit statement of when to prefer get_profile or get_posts instead, so it falls 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 cover the safety profile (readOnly, non-destructive, not idempotent), and the description adds substantial independent context: it returns missing/failed checkpoints as well as successes, distinguishes observed_at from snapshot_at, and warns that null counters mean unknown rather than zero. That is exactly the kind of interpretive disclosure annotations cannot carry.

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

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

The usage trigger is front-loaded, followed by return semantics and then interpretation caveats. Six sentences is dense but each carries distinct information (age-at-capture guidance, snapshot_at meaning, null semantics, non-finality). Slightly longer than necessary, but nothing is redundant.

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

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

With no output schema, the description must explain returns, and it does: checkpoints, missing/failed observations, observed_at vs snapshot_at, and null handling, with pagination delegated to a well-documented schema. The main omission is any pointer to sibling tools for cross-post comparison, which the age-comparison note gestures at but doesn't route.

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 67%: limit and cursor are thoroughly documented in the schema, but post_id carries only a UUID pattern with no prose. The description refers to 'a specific post' but adds no format, existence, or lookup details beyond what the pattern already implies, so it neither compensates for the gap nor adds meaning.

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

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

States a specific verb and resource — retrieving how a specific post's recorded engagement changed — and the scope (a single post, historical checkpoints). The phrase 'recorded counters are not live' implicitly contrasts it with get_live_summary/get_post, but it never names those siblings, so the differentiation is inferential rather than explicit.

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

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

Opens with a clear when-to-use trigger ('Use when checking how a specific post's recorded engagement changed after publication') and adds when-not guidance via the caveat that counters are not live totals. It doesn't name the alternative tools (get_live_summary, get_post) an agent should weigh against it, which keeps it short of a 5.

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

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

Annotations already declare readOnly, non-destructive, non-open-world, so the safety profile is covered. The description adds genuinely new behavior beyond that: results are bounded and truncated explicitly, and saved-query execution/editing are out of scope. It stops short of explaining the truncation threshold or error behavior for an unknown id, 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?

Three short sentences, usage condition front-loaded, then return shape, then boundaries. No filler, no restatement of the tool name, and every clause carries information an agent needs.

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

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

With no output schema, the description carries return-value burden and does so reasonably by naming membership, pins, saved-query references, and truncation. It omits error/not-found behavior and does not quantify the bounds, which keeps it just short of fully complete for a read 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?

There is one parameter with 0% schema description coverage; the schema only supplies a UUID pattern, not meaning. The description implies the parameter is the identity of a 'selected List' but does not restate or clarify the required UUID format or what happens if the id does not resolve. Baseline 3 for a thin single-param tool whose description adds only implicit meaning.

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

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

The description names a specific resource (a List's exact assets, authors, saved references) and what is returned (bounded membership, pins, saved-query references with truncation). It also explicitly distinguishes itself from the sibling query_list_activity and states which capabilities are not implemented, so an agent can tell it apart from neighbors without opening any schema.

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

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

'Use when a selected List's exact assets, authors or saved references are needed for follow-up research' gives an explicit activation condition, and the follow-on sentence names the alternative (query_list_activity) plus the excluded operations (saved-query execution and edits). When-to-use, when-to-use-something-else, and what-not-to-expect are all present.

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

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

Annotations already declare readOnly, non-destructive, closed-world, non-idempotent, but the description adds genuinely non-derivable traits: results are capped at the leading 30 groups, counts cover only adjacent stored windows, pending/unavailable is distinct from zero, and no full coverage or streaming is implied. These are the kind of limits an agent cannot infer from structured fields.

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

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

Four tight sentences, front-loaded with the use case, then the result shape, then the semantic caveat, then the scope boundary. Each sentence contributes distinct 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?

With no output schema, the description usefully sketches the return (counts for adjacent windows, top 30 groups) and rules out coverage assumptions. It is nearly complete for the calling decision, with the only real gap being the unexplained expected_input_stamp parameter.

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

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

Schema description coverage is 0% for both parameters, so the description carries the full burden, yet neither view_id nor expected_input_stamp is mentioned. The role of expected_input_stamp in particular is entirely opaque. The description contextualizes the Live view domain but adds no parameter-level meaning.

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

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

The description states a specific capability: returning counts of leading assets/voices for a configured Live view, limited to the leading 30 groups. It also differentiates from siblings by naming aggregate_posts and source posts as alternatives for larger rankings or narrative. It stops short of a crisp verb+resource opener, but the scope 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?

Opens with an explicit 'Use when' condition and routes the agent to alternatives with their selecting conditions ('use aggregate_posts for a larger ranking and source posts for narrative'). It also warns that pending/unavailable is not zero activity, which prevents a common misinterpretation of the 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 declare readOnly/destructive/openWorld/idempotent, and the description goes well beyond them: raw points paginate via next_point_cursor until null independently of the candle next_cursor, gaps are explicit, and no live quote or exact post-time price is implied. These are exactly the non-obvious traits an agent needs before calling.

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?

Usage grounds are front-loaded and each sentence carries information (windowing caveat, pagination rule, gap disclosure). It is dense and slightly cryptic in places ('point_summary explicitly identifies its entire requested time window') but wastes little.

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 10-parameter, no-output-schema read tool with a 40%-covered schema, the description supplies the missing behavioral context: pagination independence, explicit gaps, window semantics, and no implied live pricing. Date-range and required-ID semantics remain thin, but the agent has enough 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 coverage is only 40% across 10 params, so the description must compensate, and it does for the trickiest ones: omitting interval yields raw points while choosing an advertised interval adds candles and related posts, and it disambiguates the two independent cursors (next_point_cursor vs next_cursor). It leaves asset_id/series_id/date_from/date_to semantics largely to the schema, hence not a 5.

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

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

The description states a specific verb and resource ('Read one stored price series') and distinguishes itself from the sibling list_market_series by pointing at it as the source of series_id. It's clear an agent reads a single series rather than enumerating them, though the contrast with list_market_series is implied rather than spelled out.

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 opens with explicit usage context ('investigating the price timeline around posts or assessing a claim against later prices') and even gives scenario-specific configuration, e.g. restricting the window to published_at or later for a post outcome. No explicit when-not or exclusion is stated, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description goes meaningfully further by disclosing data-quality caveats an agent could not infer: source text is untrusted and may be incomplete, reposts retain the sharing author separately, and identity_mentions link UTF-16 spans to canonical assets.

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

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

The description is dense but front-loaded, opening with the usage trigger before moving to parameters and return contents. Every sentence carries distinct information; the only mild cost is that return-value semantics, identity_mentions and repost attribution are packed into a tight run of clauses.

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

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

With no output schema, the description must carry the return-value burden and largely does: it enumerates original_text, cleaned reading text, bounded media, relations, provenance, engagement/prices, and both mentions variants. The notable remaining gap is that the projection parameter's reading-vs-market behavior is left unexplained.

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

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

Schema description coverage is only 33%, so the description must compensate and it partly does: it specifies the canonical UUID requirement for post_id. However, it never explains the 'projection' enum (reading/market, undocumented in the schema) nor adds anything on 'detail' beyond what the schema text already says, leaving a real gap for two enum parameters.

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

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

The description states a specific verb+resource ('Use when verifying one selected source's original wording...') and emphasizes singularity ('one selected source'), which distinguishes it from the plural get_posts and search_posts siblings. It is clear about what is retrieved, though it never explicitly names the alternatives it is not.

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

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

Gives explicit when-to-use conditions: verifying original wording, quote/reply/repost attribution, or price context, plus the prerequisite (canonical post UUID required). It stops short of naming sibling alternatives (get_posts, get_price_context) or stating when NOT to use it, so it is clear context 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 cover the safety profile (readOnly=true, destructive=false, openWorld=false). The description adds real behavioral context beyond them: default projection omits prices, market projection supplies price evidence, missing items surface as not_found, and duplicate IDs are normalized. It does not explain the idempotentHint=false implication, which is the one uncovered trait.

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?

Five dense sentences, no filler, front-loaded with the use condition and the batch scope before the projection rule. Every sentence conveys a distinct operational fact.

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

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

With no output schema, the description takes on return-shape duty and does so: it enumerates the fields returned and describes the not_found and dedupe edge cases. Sourcing of post_ids and pagination/partial-failure behavior for large batches are the remaining gaps.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains both parameters meaningfully: post_ids as canonical IDs batched up to 50, and projection's reading-vs-market tradeoff (text/identities/quotes/provenance vs price evidence). It omits where canonical IDs are obtained and the UUID format constraint already in the schema.

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

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

States a concrete verb and resource ('read up to 50 canonical post IDs in one request') and pins the content retrieved (full retained text, identities, quotes, provenance). The batch-of-50 framing implicitly separates it from the singular get_post sibling, 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?

Opens with a clear use condition ('when reading original claims, conditions or quoted context from selected search results') and adds an in-tool alternative rule ('choose market for price evidence') plus a reuse instruction to avoid redundant calls. It stops short of naming the sibling tools (search_posts, get_post) or stating when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the return payload shape (exact USD decimals, source posts, provider/series identities, fixture labels) and an explicit statement of what the data is NOT (candles, live quotes, exact publication prices). It stops short of describing pagination semantics, which the schema carries 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?

Two sentences, zero waste, and the usage trigger is front-loaded ahead of the return description and the sibling routing. Every clause either tells the agent when to call it or what it gets back.

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

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

With no output schema, the description correctly takes on the burden of describing return values, and it does so concretely. Five parameters at 40% schema coverage leave the three required date/asset arguments under-documented, but the capture-time framing and the sibling routing cover the main decision an agent must make.

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

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

Schema description coverage is only 40% – asset_id, date_from and date_to have no schema prose, only patterns. The description partially compensates by framing the range as a 'capture-time window', which clarifies date_from/date_to semantics versus publication time, but it adds nothing about asset_id being a UUID or about the cursor/limit pair beyond what the schema already says.

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 ('inspecting the stored prices captured with posts for an asset') and pins the scope to a capture-time window. It explicitly names the sibling tools it is not (list_market_series/get_market_history), so an agent can route without opening either schema.

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

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

Gives an explicit trigger ('Use when inspecting the stored prices captured with posts...') plus an explicit alternative and exclusion set ('Use list_market_series/get_market_history for a price timeline; these captures are not candles, live quotes or exact publication prices'). When-to-use, when-not-to-use and the competing tool are all named.

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

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

The annotations already declare the read-only, non-destructive, closed-world safety profile, so the bar is lower; the description still adds value beyond them by disclosing that access is authenticated but free, that the account ID is stable, and that the call never selects or replaces another account (a side-effect guarantee absent from the annotations). It does not mention rate limits or failure modes, which keeps it out of 5 territory.

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

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

Three short sentences: identity first, then cost/auth and return fields, then usage boundary. Every sentence carries distinct information with no repetition of annotation data.

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 detail is unnecessary; with that covered, the description supplies identity, auth/cost context, usage boundaries and non-side-effect guarantees. Nothing an agent needs to invoke a zero-parameter read correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify beyond that. It correctly implies no inputs are needed rather than hinting at any configuration.

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 ('Identify the CryptoSocials account connected to this app') and immediately enumerates the returned fields (stable account ID, display name, email). It also carves out its scope against the large family of research siblings ('not crypto research'), so an agent can distinguish it without opening a schema.

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

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

Gives explicit when ('account selection and connection help') and when-not ('not crypto research') guidance, which is unusually clear for this tool set. It stops short of naming a concrete alternative sibling to use for the excluded crypto-research cases, which is what a 5 would require.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: the call is free and consumes no research credits, and it is guidance rather than a research request. It does not describe return shape, but that is acceptable given no output schema.

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

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

Four short sentences, front-loaded with the usage trigger and the key exclusion. Every sentence carries information, though the middle sentences about overview vs. topic selection could be tightened into one.

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

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

For a zero-required-param, no-output-schema guide tool, the description adequately covers when to call it and that it is free. However, the topic enum's semantics are entirely unexplained in both schema and description, which is the main gap an agent faces when deciding which topic value to pass.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only implies the topic parameter's role ('Overview introduces combinable topics; choose a topic for more detail') and names the default implicitly; it never explains what the 11 enum values (live, coins, chains, coverage, data, etc.) each yield, leaving the agent to guess from terse enum strings.

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

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

The description states a specific verb+resource and clarifies the tool's nature: it is 'Free guidance, not a research request' that explains what CryptoSocials can investigate. It distinguishes itself from research-query siblings by framing itself as meta-guidance, though the scattered phrasing ('overview introduces combinable topics') is slightly less crisp than a clean purpose statement.

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 triggers are given ('Use when asked what CryptoSocials can investigate, for research ideas, about its evidence or how research credits work') plus an explicit exclusion ('A specific question can proceed directly without this call'). This is exactly the when-to-use/when-not guidance the dimension asks for.

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

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

Annotations already establish readOnly/destructive/idempotent, and the description adds real behavioral context on top: the call is a free/no-credit-cost read, the balance is shared across all keys, MCP, REST and Archive, the period end is not a guaranteed renewal, receipts are not conversations or full question costs, and the current call is recorded only after preparation. These are non-obvious operational facts an agent cannot derive from the annotations.

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

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

The most important element, the when-to-use trigger, is front-loaded in sentence one, and the remaining sentences each convey distinct facts (sharing, renewal, receipts). The field-enumeration sentence is a dense run-on that is harder to parse than necessary, 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?

With no output schema, the description compensates by enumerating the returned keys (credits.limits, transport_limits, allowance, used/pending/remaining, receipts) plus two important caveats about renewal and receipt meaning. It stops short of a clear return structure, but it is strong for a read-only tool whose safety profile is already in the annotations.

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 limit and cursor both fully documented in the schema (paging, cursor reuse, unchanged query args). The description only alludes to "paged receipts" without adding format or semantics beyond the schema. Baseline 3 is appropriate when the schema already carries the parameter burden.

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

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

The first sentence names a concrete verb (checking) and resource (research-credit balance, spending, research budget), so the tool's job is immediately legible. No sibling tool deals with credits, usage, or receipts, so it is cleanly differentiated from the surrounding catalog. An agent can pick 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?

"Use when checking research-credit balance, spending or a requested research budget" gives explicit triggering conditions rather than vague implied usage. There are no competing credit-related siblings to disambiguate against, so no exclusion clause is needed. Missing only a when-not case, which is minor here.

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 destructiveHint=false, so safety is covered; the description still adds value by disclosing the UUID ordering and that the call does not advance seen positions, which is not derivable from the annotations. It stops short of describing result shape or paging side effects.

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

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

Three short sentences, front-loaded with the usage trigger before the return behavior and the edge-case instruction. No filler, though the 'Does not modify Lists' clause partially repeats the readOnly annotation.

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 no-required-parameter read-only listing with no output schema, the description covers the trigger, return contents, ordering, and the empty-List case. It leaves the after_id pagination contract entirely to the schema and says nothing about error or auth conditions, so it is adequate but not fully complete.

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

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

Schema description coverage is only 50% – limit is well documented in the schema, but after_id has nothing beyond a UUID pattern. The description never mentions either parameter; its 'ordered by UUID' phrase hints at after_id's format but does not explain how to use it, so it fails to compensate for the coverage gap.

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

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

The description states a specific verb and resource: it returns the connected account's saved List directory, ordered by UUID. That is clear enough to separate it from a single-List tool, though it never names the sibling (get_list) an agent should use for a specific List.

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 one when-to-use trigger (researching followed coins/Crypto Voices) and a fallback instruction when no List exists (ask for named interests). However it offers no routing to alternatives such as get_list or query_list_activity, so the usage guidance is implied rather than explicit.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real context: the results are 'public research views, not customer Lists', and the payload carries windows plus a freshness signal — useful traits not present in the structured fields.

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

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

Three short sentences, front-loaded with the usage trigger, then the scope caveat, then the next-step routing. Every sentence carries distinct information with no padding.

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

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

With no parameters, no output schema, and annotations already declaring the read-only profile, the description supplies the missing pieces: what the views are, that they are not customer Lists, what the response contains (windows, freshness), and how to proceed afterward. Nothing an agent needs 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?

The tool takes zero parameters with 100% schema coverage, so parameter semantics are trivially satisfied and the baseline is 4. Nothing in the description is needed or misleading regarding inputs.

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

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

The description names a specific verb+resource ('configured Live discussion windows') and immediately demarcates scope by stating these are 'public research views, not customer Lists', distinguishing it from list_lists and the get_live_summary sibling. An agent knows exactly what this enumerates.

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 opens with an explicit trigger ('Use when discovering ... for a recent catch-up') and routes the agent onward: 'Read the returned windows and freshness before choosing get_live_summary.' Both when-to-use and the follow-on alternative are stated, not inferred.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds non-obvious result semantics beyond that: sources 'remain separate,' it does not pick a winning price, and it does not backfill missing history — useful expectations for an agent consuming the output.

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

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

Three tight sentences with the trigger condition front-loaded, followed by the return summary and the exclusion. No filler, though the phrasing is dense and could be slightly easier to scan.

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

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

With no output schema, the description supplies the return shape (series identities, candle intervals), and pagination mechanics are already documented in the cursor/limit parameter descriptions. Annotations cover the safety profile, so 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 coverage is only 40% — asset_id, date_from and date_to carry regex patterns but no descriptions. The description partially compensates by tying inputs to 'an exact asset and UTC period,' but it adds no detail on the date format, range semantics, or required-ness beyond what the schema already enforces.

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 and output: it 'Returns series identities and available candle intervals' for a given asset and UTC period. That is more specific than the name alone, but it never names a sibling (e.g. get_market_history) to distinguish this listing tool from the market-history retrievers.

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 when: 'Use when choosing the stored price source for an exact asset and UTC period before comparing posts with prices,' plus a when-not: it 'does not select a winning price or fetch missing history.' It stops short of naming an alternative tool to use instead, so it is context without explicit routing.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds genuine beyond-annotation context: first-page whole-window member counts with an equal-duration preceding comparison, and the paging invariant that retained paging requires unchanged filters, limit and List revision. It also explicitly disclaims side effects ('Does not change Lists or create alerts').

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 'Use when' trigger, then tightly sequenced: what it returns, the first-page comparison payload, the efficiency hint, the price-history pointer, the paging invariant, and the side-effect disclaimer. Dense but nearly every sentence carries decision-relevant information.

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

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

For a 19-parameter tool with no output schema, the description does the important work of describing the distinctive return payload (member counts, preceding comparison, activity.comparisons) and the state invariants for paging. Remaining gaps are minor since the schema carries the per-parameter semantics at 79% coverage.

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 79%, so the schema already documents most parameters (mode, cursor, detail, order, date bounds). The description reinforces the paging contract ('unchanged filters, limit and List revision') but adds no syntax, format or constraint detail beyond what the schema states, which is the expected baseline 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 states a specific verb and resource: reviewing what changed among assets and Crypto Voices in a saved List, returning posts matching author OR asset members without duplication. It is clearly distinguishable from plain post search, though it never names the closest siblings (discover_activity, compare_activity) to sharpen the boundary.

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

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

The opening clause gives explicit when-to-use context ('reviewing what changed... in a saved List') and routes away from adjacent work: 'Read price history separately as needed' and 'Use activity.comparisons rather than rereading every member.' No explicit when-not-to-use or named alternative tool, so it falls 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 cover the safety profile (readOnly, non-destructive, closed-world), so the description's job is to add resolution semantics — which it does: a symbol alone is not proof, the intended candidate must be confirmed, and unknown/merged states remain explicit. This tells the agent to expect ambiguous multi-candidate results, which annotations do 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?

Front-loaded with the triggering condition and packed with actionable guidance in a compact space. The clipped final sentence ("Unknown/merged states stay explicit") is slightly terse but still parses.

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

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

With no output schema, the description compensates by signaling that resolution may return candidates requiring confirmation, and the schema carries pagination via cursor. Auth/permission context is absent but the tool is a read-only lookup, so the gap is minor.

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

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

Schema description coverage is 100%, so the schema already documents query, limit, and cursor. The description's format hints ($BTC, #BTC) largely overlap the schema text, adding little beyond it; 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 — resolving a named coin, ticker, or contract to its exact identity. It is clearly distinguishable from siblings like get_asset (fetch details for a known asset) because the description frames this as identity lookup from an ambiguous input.

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

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

"Use when a user names a coin, ticker or known contract and research needs its exact identity" gives a clear triggering condition, and the retry guidance (split a combined name/ticker query if nothing is found) is practical. It stops short of naming alternative tools or stating when not to use it.

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

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

Explains the non-obvious side effect that justifies readOnlyHint=false: an exact missing @handle lookup can record the handle locally for coverage review, with no provider call or promise of addition. This is exactly the kind of write-behavior disclosure annotations cannot convey on their own.

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

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

Four dense sentences, front-loaded with the usage trigger and alternative, then the identity caveat and the write side effect. Every sentence earns its place, though the final clause about coverage review is wordy enough to slow the read slightly.

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

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

No output schema, but the description pairs with a rich cursor/limit schema to cover pagination, and it discloses the mutation-like side effect and identity-confirmation caveat. Return-shape detail (candidate fields, ranking) is left implicit, which is the only real gap for a 3-param search 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 query/limit/cursor semantics are already documented. The description restates the accepted query forms (handle, platform user ID, display-name prefix) and adds a note about exact missing handles, but adds little syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource (find author candidates) and immediately distinguishes the tool from get_author, which handles profile/posts/activity. An agent can pick between the search and lookup tools without opening either schema.

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

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

Gives an explicit trigger condition ('when the user wants to research an X author by handle or name') and names the complementary tool with its role ('then use get_author for profile, posts and activity'). Adds a caution that name matches may be historical and the intended identity should be confirmed.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that: it discloses the return shape (text previews, source links, IDs, observed metrics) and the bounded/stored-vs-live nature of the search. It omits auth/rate-limit context, and mode/cursor behavior lives only in the schema, 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-loaded with the trigger, then purpose, then targeted parameter pointers, then the boundary condition. Every clause earns its place and no sentence is filler, even though the description is dense.

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 18-parameter tool with no output schema, the description supplies the essentials: purpose, main routing alternatives, approximate return contents, and the live-search limitation, while 83% schema coverage fills in the rest. It leaves mode/pagination semantics entirely to the schema, which is a minor gap.

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

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

Schema coverage is 83%, well above the threshold where the schema carries the load, so baseline 3. The description still adds usage-oriented meaning for two key params (order=time_balanced for broad discussion, detail=market for capture-price context), which is more than merely restating 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 ('Search stored posts in a bounded UTC window') and adds scope ('Crypto Voices', UTC-bounded). It distinguishes itself from get_post/get_posts (full-text verification) and from live tools ('No live X search'), so an agent can separate it from all 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?

Opens with an explicit when-to-use trigger ('finding what Crypto Voices said... before, during or after a period of interest'), routes to alternatives (get_post/get_posts for retained full text) and gives an explicit exclusion ('No live X search'). Nothing about selection 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.