OwlChart

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description usefully adds the 30-symbol cap and per-member ownership scope, but says nothing about duplicate handling, error behavior when the cap is exceeded, or why the operation is non-idempotent as the annotation claims.

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

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

A single sentence that front-loads the operation, then the resource, examples, and limit. No filler, nothing to trim.

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 one-parameter add tool with no output schema, the description covers the action, the target, accepted value shape, and the hard limit. Only marginal gaps remain: duplicate behavior and what happens at/over the 30 limit.

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 0%, so the schema only conveys that 'symbols' is a string array. The description compensates by defining what a symbol is (a market ticker), giving concrete examples, and stating the 30-item ceiling that the schema does not encode.

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 ('Adds') plus resource ('markets ... to this member's own watchlist') and scopes it with examples (BTC, WLFI, AAPL). The verb contrast with remove_from_watchlist and get_watchlist makes it unambiguous which operation this is 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?

The description implies its context (curating one's own watchlist) and supplies a real usage constraint ('up to 30'), but names no alternatives and gives no explicit when/when-not guidance relative to get_watchlist or remove_from_watchlist.

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 write/openWorld/non-idempotent/non-destructive; the description adds the substantive traits an agent actually needs: the entry is locked at the live price and time, it is scored with the Brier score, it pays $OWL points that carry no value and are non-transferable, only one open call per market per kind is permitted, and the next-open grading behavior for closed equity markets is stated in the market param. That is real settlement and side-effect disclosure beyond structured fields.

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

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

The critical scope statement is front-loaded and every sentence carries information; there're no filler pleasantries. It is dense to the point of being run-on, packing kinds, scoring and constraints into two long sentences, so structure helps less than it could.

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, low-coverage write tool with no output schema, the description covers the decision-relevant surface: what is recorded, how it locks and settles, what it pays out, and the duplicate constraint. Missing pieces are the return value (accepted call id, entry price, confirmation) and the hours semantics/default, which an agent would want before calling a touch forecast.

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 schema coverage at 13%, the description has to compensate and mostly does: it explains the kind enum, the per-kind meaning of side, the meaning and bounds rationale of probability (0.50-0.99, scored by Brier), what agent_name controls, and that up/down default to the liquidity magnets for touch calls. Gaps remain on 'hours' (only obliquely referenced as 'within hours', with no mention of the 1-72 range) and on the up/down levels' format.

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+mechanism: 'Records a forecast in the Owl Arena, locked at the live price and time.' It then enumerates the three call kinds (close, touch, etf) with their side values, which distinguishes it instantly from siblings like arena_my_forecasts and arena_leaderboard that read the same domain.

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?

Each 'kind' is paired with the condition that selects it (24h directional close, first level touched, next daily ETF net-flow sign), which is explicit when-to-use guidance at the variant level. It also states the 'one open call per market per kind' constraint and points to search_markets for market ids. What's missing is explicit routing against siblings (e.g. check arena_markets first, or review existing calls with arena_my_forecasts) and any when-not-to-use case.

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 domain semantics beyond that: the ranking metric (Brier skill), the minimum sample threshold (3 graded calls), and the precise definition of 'consensus' (pooled probability of closing higher in 24 hours). What is missing is any note on result size, ordering of the three sections, or freshness of the 'live' consensus.

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?

One dense sentence of roughly forty words with no filler, and the primary resource (leaderboard ranked by Brier skill) is front-loaded. The nested parentheticals make it read as a fragment rather than a directive, but nothing should be cut.

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

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

With no output schema, the description carries the burden of explaining returns; it identifies three distinct data sets but not how they are structured or nested in the response. For a read-only, zero-required-param tool this is adequate but leaves ambiguity about what an agent actually receives back and how 'live' is refreshed.

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 single parameter 'limit' has 0% schema description coverage and is never mentioned in the description. It is unclear whether limit caps leaderboard rows only, or also affects the consensus and track-record sections. With optional-defaulted and low-stakes parameters this is a minor gap, but the description does nothing to compensate for the undocumented 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 names the specific resource and its contents: an Owl Arena leaderboard ranked by Brier skill, a live per-market consensus (pooled probability of closing higher in 24 hours), and a consensus track record. The 'Owl Arena' scoping plus the Brier-skill ranking distinguishes it from the generic siblings get_leaderboard and get_track_record, though it never explicitly contrasts itself with them. It lacks an action verb, but the returned data is unambiguous enough for an agent to select it.

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?

There is no statement of when to use this tool versus get_leaderboard, get_track_record, arena_markets, or arena_forecast, and no exclusions or prerequisites. The parenthetical '(agents and members with at least 3 graded calls)' is a data inclusion rule, not usage guidance. An agent must infer the selection context entirely.

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 behavioral context by disclosing the returned content areas: live price, liquidity magnet levels, next ETF flow day, call kinds, rules, and that grading comes from OwlChart's own candles. It does not discuss freshness guarantees, rate limits, or response shape beyond a content list.

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

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

The description is a single front-loaded sentence that enumerates the returned domains without filler. The final short sentence about OwlChart grading adds relevant context rather than repeating the title.

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

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

With no parameters and no output schema, the description must explain the return contents, and it lists the main components an agent would need: markets, live prices, liquidity presets, ETF flow day, call kinds, and rules. It is sufficient for invoking a zero-parameter reference tool, though it could state whether this is a static reference endpoint or a live snapshot in more explicit terms.

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 has zero parameters, so there are no parameter semantics to explain. The baseline for zero-parameter tools is 4, and nothing in the description undermines that.

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 the resource clearly: the markets an agent can make a call on in the Owl Arena, along with related reference data such as call kinds and rules. It is more specific than the title alone and distinguishes itself from action-oriented siblings like arena_forecast or show_chart, though it never uses an explicit verb like 'list' or 'return'.

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 phrases such as 'markets an agent can make a call on' and 'presets for a touch call,' which suggest this is reference data to consult before making an arena call. However, the description gives no explicit when-to-use guidance and does not contrast this tool with siblings like arena_forecast or search_markets.

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=false already establish the safety profile, so the description's job is lighter. It adds real value by disclosing the payload scope — both open and graded calls plus derived metrics (Brier score, calibration, streak, points) — so an agent knows this is a composite stats read rather than a raw call list.

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?

One compact sentence, front-loaded with the resource and followed by the enumerated contents. No filler, no restatement of the tool name.

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 enumerates the returned fields, and the read-only/single-filter shape is simple enough that little else is required. The remaining gap is positional: it doesn't clarify how this differs from the several other score/track-record tools in the 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 0%, so the description must carry the single `status` parameter, and it only obliquely does so via "every call open and graded." The enum values (all/open/graded) are largely self-explanatory, but the default behavior and what 'graded' implies for scoring are not spelled out.

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: fetching "this account's Owl Arena record," and enumerates the contents (open/graded calls, accuracy, Brier score, calibration, streak, $OWL points). It doesn't distinguish itself from overlapping siblings like get_owl_score, get_track_record, or arena_leaderboard, which an agent may conflate with this.

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?

"This account's" implies it is the personal/session-scoped view as opposed to arena_leaderboard or arena_markets, but that contrast is never made explicit. There is no statement of when to prefer this over get_track_record or get_owl_score, and no prerequisites mentioned.

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 description discloses the key state change that explains the readOnlyHint=false annotation: it 'marks them read'. It also conveys incremental semantics ('since the last check'), which aligns with idempotentHint=true. It does not mention any permission/auth requirement or whether the read-marking is reversible, 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?

A single sentence with a specific action, scope, and side effect, front-loaded with the return value. Nothing is redundant or padded.

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

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

With no parameters, no output schema, and annotations covering the safety profile, the description carries what an agent needs: what is returned, the time window, and the side effect. A brief note on the alert payload or on how it differs from list_alerts would close the remaining 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter surface for the description to compensate for.

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 ('Returns this member's alerts that fired') plus scope ('since the last check'), which is concrete enough to act on. However it does not differentiate itself from the sibling list_alerts, so an agent must guess which of the two alert-listing tools fits.

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

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

The phrase 'since the last check' implies the polling/incremental use case, which is useful implied guidance. But it never names list_alerts or states when to prefer one over the other, and gives no prerequisites or exclusions.

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

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

Annotations only declare the safety profile (readOnly=false, idempotent=false, destructive=false); the description adds substantive behavior the annotations cannot convey: one-minute checking, one-shot firing, the 10-alert cap, and webhook delivery to Discord/Slack/Zapier/Make/n8n or any https hook.

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?

Dense but front-loaded, with purpose stated first and then the type catalog. Every clause carries necessary information, though the semicolon-delimited wall of type definitions would scan better as a list.

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 5-parameter creation tool with no output schema, the description covers trigger semantics, delivery, limits, and per-type parameter meaning, so nothing essential to 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?

With only 60% schema coverage, the description compensates heavily: it defines what 'threshold' means per type (dollars, percent, millions, or unused for magnet_hit/reg_keyword), when it may be negative, that 'coin' is ignored for stablecoin_mint and reg_keyword, that 'note' is the keyword for reg_keyword, and that large_transfer takes a token hub id — far beyond the terse schema descriptions.

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 ('Sets an alert on OwlChart data') plus the polling cadence, which immediately distinguishes it from check_alerts, list_alerts and delete_alert. An agent can identify this as the alert-creation tool 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 explains the operational context (fires when condition met, one-shot, up to 10 active alerts per member, optional webhook delivery) and points to check_alerts for observing results. It stops short of explicitly routing the agent to siblings (e.g. 'use delete_alert to cancel'), but the surrounding 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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the id provenance and the member-scoped ownership constraint, but says nothing about irreversibility, failure behavior for an unknown id, or effects on triggered 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?

A single short sentence that front-loads the action and its key; every clause earns its place with no filler.

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

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

For a one-parameter deletion tool whose annotations already convey destructiveness and idempotency, this is close to sufficient. The main remaining gap is what happens on an invalid or already-deleted id, which matters more here because idempotency is asserted but not explained.

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?

Only one parameter and schema description coverage is 0%, so the schema gives no semantics. The description partially compensates by telling the agent the id is an alert id obtained from list_alerts and is member-scoped, but it adds no format details (UUID vs numeric) or constraints.

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 ('Deletes ... alerts') and its lookup key ('by its id'), which cleanly separates it from create_alert and list_alerts. It does not name those siblings explicitly, so it falls short of full differentiation.

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 parenthetical '(from list_alerts)' gives an implicit workflow hint about where the id comes from, which is real usage guidance. However, there is no explicit when-to-use vs when-not, no mention of confirmation requirements, and no exclusivity guidance against alternatives.

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 meaningful auth context (members key vs a purchased reader pass), but says nothing about pagination, feed contents, or return behavior.

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

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

Two sentences, purpose front-loaded, no wasted clauses. The embedded reader-pass URL is dense but adds actionable detail rather than filler.

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

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

There is no output schema, so the description carries the return-value burden, yet it never describes what a feed or room list contains, nor the effect of 'limit'. Adequate on access modes, incomplete on what comes back.

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

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

Schema coverage is only 33% and the description must compensate, but it only clarifies 'key' (members room key) and the reader-pass mode. The 'room' and 'limit' parameters remain undocumented in both the schema and the description, leaving a real gap.

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

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

States a specific resource (collaborative rooms) and two clear operations: listing public rooms or reading one room's feed. An agent can tell this is the read side of the room feature. It does not explicitly contrast with the likely write sibling post_to_room, so it falls short of full sibling differentiation.

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?

Explains the two access paths – a room key for members or a reader pass – which implies when to use each. However it gives no when-not guidance and never points away from alternatives like post_to_room for writing, leaving routing to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior: the latest reading is always returned, while full history, per-stock closes, and CSV are gated behind the AI Metric pass (a paywall/entitlement constraint not visible in annotations). The closing disclaimer frames the output as data, not advice.

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

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

The core purpose is front-loaded, and the gating note plus disclaimer are useful. However, the opening is a single comma-spliced run-on cramming the 47-stock sector list, six possible states, and seven sub-metrics into one sentence, which costs readability without adding 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?

With no input parameters and no output schema, the description carries the burden of explaining what comes back, and it largely does by enumerating the score, its states, and the component metrics. It also discloses the entitlement boundary for history/CSV. Some gaps remain about freshness cadence and update frequency, but an agent has enough to invoke it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description also names the concrete fields surfaced (state, momentum, breadth, distance from high, relative strength, correlation, bubble heat), which is return-content detail rather than parameter 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 exactly what the tool returns: one 0-100 score for the whole AI market plus its qualitative state and sub-metrics. It is clearly a read of a composite AI-market indicator rather than a generic market call. It does not, however, differentiate itself from near-siblings such as get_owl_score or get_market_radar, which an agent could easily confuse it with.

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

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

Usage is only implied: an agent can infer it should call this when it wants the AI-sector composite reading. There is no explicit when-to-use, when-not-to-use, or guidance on choosing this over get_owl_score, get_market_radar, get_carv, or get_data_pack. The one gateway note ('the full history... need the AI Metric pass') hints at an upgrade path but is not framed as usage 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 API version (v5.691) and hub/docs URLs, which is useful context, but discloses nothing about auth, rate limits, pagination, or error behavior beyond what annotations 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?

A single dense paragraph with the tool's nature front-loaded and each mode's payload enumerated. The parenthetical lists are long but each element earns its place by telling the agent what it will receive.

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

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

No output schema exists, so the description carries the return-value burden, and it does so by enumerating the data returned per mode. It stops short of describing the response shape/format or any limits, but is largely complete for a 2-param hub tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further: it spells out the market field list, the contract addresses scope, the link inventory, and reiterates days' 2–1000 range/default and that it applies to history only. That meaningfully enriches the bare enum descriptions in the schema.

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

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

States a specific resource ($CARV market/contracts/links/@carv_official data) and enumerates exactly what each mode returns. The verb+resource framing ('The $CARV developer API as one tool') is unambiguous and clearly distinct from generic siblings like get_price_history or search_markets.

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

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

The description details what each `what` value yields (market, history, contracts, links, x), which helps mode selection, but never says when to use this tool versus siblings such as get_price_history or get_price_history/show_chart. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and scope profile is covered. The description adds useful context that results carry dates and come from a 'live' tracker (implying freshness), but it says nothing about result volume, pagination, or update cadence beyond the word 'live'.

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

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

A single sentence, front-loaded with the subject matter and backed by a parenthetical of concrete examples. No filler or restatement of the tool name.

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-argument, no-output-schema news tool the description covers what the agent needs: source, topic scope, named entities, and the presence of dates. It would be complete at 5 if it hinted at how much content is returned or how recent 'latest' is.

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, which is the baseline-4 case per the rubric. The description correctly signals that no filtering is required, and nothing in the schema needs compensating for.

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 (crypto market structure law and regulators) and enumerates the concrete content covered: the CLARITY Act and related bills, SEC and CFTC items, with dates. This clearly distinguishes it from every sibling, all of which return market/pricing data (flows, funding, liquidations, orderbook) rather than regulatory news.

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

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

Usage is implied by the content scope — call this for regulatory/legislative updates — but the description never states when to use it versus alternatives, nor any exclusions. With no competing regulatory sibling the ambiguity is low, so 3 is fair rather than a penalty.

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

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

Annotations cover safety (readOnlyHint, openWorldHint), but the description adds real behavioral context beyond them: the Builder/Scale/PRO tier requirement, the fact that a subscription check gates the download address, and the two-step flow where the signature/address is returned here and the file itself is fetched with the same Bearer token. It omits rate limits or format details of the signature, hence 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 dense sentences, front-loaded with the pack contents before mode and auth details. The embedded example URL consumes space but is functional, and nothing is redundant given the schema carries no 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 no output schema and a single bare enum parameter, the description covers the essentials: what the packs contain, the list-versus-download branching, the tier prerequisite, and the shape of the return (download address plus signature). Only minor gaps remain around response format specifics.

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 burden, and it does: it maps the pack values to their markets (BTC/ETH/SOL/XRP/WLFI → *-core), gives a concrete example (btc-core), and explains the behavior when the parameter is omitted. The enum values themselves are only partially self-explanatory, which keeps it from a 5.

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

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

States a specific resource (historical data packs per market) with concrete contents: 730 daily candles, 1000 hourly candles, daily open interest across 13 exchanges, and daily spot ETF flows as signed JSON or CSV. This clearly distinguishes it from siblings like get_price_history, get_open_interest, and get_etf_flows, which expose those datasets individually rather than as bundled packs.

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 two operating modes are explained (no pack = list packs; with a pack = retrieve download address), which is implicit usage guidance. However, it never states when to prefer a data pack over the sibling point-read tools, and the tier-gating condition is mentioned only in passing rather than framed as a prerequisite the agent must check.

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 goes further by disclosing the Bearer owlpass_ auth requirement, the purchase endpoint needed to obtain a pass, and a scope disclaimer ("Data and analysis only"). It does not clarify the two-mode behaviour (what is returned when the pass is absent) or any 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?

Two sentences carrying a lot of load: the resource and its fields first, then the pass-gated retrieval behaviour and the disclaimer. The embedded /api/desk-strategies/{id}/buy path is unusual inside a tool description but earns its place by explaining how a pass is obtained.

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

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

With no output schema and only two fully documented optional parameters, the description supplies most of what an agent needs: the auth model, the paid-content flow, and the returned content types. The remaining gap is the ambiguity about what a call without a pass returns, which matters for a tool whose parameters are all optional.

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 documented and the baseline is 3. The description reinforces the meaning of strategy (an id tied to a pass) but adds no format or syntax detail for the desk slug, so it does not exceed what the schema 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 names the resource (strategies sold by verified trader desks on OwlChart), enumerates the listing fields returned (title, desk, track record, price), and describes a second pass-gated mode that returns trader instructions and an alert bundle. That is enough to separate it from siblings like get_track_record or get_owl_score. It falls short of 5 because it never states a clear verb and blurs two operations (listing vs. pass-gated retrieval) into one tool.

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 implies when the different behaviours apply: call with a strategy id you hold a pass for to get the instructions, and it points to /api/desk-strategies/{id}/buy for acquiring a pass. However, it never says what happens without a pass, whether the listing mode requires any parameters at all, or when an agent should pick this over adjacent tools such as get_track_record. Usage is implied rather than stated.

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

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

readOnlyHint=true and openWorldHint=true already tell the agent this is a safe, open-world read, so the bar is lower. The description usefully adds that results are aggregated from 'three raw sources' and includes an interpretive 'verdict', but says nothing about freshness semantics, rate limits, or result granularity.

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

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

A single front-loaded sentence that leads with the resource and stays compact. The ellipsis, nested quotes and parenthetical fund examples are slightly informal but do not waste 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?

With no output schema, the description must describe returns, and it does sketch them (fund-by-fund flows, recent days, a verdict). However, 'recent days' is imprecise and nothing is said about output shape or time coverage, leaving gaps for a data-retrieval 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 0%, so the description must carry the parameter meaning; it partly does by stating 'Bitcoin or Ethereum', which maps to the btc/eth enum. It does not mention the default of btc, and with a single enum param the added value is modest.

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 (Bitcoin or Ethereum spot ETF flows, fund by fund) and even cites concrete funds (BlackRock IBIT/ETHA, Fidelity, Grayscale), so an agent immediately knows what it retrieves. It is clear but doesn't explicitly position itself against siblings; the distinct resource alone carries the differentiation.

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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only says what data exists, leaving the agent to infer that it should call this for ETF-flow questions rather than get_price_history or get_market_radar.

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 a genuinely useful non-schema behavior: the required subscription tier. However, it does not explain verdict semantics, data freshness, or rate/refresh behavior, so it adds only modest value 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?

Tightly written: one sentence enumerating the returned fields, one sentence for the access prerequisite. Front-loaded with the core deliverable and no filler, though it is a single dense clause that compresses several outputs.

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

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

With no output schema, the description carries the return-value burden and does it well, enumerating verdict states and the specific metrics returned. The main gap is the absence of explicit differentiation from get_etf_flows, but for a 1-param read-only tool it is largely 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?

One optional enum parameter (BTC/ETH) with 0% schema description coverage, but the enum values are self-explanatory and the description ('BTC and ETH spot ETF verdict') confirms the allowed values. It adds no syntax, default, or behavioral detail about the parameter, so it sits at the schema-lifting 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?

States a specific resource and output: an ETF verdict (BUYING/SELLING/MIXED) plus day/7d/30d flows, consecutive-day run, BlackRock holdings and daily history. It is clearly the analytical 'verdict' layer rather than raw flows, though it never explicitly contrasts itself with the sibling get_etf_flows, so the agent must infer the distinction.

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 only guidance is an access prerequisite ('Needs the Flows Terminal pass, Builder, Scale or PRO'), which is useful context but not when-to-use guidance. It never says when to prefer this over get_etf_flows or get_global_flows, leaving the choice 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 and openWorldHint, so the safety profile is covered. The description adds genuine behavioral context beyond that: the data spans every exchange OwlChart reads, and the sign convention is decoded ('Positive means longs pay shorts'), which is essential for interpreting results.

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

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

One tight sentence with the resource front-loaded and no filler; the sign convention follows naturally. It is efficient, though slightly terse given what remains undocumented.

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 simple read-only tool with one parameter and no output schema, the description covers what is returned (per-exchange rates) and how to read it. It omits freshness/update cadence and the coin identifier format, which is the main residual gap.

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

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

Schema coverage is 0%, so the description carries full responsibility for the single parameter, yet it only implies that 'coin' exists and never states the expected format (ticker symbol vs. full name). An agent must guess the identifier convention.

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 ('Perpetual funding rates for a coin') plus the scope of coverage ('on every exchange OwlChart reads'). It distinguishes itself from rate-adjacent siblings like get_open_interest and get_liquidations, though it never names an alternative 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?

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The phrase 'straight from the exchanges' hints at live source data but stops short of any real routing advice.

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 them by disclosing the required pass tier and the hourly-series-with-daily-roll-ups granularity. It stops short of describing pagination, response size, or what happens when the entitlement check fails.

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?

Leads with the terminal name and then front-loads the data coverage before the access caveat, so the most important information is early. It is a single dense run-on sentence, but nearly every clause carries a distinct data type rather than filler.

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

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

There is no output schema, and for a multi-source aggregator the description omits any indication of response shape, default behavior when asset is omitted, or how the series are keyed. Coverage of data content and access requirements is solid, but the call-and-interpret picture is incomplete.

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

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

Schema coverage is 50% (asset is described, window is not), so the description is expected to compensate. It does list the window values (24h/7d/30d/90d) and the asset universe (BTC, ETH, SOL, WLFI), but since windows are already an enum in the schema this adds little, and it does not explain what omitting asset returns or what a 'daily roll-up' means for the series.

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 retrieval target and enumerates exactly which series it covers (stablecoin supply, tokenised gold/treasuries/stocks, ETF flows, open interest) plus time windows, so the resource is unambiguous. However, it never distinguishes itself from near-duplicate siblings like get_etf_flows, get_stablecoin_net_mint, get_open_interest or get_money_flows, which it appears to supersede.

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 only usage guidance is an entitlement gate ('Needs the Flows Terminal pass, a Builder or Scale pass, or PRO'), which tells the agent about access, not about when to pick this tool over its many overlapping siblings. There is no statement of when this aggregate is preferable to the single-metric tools, and no exclusions.

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

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

Annotations only declare readOnlyHint and openWorldHint. The description adds substantial behavior beyond that: it is live/real-time data sourced directly from regulators, it enumerates the exact market-summary contents returned, and it discloses the licensing constraint that blocks CA/AU/HK/IN. This is genuinely useful context an agent couldn't infer 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 purpose and the ticker/no-ticker behavior are front-loaded, and the regional enumeration is informative rather than padding. It is a dense single block, and the trailing version tag 'v5.732' is pure noise, but overall little 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 carries the return-value burden and does so well by describing the market-summary payload. It is close to complete for a read-only, 4-param tool, with the only meaningful gap being the unexplained `days` and `side` semantics.

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 25% (only `ticker` is described in-schema). The description compensates for some of this: it clarifies that `ticker` also accepts company/insider names and maps `market` regions to their regulators while noting the unsupported ones. However, it says nothing about `days` or the `side` enum values (trades/sell/buy/proposed/exercise/all), leaving half the parameters unexplained.

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 ('Live insider trades read straight from the regulators') and enumerates exactly what data it covers — SEC Form 4, Form 144, BaFin, AMF, Finansinspektionen, AFM, EDINET. An agent can clearly distinguish this from siblings like get_market_radar or get_money_flows 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 the two operating modes with clear conditions: 'Without a ticker it returns the market summary… With a ticker, company or insider name it returns that name's filings.' It also flags region caveats ('Canada, Australia, Hong Kong and India… need a data licence first'), though it names no alternative sibling tool for those cases.

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 safe/public-read profile is covered. The description adds genuine behavioral context beyond that: the ordering rule ('featured agents first'), the ranking dimensions, and that access is free (no auth/cost barrier). It does not explain pagination or what happens when limit is omitted, which leaves some gaps for a list endpoint.

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

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

A single dense sentence front-loads the resource and then lists the ranking criteria, with no filler. The trailing 'Free' is a little abrupt but carries real information. Sized appropriately for the tool's simplicity.

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 one-parameter read tool with no output schema, the description covers what is ranked and in what order, and annotations cover safety. However, it omits the limit parameter and gives no hint of the return shape or default page size, leaving the agent guessing about the response. Adequate but with clear gaps.

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

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

There is a single parameter, limit, with 0% schema description coverage, so the description must carry the burden of explaining it. The description never mentions limit at all, leaving its range, default, and effect on the ranking unexplained. With one undocumented parameter, the definition 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 names a specific resource (agents and desk strategies sold on OwlChart) and characterizes it as a public ranking by sales, usage, verified desk hit rate and member ratings, with featured agents first. This is clearly a leaderboard rather than a raw product list like get_desk_strategies or a single-agent report like get_track_record. It stops short of explicitly contrasting itself with those siblings, so it earns a 4 rather than 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?

The description says the data is public and free, which implies an open read use case, but never states when to reach for this tool versus get_desk_strategies, get_owl_score, or get_track_record. There are no prerequisites, exclusions, or alternative-routing hints, so an agent must infer the use case from the ranking criteria alone.

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 genuine provenance ('recorded by OwlChart from the exchanges' public feeds') and disambiguates 'actually liquidated' from hypothesized levels, but says nothing about staleness, rate limits, or granularity.

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

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

A single, front-loaded sentence with no filler. It is efficient, though its brevity is also part of why parameter detail is missing.

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 simple read-only, two-parameter tool with no output schema, the description covers the semantic meaning of the return (realized liquidations by side and time window). However, the complete absence of parameter documentation and any note on data granularity or limits leaves it only marginally sufficient.

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 0%, so the description carries the burden. It only conceptually gestures at 'a coin' and 'over the last hours' without explaining the coin identifier format (symbol vs pair vs id) or that hours defaults to 24 and caps at 168. This leaves real gaps for a 2-param tool.

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: it fetches long/short positions 'actually liquidated' for a coin over a time window, and names the source. This is clearly distinct from siblings like get_funding_rates or get_open_interest, though the description never explicitly contrasts them.

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?

No when-to-use guidance, no alternatives, no exclusions. The context of liquidations is implied by the topic, but an agent gets no help deciding between this and related derivatives tools such as get_open_interest or get_funding_rates.

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 readOnlyHint and openWorldHint, so the safety profile is covered. The description goes further by scoping the domain to crypto coins and disclosing that results include 'the model's measured hit rate' plus that all OwlChart charts share one consensus answer, which is genuine reliability/consistency context beyond the annotations. Freshness cadence and rate limits remain unstated.

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

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

It is a single dense sentence, but because there is no output schema the enumeration of returned fields earns its place and the consensus answer is front-loaded as instructed. It reads as a run-on mixing consensus and heatmap concerns, which slightly hurts scannability.

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

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

With no output schema, the description must convey the return shape, and it does so thoroughly: consensus headline, magnets above/below, net pull, whale bids/asks, open interest, long/short split, RSI, TBO trend, hit rate. Combined with read-only annotations, an agent has enough to call it correctly; only update cadence 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?

Schema coverage is 100% for the single 'coin' parameter, so the baseline of 3 applies. The description adds only slightly more than the schema by listing extra example tickers and restricting to crypto, but contributes no format or validation detail 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?

The description states two concrete deliverables: the OwlChart consensus direction and the surrounding liquidation levels ('nearest liquidity magnet above and below, net pull direction'). This clearly differentiates it from data-only siblings like get_liquidations or get_open_interest, though the run-on enumeration is closer to an output inventory than a crisp verb+resource statement. It never names a sibling directly.

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

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

Usage is only implied: 'around the current price' and 'Crypto coins only (BTC, ETH, SOL, WLFI ...)' gesture at when it applies, and 'lead with consensus.headline' hints at how to read the result. There is no explicit when-to-use vs get_liquidations/get_open_interest guidance and no exclusions. Adequate but with a clear gap.

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 goes beyond them by disclosing the Bearer owlpass_ auth requirement and the purchase endpoint needed to activate template retrieval. It does not say what is returned when the pass is missing or invalid, so the disclosure is useful but incomplete.

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

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

Two sentences, front-loaded with the resource definition before the access mechanics. The inline enumeration of eight alert types is dense and slightly list-like, but it is informative rather than filler.

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

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

For a read-only, one-optional-param tool with no output schema and thin annotations, the description covers the resource, its contents, the price model, the auth/pass requirement, and the downstream create_alert step. The only gap is the no-param (list-all) behavior.

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 'template' param is documented there, so baseline is 3. The description adds genuinely new meaning — the pass prerequisite and where to obtain it (buy?for=ID) — which is parameter-related context the schema does not carry.

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 (alert templates sold by OwlChart members) and enumerates the concrete contents (bundles of alert types with coins/thresholds at a monthly price), which clearly separates it from siblings like create_alert, list_alerts, and check_alerts. It is slightly ambiguous about whether it lists all templates or fetches one by id, which keeps it 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 concrete prerequisite chain — obtain a template pass via /api/products/alert_marketplace/buy?for=ID, then supply the template id — and names create_alert as the follow-up. It does not, however, state what happens without a template id or explicitly contrast with list_alerts, so the boundaries are left 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 declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuine value by disclosing the fixed coin set and the three returned dimensions, which matters with no output schema. It does not mention freshness, caching, or whether the list can be configured.

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?

One sentence, front-loaded with the scope ('major coins at once') followed by the payoff (coins and fields). No filler whatsoever.

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-parameter snapshot tool with annotations covering the safety profile and no output schema, the description tells the agent what it gets and for which assets. Only minor gaps remain (data freshness, whether the coin set is fixed vs. configurable), which are not blocking.

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?

Zero parameters, so per the rubric the baseline is 4. The description correctly conveys that the tool is parameterless and operates on a fixed coin list, which is the only semantic an agent needs 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?

Names a specific verb ('read') and resource ('major coins at once'), and enumerates both the covered coins and the returned fields (Owl Score, price, verdict). It is clearly distinct from per-coin sibling get_owl_score, though it never names that sibling explicitly.

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

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

'A quick read' implies a snapshot/overview use case versus the deeper per-coin tools in the sibling list, but there is no explicit when-to-use / when-not-to-use statement or named alternative, leaving the routing to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds the temporal window (last day) and discloses the data provenance (minted/burned read from the contracts), but says nothing about refresh cadence, latency, or any coverage caveats for an aggregated snapshot.

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

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

A single sentence with the scope constraint ('over the last day') front-loaded ahead of the content list. It is dense but each listed source earns its place; only the trailing open-interest clause reads as slightly tacked on.

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

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

With no output schema and no parameters, the enumeration of returned content in the description is what carries the tool. It is nearly complete, though it omits the form/units of the returned numbers and does not flag that overlapping siblings exist.

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 and schema coverage is 100%, so baseline 4 applies. There is nothing for the description to clarify about inputs.

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

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

The description gives a concrete resource (money flows over the last day) and enumerates the specific data it aggregates: stablecoin mint/burn, tokenised gold and treasuries, ETF flows, BlackRock bitcoin, and 24h open interest change. An agent knows what this returns, but it never distinguishes itself from siblings that cover the same ground (get_etf_flows, get_open_interest, get_tokenization_overview).

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

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

There is no statement of when to use this aggregate overview versus the specific siblings like get_etf_flows or get_open_interest, and no exclusions or prerequisites. The agent must infer that this is a broad daily digest rather than a drill-down.

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, so the description is expected to carry the behavioral load, and it does: ordering (newest first), per-item payload (source, second-precision timestamp, link, for coins the headline price and move since), and that calendar events and Owl Journal stories are included. It does not discuss rate limits, pagination, or result caps, which keeps it short of a 5.

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

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

Front-loaded with the core identity and freshness ordering, then the payload, then filters. It is a single dense run-on sentence with several stacked clauses, but nearly every clause carries information an agent would otherwise have to infer; only the journal/calendar clause feels slightly padded.

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

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

With no output schema, the description must describe returns, and it covers format, ordering, per-item fields, and the auxiliary calendar and journal content well. The gap is the unmentioned region parameter and the absence of any guidance on volume or pagination for a live feed.

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 67%. The description supplies meaning for two of the three parameters -- the coin filter ('Optional coin filter (BTC)') and the desk filter's allowed values ('all, crypto, x, stocks') -- matching the enum that the schema lists without explanation. It adds nothing for region, which remains documented 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?

States a specific verb and resource ('the live news wire OwlChart reads, newest first') and enumerates the exact content classes it returns (crypto news, X accounts, stock/macro, rule changes, chart patterns, calendar, Owl Journal). This is enough for an agent to distinguish it from data-oriented siblings like get_market_radar or get_regional_pack 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?

Usage is only implied: the description tells the agent the optional coin and desk filters exist and hints at content breadth, but never states when to prefer this over sibling feeds such as get_regional_pack, get_reg_radar, or get_crypto_regulation. No explicit when-not or alternative routing is given.

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 behavioral context beyond annotations: it specifies aggregation across 13 named exchanges, a one-row-per-venue output shape, and the 24-hour change metric. It does not cover auth, rate limits, or update frequency, but for a public read-only analytics tool that is a minor gap.

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

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

The description is a single front-loaded sentence, which is good structure. However, the parenthetical list of 13 exchanges is long and arguably unnecessary for tool selection, bloating the sentence without clear benefit to the agent.

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 simple read-only, single-parameter tool with no output schema, the description adequately explains the return shape and exchange coverage, and annotations carry the safety profile. It still leaves key gaps: no coin format guidance and no when-to-use context. Adequate but incomplete.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented coin parameter. It only repeats 'for a coin' without specifying symbol format, case sensitivity, or examples, adding essentially no meaning beyond the parameter name itself.

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 (live open interest), scope (summed across 13 exchanges), and output granularity (one row per venue with coins, dollars, share, and 24h change). It is clearly distinct from siblings like get_funding_rates and get_liquidations, but it does not explicitly name an alternative or contrast itself with one.

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?

There is no explicit when-to-use, when-not-to-use, or alternative guidance. The agent can infer it is for open interest, but the description gives no context about when this tool should be selected over related market-data tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that the data spans 'wired exchanges' and names specific order-book metrics, which is useful context. It does not disclose return format, refresh behavior, or rate limits, but with annotations covering the core behavioral traits, a 3 is appropriate.

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

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

The description is a single, front-loaded sentence that efficiently lists the returned content. Every phrase earns its place, and there is no redundant or filler text.

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

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

For a read-only, single-parameter market data tool with no output schema, the description gives a good high-level summary of what the response contains: depth, walls, and imbalance across exchanges. It could do more to specify the coin identifier format or whether the data is live versus snapshot, but it is largely complete for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the single 'coin' parameter. It only says 'for a coin' without clarifying format (ticker, symbol, contract address) or whether it must match a specific exchange convention. That is barely more than the parameter name itself, so it does not adequately cover the 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 clearly states the resource: resting bids and asks for a coin, plus specific metrics (depth near price, biggest walls, buy/sell imbalance). It is not a tautology and gives an agent a precise sense of what the tool returns. However, it does not explicitly differentiate itself from sibling tools like get_liquidity_heatmap or get_market_radar, so a 4 is appropriate.

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?

There is no explicit guidance on when to use this tool versus alternatives such as get_liquidity_heatmap or search_markets. The description only implies usage through the content it returns, leaving the agent to infer the right context. No exclusions or prerequisites are stated.

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

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

Annotations already cover readOnlyHint=true and openWorldHint=false, so safety is established. The description adds genuinely useful context beyond that: the history is append-only, points carry no monetary value, and there is no token contract, swap, or account-to-account sending — which preempts an agent from trying transfer-style operations. It omits any mention of ordering or pagination behavior for the history.

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

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

Two sentences with no waste: the first delivers the payload, the second delivers the constraint that prevents misuse. Well front-loaded and nothing redundant.

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

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

With no output schema, the description does list the returned fields, which is the main burden. Missing only the pagination/limit semantics and any statement of what 'this account' resolves to (implicit auth context), so it is nearly complete for a simple 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?

The single `limit` parameter has 0% schema description coverage, so the description carries the full burden and does not address it at all — no indication whether the limit caps history entries only, whether the balance is always returned, page size bounds, or ordering. Only an indirect hint exists in that 'history' implies a list.

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 precise resource (this account's $OWL points balance) plus the exact payload of its history (reason, amount, time, reference). An agent knows exactly what comes back. It doesn't explicitly differentiate itself from the sibling get_owl_score, so the boundary between the two point-related tools must be inferred.

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 line about points being earned in the Owl Arena for graded forecasts implies usage context (checking your forecast rewards), and the non-transferable clause implicitly rules out transfer attempts. But there is no explicit 'use this instead of X' routing against get_owl_score or arena_leaderboard, and no prerequisites stated.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description only needs to add context. It does add value by naming the return contents (score, verdict, price, state) and by clarifying the output is a condition reading rather than a trade signal, but it says nothing about freshness, data source, or failure behavior for an unknown coin.

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 sentences with the substance front-loaded: what the score is and what comes with it, followed by the interpretive caveat. Nothing is wasted, though 'OwlChart's' branding is the least informative fragment.

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 one required parameter, no output schema, and no annotation detail beyond read-only/open-world, the description partially compensates by listing return fields. It is still incomplete on the one thing an agent must get right — the accepted format of the coin identifier.

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 carries the burden for the single 'coin' parameter. It only implies a coin is required ('for a coin') and gives no format guidance — symbol vs. name vs. internal id — which is exactly the ambiguity that causes mis-invocation.

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 (OwlChart's 0-100 score for a coin) and enumerates what it returns (verdict, price, state), so an agent can tell it apart from generic market tools like get_market_radar or get_ai_metric. It stops short of explicitly contrasting itself with the closest siblings, which keeps it at 4 rather than 5.

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

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

There is no when-to-use guidance and no named alternative among the many sibling getters. The line 'A reading of conditions, not a trade call' sets interpretive expectations but does not tell an agent when to choose this over get_carv, get_ai_metric, or get_track_record.

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 value by disclosing what the response contains (candles plus last price, change over window, high, low), a behavioral trait not in the annotations, but says nothing about rate limits, pagination, or window semantics.

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 primary purpose front-loaded and the input-format caveat second. Every clause earns its place.

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

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

No output schema exists and the description compensates by summarizing the return shape. The main symbol-format ambiguity is resolved. Minor gaps remain around interval/limit semantics and window length, but nothing critical for a 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 0%, so the description carries the full burden. It resolves the key ambiguity for `symbol` (plain ticker vs market id), which is genuinely useful; `interval` is a self-descriptive enum and `limit` is bounded 20-500 with a default in the schema, so the remaining gap is modest rather than severe.

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 combination (OHLCV candles) plus the summary payload returned, which is concrete and distinguishable from siblings like get_orderbook_depth or get_funding_rates. It does not explicitly differentiate from adjacent tools such as scan_patterns or get_market_radar, 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?

It clarifies accepted input forms (plain ticker BTC/ETH/AAPL or an id from search_markets), which is real usage guidance and routes the agent to a sibling for id resolution. However, it gives no when-to-use guidance versus alternatives like get_market_radar or scan_patterns, so usage is only implied.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, yet the description adds real behavioral context beyond them: the trial is capped at three English headlines, and the full pack is paywalled behind the listed tiers/passes. What is missing is whether results are paginated or how freshness/refresh works.

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 clause, which is good, but the sentence is a dense run-on and the purchase URL (/api/products/regional_packs/buy?for=latam) reads as marketing/upsell rather than agent-operational content. It is not padded, but it is not tightly structured either.

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

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

There is no output schema, but the description effectively enumerates what is returned (news wire, regulatory events, translated headlines, market hours, venues) and states the access tiers, so an agent knows both the payload shape and the gating. Only pagination/refresh behavior and the pack-lang interaction remain unaddressed.

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

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

Schema coverage is 50% (only lang is described, and thinly, as 'A language of the pack'). The description compensates partially by naming the six regions and the eleven accepted language codes, which is meaningful help. However, it does not explain the interaction between pack and lang (e.g. whether lang defaults, or whether pack language overrides translation), leaving a real gap.

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

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

States a specific resource (region-specific market intelligence) and enumerates its contents: live news wire, regulatory events, translated headlines, market hours and venues. This clearly separates it from a generic news tool, but it never names a sibling (e.g. get_news, get_reg_radar, get_data_pack) that overlaps with it, so the differentiation is left implicit.

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 describes access conditions rather than usage: a free trial gives three English headlines, and full access requires a pack pass, Builder, Scale or PRO subscription. That is genuinely useful gating context, but there is no guidance on when an agent should choose this over get_news or get_reg_radar, and no exclusions.

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

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

Annotations cover readOnlyHint and openWorldHint, so the safety profile is set. The description adds meaningful behavior beyond that: the access-tier limitation (trial returns only ten latest items, paid tiers return the whole store) and the semantic decoding of the sign field (green opens, red tightens, grey informs). It does not mention pagination or ordering, but the added context is substantial.

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

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

Three dense sentences organized as return content, then filters, then access tiers. Front-loaded with what the tool returns. Slightly packed but every clause carries information; no filler.

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

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

For a 7-parameter, no-output-schema tool with low schema coverage, the description covers returned fields, most filter values, and access tiers. Missing: limit behavior and valid kind values, which an agent might need to call it optimally.

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%, so the description must compensate, and it does: it enumerates the jurisdiction enum values (sec, cftc, usbank, eu, uk, row, macro), gives the since format (YYYY-MM-DD), and explains the sign semantics. It does not document the limit parameter or list valid kind values, leaving some gaps.

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

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

States a specific resource (structured regulatory events) with named source categories (SEC, CFTC, US banking regulators, Treasury, EU, UK, RoW, macro) and the fields each event carries. An agent can distinguish this from siblings like get_news or get_crypto_regulation from the description alone.

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 filter list implies how to narrow results, and the tier note ('Trial: ten latest; ... the whole store') tells the agent about access constraints. However, there is no explicit when-to-use guidance or naming of alternative tools for regulatory vs. general news 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 the safety profile is covered. The description adds real value by naming the data source (token contracts) and the access prerequisite (Flows Terminal pass, Builder, Scale or PRO), but says nothing about rate limits, latency, or return format.

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

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

Two sentences, front-loaded with the core computation and its outputs, with the access caveat last. The dense comma-list of outputs is slightly run-on but every clause conveys 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 usefully compensates by summarizing the return payload (net figure, total supply, biggest mints/burns, hourly history) and the auth requirement. However, the undocumented window options and lack of any guidance among the many sibling flow tools leave it only minimally complete for an openWorld paid-tier endpoint.

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 the single 'window' parameter. The description only says 'over the last 24 hours', which effectively implies a fixed window and does not acknowledge the 7d/30d enum options the schema exposes, leaving the parameter under-documented and potentially misleading.

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 metric (net stablecoins minted minus burned) and enumerates the returned content (total supply, biggest mints/burns, hourly history), which is far more specific than a restated title. It is clearly the stablecoin-specific counterpart to the broader flow tools, though it never explicitly names a sibling to distinguish itself from.

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?

No statement of when to use this versus the sibling flow tools (get_etf_flows, get_global_flows, get_money_flows). The only contextual cue is the access-tier requirement, which is a prerequisite rather than usage 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 and openWorldHint, so the safety profile is covered. The description adds real value by disclosing tier-gating: large transfers of the last hour, supply history and regulation items require the Tokenized Assets pass, Builder, Scale or PRO — behavior an agent cannot see in the annotations.

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

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

The purpose is front-loaded, but the long parenthetical ticker lists ('USDT, USDC, USD1, PYUSD, RLUSD...', 'BUIDL, Ondo...') consume significant space for marginal selection value, making it a dense wall of text rather than a tight definition.

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

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

With no output schema, the description carries the burden of describing returns, and it does so reasonably by listing the fields and the tier-dependent extras. It stops short of return format/pagination details, but for a single-optional-param read tool it is largely 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 the token id is documented. The description adds genuinely useful semantics beyond the schema: the range of valid asset categories and, crucially, the behavior of the optional parameter when omitted ('the list'), which the schema does not state.

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

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

The description clearly states the resource — a per-token hub that reads tokenised-asset data from contracts — and enumerates the covered asset classes and returned fields (price, supply, value, 24h change, issuer, contract). It does not, however, name the closest siblings (get_tokenization_overview, get_carv, get_stablecoin_net_mint) to differentiate itself, so an agent must infer the boundary.

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

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

Usage is only implied: 'No token given: the list' tells the agent what happens with an empty call, and the tier mentions hint at gated data. There is no explicit when-to-use / when-not-to-use guidance versus the related tokenization and CARV tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context: the $5M/24h filter, the contract-level granularity, and that regulation items are included. It does not disclose pagination, ordering, or how results are truncated for lower tiers, so a 3 is appropriate.

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

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

The first clause is front-loaded with the core scope, but the sentence is a long run-on stringing together supply events and regulation items. The trailing tier note ('Pass, Builder, Scale or PRO') is somewhat useful but sits awkwardly and is not clearly framed.

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 1-parameter, no-output-schema tool with annotations covering safety, the description adequately conveys what data is returned. However, it omits the meaning of the 'days' parameter and any sense of result volume or truncation, leaving gaps an agent would need to infer.

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 0%: the single 'days' parameter (integer, 1-90) has no description in the schema, and the description never mentions or explains it. The phrase 'the last days' hints at a time window but gives no mapping to the parameter or its 90-day cap, so the description fails to compensate for the coverage gap.

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

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

The description states a concrete resource (tokenised asset supply changes: mints/burns of stablecoins, treasuries, gold, plus regulation items) with a precise scope threshold ($5M per contract over 24h). An agent can tell it apart from get_stablecoin_net_mint or get_reg_radar, though it does not explicitly name those siblings. The concrete filtering criteria make the purpose clear.

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?

There is no guidance on when to use this tool versus get_tokenization_overview, get_stablecoin_net_mint, or get_reg_radar, all of which overlap on the same data. The only routing-style sentence ('Pass, Builder, Scale or PRO for the full list') is about subscription tier, not about when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the data provenance ('read from the contracts'), which is useful context about freshness/source. It does not cover update cadence, coverage universe completeness, or 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?

It is a single sentence, which is efficient, but the opening rhetorical question ('How much real-world value is on-chain today') delays the actual payload and the parenthetical examples (BlackRock BUIDL, Ondo ...) add length without much selection value. Front-loading could be tighter.

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-param read tool with no output schema, the description does list the data categories covered, which is the main thing an agent needs. However, it says nothing about the response structure, units, or whether the world-market denominators are included, so the agent must discover output shape at call time.

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. The description appropriately spends no words on arguments and instead explains the data content.

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 the specific resource (on-chain tokenisation: stablecoins, tokenised treasuries/funds, gold, shares) and the framing metric (value on-chain vs. each world market). An agent can distinguish it from sibling get_crypto_regulation or get_etf_flows. The rhetorical question opening is less direct than a verb-first phrasing, but the content is clear.

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?

There is no statement of when to call this versus alternatives, no prerequisites, and no mention of any sibling. The agent must infer usage purely from the subject matter.

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 known. The description adds meaningful behavioral context: calls are logged before the outcome then scored, and it specifies the exact metrics computed, which goes 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?

Two dense sentences that front-load the core resource and follow with the metric list. No wasted words, though the second sentence is a somewhat long enumeration.

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, single-parameter tool with no output schema, the description covers what the tool returns and how the data is generated. It stops short of explaining the return shape or pending-call semantics, but the annotations and schema carry the rest.

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 100% schema coverage, the single optional 'coin' parameter is fully documented in the schema. The description's phrase 'overall and per coin' implies the coin parameter's effect but adds 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?

The description names a specific resource (OwlChart's liquidity pull model track record) and specifies the exact contents returned: hit rate, direction accuracy, 95% range, pending calls, overall and per coin. This is clearly distinguishable from siblings like get_owl_score or get_market_radar.

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

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

The description explains what the record contains but doesn't explicitly state when to use this tool versus alternatives like get_owl_score. Usage is implied for credibility checks, but there are no stated exclusions or alternative 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by disclosing what data is returned (live price and 24h change per market), but says nothing about auth requirements or freshness/staleness of the live prices.

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

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

A single front-loaded sentence that carries the resource and the returned data with no wasted words.

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 needs to convey the return shape, and it does so at a high level (live price plus 24h change per market). For a no-arg read tool this is nearly complete, though it omits how empty watchlists behave.

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. Baseline 4 applies since parameter semantics are trivially satisfied.

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 clear verb+resource (get this member's own watchlist) and even names the returned fields (live price and 24-hour change). It is distinguishable from the mutating siblings add_to_watchlist/remove_from_watchlist, though it does not name them 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?

No explicit when-to-use guidance or routing to alternatives. The phrase 'this member's own watchlist' implies the context but never states conditions or exclusions versus add_to_watchlist/remove_from_watchlist or search_markets.

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=false, covering the safety profile. The description adds the useful scoping detail that results include both active and recently fired alerts, but says nothing about ordering, limits, or how 'recently' is bounded.

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

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

A single front-loaded sentence with no filler. Every word (member scope, active, recently fired) carries information, and 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?

With no parameters, no output schema, and annotations covering the read-only profile, the description supplies what an agent needs: whose alerts and which subset. The only gap is the undisclosed size/ordering of the result 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?

The tool takes zero parameters, so the baseline is 4. There is no input to describe and the description correctly does not invent any parameter 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 (Lists) and resource (alerts) with a scope qualifier ('this member's'). It distinguishes itself somewhat from create_alert/delete_alert by being a read, but it does not differentiate from the sibling check_alerts, which likely overlaps in intent.

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

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

Usage is only implied by the possessive scoping ('this member's'), which hints at a personal listing. There is no explicit when-to-use or when-not-to-use guidance, and crucially no routing away from the overlapping sibling check_alerts.

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=false and openWorldHint=true; the description earns credit by disclosing the real side effect — the post fans out to the room owner's delivery channels, so it is not a private note. It still omits failure modes, rate limits, and whether the post is editable/retractable.

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 core action stated first and the fan-out consequence second. 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, 5 undocumented parameters, and no direction on what the `data` object is for or what a successful post returns, the definition is only minimally sufficient. It covers the headline behavior well but leaves real gaps for a tool with a nested object 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% across 5 parameters, so the description must compensate and largely does not. It mentions text and the optional data object, but 'with the room key' is ambiguous between the separate `room` and `key` parameters, and the optional `author` parameter is never addressed.

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: 'Post a finding... into an agent room you belong to.' It is clearly the write counterpart to get_agent_room, but it never names that sibling or otherwise positions itself among the read-only get_*/list_* tools around it.

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?

'into an agent room you belong to' implies the membership prerequisite for posting, which is useful implied usage guidance. However, it gives no explicit when-to-use conditions, no pointer to get_agent_room for discovering room keys, and no when-not-to-use exclusions.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: the scope is limited to "this member's own" watchlist, implying a per-user authenticated context. It does not say what happens when a symbol is absent or whether a partial failure occurs.

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

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

A single efficient sentence with the verb and scope front-loaded and zero filler. It is terse to the point of under-specification, but nothing in it 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?

Annotations cover the destructive/idempotent profile and there is no output schema to explain, so the definition is callable. Still missing for a destructive mutation: the identifier format for symbols, behavior when a symbol is not present, and any authorization requirement implied by "member's own."

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 carries the full burden, yet it only implies plurality via "markets." It never states whether symbols are tickers, market IDs, or slugs, nor what an empty array does. With one required undocumented parameter, this is a real 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?

Specific verb ("Removes") plus resource ("markets ... watchlist"), so the action is unambiguous. It implicitly separates itself from add_to_watchlist and get_watchlist by naming the inverse and read operations' resource, but it never names a 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as get_watchlist for inspection or add_to_watchlist for the inverse. The agent must infer the context entirely.

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 behavioral context beyond that: the model used, that every intermediate number (sigma, z, formula, caveats) is surfaced, and tier-based limits on levels, vol multiplier, and saved scenarios. It does not cover latency, rate limits, or failure modes, 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 core computation, and the tier restrictions are packed into one clause. It is dense but slightly run-on with stacked parentheticals, which costs a little readability.

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

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

With no output schema, the description does the work of describing the return (touch probability, above/below probability, and the full calculation shown), which is what an agent needs to know. The remaining gaps are input-side details (asset format, horizon semantics) rather than output expectations.

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

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

Schema coverage is 60%, and the description reinforces a few parameters: level count limits, the vol multiplier concept, and saved scenarios. It does not clarify the asset string format or what horizon_hours measures, so it only partially compensates for the coverage gap.

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

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

States a specific computational verb and resource: probability a market touches given price levels within a horizon, plus above/below finish probability, and names the method (driftless lognormal, reflection principle, realised hourly volatility). This is clearly distinguishable from every sibling, which are data-retrieval tools rather than a probability calculator.

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 context: any market OwlChart covers, with examples (BTC, ETH, SOL, WLFI, AAPL, gold), and spells out the trial vs Scenario Engine/Builder/Scale/PRO split of one level vs up to eight levels. It stops short of naming alternative tools or stating when not to use it, 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context about what is returned (win rates, a confluence score), but says nothing about latency, coverage limits, or how patterns are sourced.

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

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

A single dense sentence that front-loads the core action and packs the key output details without filler. Efficient, though the clause-after-colon structure makes it slightly harder to scan than a split sentence would.

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

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

For a two-parameter read-only tool with no output schema, the description covers purpose and returns adequately, but it leaves the interval enum and symbol format unexplained. Given 0% schema description coverage, this gap matters.

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 compensate, and it doesn't. It vaguely maps 'market' to symbol and 'timeframe' to interval, but gives no format guidance for symbol and never explains the interval enum values or the default.

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 (runs) and resource (OwlChart's pattern engine) plus the inputs (market, timeframe) and the output content (candlestick/chart patterns, historical win rates, confluence score). It is clearly distinguishable from data-fetching siblings like get_price_history or get_orderbook_depth, though it never names a 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?

There is no when-to-use, when-not-to-use, or alternative routing guidance. The agent must infer that this is for pattern detection rather than raw price retrieval, but the description offers nothing about prerequisites or competing tools.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds value by disclosing the return format ('crypto_perp:bybit:BTCUSDT', 'equity:NASDAQ:AAPL') that no output schema provides. It omits ranking/ambiguity behavior for multi-match queries.

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

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

Two tight sentences: coverage first, then the return-value contract and its consumer. Nothing is repeated from the title or schema and every clause earns its place.

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

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

For a one-parameter lookup with no output schema, the description supplies the critical missing piece: the shape of the returned id. Coverage list plus id format is nearly enough; match-ranking or case-sensitivity behavior would close the remaining gap.

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

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

Schema description coverage is 100% and the single query parameter is fully documented there with examples. The description adds no syntax or matching-semantics detail (prefix vs fuzzy vs exact) beyond what the schema already states, so baseline 3 applies.

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

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

States a specific verb (Find) and resource (any instrument OwlChart covers), then enumerates the asset classes covered, which cleanly separates it from siblings like get_price_history or get_etf_flows that act on a single market type.

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 tool as the lookup step whose output ids feed into get_price_history, giving clear downstream context. It stops short of stating when NOT to use it (e.g. when an id is already known), so no explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely new behavioral context: the chart is rendered inside the chat, liquidity magnets are overlaid for crypto coins, and numeric data is returned alongside the visual. It doesn't address rate limits or whether the chart is ephemeral.

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 what the tool produces and ending with the usage trigger. Only mild padding in 'Also returns the numbers,' which is vague but cheap.

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 should carry the return-value burden, and 'also returns the numbers' is too vague to tell an agent what data comes back or whether it needs to render separately. For a 2-param read-only chart tool this is adequate but leaves a real 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 50% – symbol is documented but interval is not described in the schema beyond its enum. The description compensates slightly by enumerating supported market types (crypto, stocks, forex, commodities), implying flexible symbol formats, but says nothing about interval values or defaults.

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 ('Shows an interactive OwlChart candle chart inside the chat'), names supported markets, and adds the distinguishing behavior (liquidity magnets for crypto). This clearly separates it from data-only siblings like get_price_history by signaling a rendered chart artifact.

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

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

'Use it when the user wants to see a chart' gives an explicit triggering condition. It stops short of naming alternatives (e.g. get_price_history for raw numbers) or stating when not to use it, so it lands at clear-context without exclusions.

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