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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description contributes a content inventory but says nothing about how many periods are returned, historical depth, currency, or whether values are restated — information an agent cannot get 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?

One efficient sentence with the resource and payload inventory front-loaded and no filler. Nothing is wasted, though there is also no routing or constraint information an agent would benefit from.

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?

A read-only single-fetch tool with an annotated safety profile and a fully documented 2-parameter schema needs little more, and the field list gives a reasonable sense of the payload. However, with no output schema, the description should say something about return shape (single vs multi-period, historical range) and does not.

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 ticker and the annual/quarterly enum are fully documented in the schema. The description adds no syntax, defaults, or behavioral meaning beyond that, which is the expected baseline when the schema does the work.

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 (get balance sheet data) and enumerates the content returned: assets, liabilities, equity, debt structure, shares outstanding. It does not differentiate itself from close siblings such as get_stock_financials, get_fundamental_breakdown, or get_income_statements, so the agent must infer the boundary from the name 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?

There is no when-to-use guidance, no mention of when to choose annual vs quarterly, and no routing to or away from the overlapping financial-statement siblings. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety/behavior profile is covered. The description usefully adds the returned field scope (operating/investing/financing plus capex, dividends, buybacks), but says nothing about data source, historical depth, or missing-data behavior — acceptable but not rich given annotations carry the rest.

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; the trailing field list earns its place by telling the agent what the response contains. Only minor redundancy with the schema-level resource 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 simple two-parameter read tool with strong annotations, the description is nearly sufficient — it identifies the resource and enumerates returned line items. It lacks only guidance on report_type defaults and any historical/pagination 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 description coverage is 100%: both 'ticker' and the 'report_type' enum are fully documented in the schema. The description adds no format, default, or filtering semantics beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb ('Get') and resource ('cash flow statement data for a ticker') and enumerates the contained line items (operating, investing, financing, capex, dividends, buybacks). This clearly separates it from sibling statement tools like get_income_statements and get_balance_sheets, though it never names those siblings 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 statement of when to use this tool versus the other financial-statement siblings, nor any prerequisites or exclusions. Usage is only implied by the resource name.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, covering the safety profile, so the bar is lower. The description adds value by enumerating the returned fields in the absence of an output schema, but says nothing about how many periods are returned, ordering, or empty-result 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?

A single front-loaded sentence with the verb+resource first and the field enumeration second. The listing is slightly dense but earns its place given there is no output schema to convey return shape.

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 2-parameter, read-only lookup with no output schema, the description covers the essential returned fields. Minor gaps remain around result volume/period range and no-data behavior, but nothing prevents correct invocation.

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

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

Schema description coverage is 100%, so both parameters (ticker with example values, report_type enum 'annual'/'quarterly') are fully documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get earnings history for a ticker') and enumerates the exact data returned (reported EPS, estimated EPS, surprise amount/percentage, report date/timing), so the agent knows precisely what this yields. It does not, however, distinguish itself from the closely named sibling 'uw_earnings', leaving potential overlap ambiguous.

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 alternatives such as uw_earnings or get_income_statements, nor any stated prerequisites (e.g., whether the ticker must be US-listed). The agent must infer usage purely from the name and the field list.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and idempotency are covered. The description adds meaningful context with 'filing-based' (data source/provenance), but says nothing about rate limits, freshness, or response shape. With annotations carrying the safety profile, this is adequate but not rich.

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

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

Two sentences, front-loaded with the purpose before the usage note. The enumerated data list is informative rather than wasteful, though it is on the long side for a one-parameter tool.

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

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

With no output schema, the description usefully enumerates what the tool returns (earnings, revenue, cash flow, dividends, EPS, balance-sheet trends, segment breakdowns). For a simple read-only single-parameter tool with strong annotations, little is missing; the main gap is sibling differentiation.

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 and schema description coverage is 100%, so the schema already documents the ticker field with examples. The description adds no format or syntax detail beyond the schema, which is the expected baseline at full coverage.

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

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

The description gives a specific verb and resource ('Get filing-based fundamentals for a ticker') and enumerates the data covered, so the agent knows exactly what it returns. However, it does not distinguish this tool from close siblings like get_income_statements, get_balance_sheets, get_cash_flows, or get_earnings_history, which cover overlapping ground, 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?

'Use this for company financial statement analysis and medium/long-term fundamental context' provides a usage cue and a time-horizon hint. But no alternatives are named and no exclusions are stated, leaving the agent to infer when to pick this over the numerous financial-statement siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description's one addition of substance is enumerating which financial metrics come back, which is useful given there is no output schema, but it says nothing about reporting periods, history depth, or data freshness.

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; the resource and returned fields come first. It is appropriately sized for a two-parameter read tool, though the field enumeration makes it slightly list-like rather than directive.

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, two-parameter tool with a fully documented schema and annotations covering safety, the description supplies the one missing piece – what data comes back – in the absence of an output schema. It leaves minor gaps around period coverage and how report_type defaults, but nothing critical to correct invocation.

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

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

Schema description coverage is 100%, including an enum for report_type (annual/quarterly), so the schema fully documents both parameters. The description adds no format, default, or period-scope detail beyond what the schema already states, which matches the baseline 3 for high-coverage schemas.

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

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

Names a specific verb+resource ('Get income statement data for a ticker') and enumerates the line items returned (revenue, gross profit, operating income, EBITDA, net income), which distinguishes it from generic siblings like get_stock_financials. It does not explicitly contrast itself with get_balance_sheets or get_cash_flows, so an agent still infers the distinction from the resource name 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?

There is no when-to-use guidance, no mention of alternatives such as get_stock_financials or get_fundamental_breakdown, and no statement of prerequisites. The only contextual cue is 'for a ticker', which is implied by the schema's required parameter rather than stated 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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds value by listing the data categories returned (income statements, balance sheets, cash flows, earnings), giving some insight into the response shape; however, it omits details like periodicity or 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?

The description is a single, front-loaded sentence with no redundant or filler content. It efficiently communicates the tool's purpose and contents.

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 low-complexity, single-parameter tool with full schema coverage and annotations, the description adequately explains what data is retrieved. It does not specify periodicity (e.g., annual vs. quarterly) or response format, but no output schema exists to cover that, so a minor gap remains.

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 sole parameter 'ticker' already has a clear description with examples. The tool description adds no additional semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource ('Get combined stock financials for a ticker') and enumerates the included statement types. The word 'combined' distinguishes it from sibling tools like get_income_statements, get_balance_sheets, and get_cash_flows, so an agent can tell what it does 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?

Usage is implied by 'combined'—it aggregates multiple statement types—but there is no explicit guidance on when to prefer this over the individual sibling tools (e.g., use this for a full overview vs. get_income_statements for a single statement). No exclusions or alternatives are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is fully covered and the description's bar is lower. The description adds only that the result is a time series; it says nothing about pagination/row limits or the behavior of the optional 'month' backfill parameter beyond what the schema states.

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

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

Two tight sentences, with the core purpose front-loaded before the supported-function list. The 14-item indicator list simply duplicates the schema enum, so it consumes space without adding new information.

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

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

For a six-parameter analytical tool with no output schema, the description is adequate but thin: it never indicates the shape of the returned series (timestamp/value pairs, indicator-specific columns such as MACD's multi-line output). It is callable as written but leaves the response format to inference.

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

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

Schema description coverage is 100%, so all six parameters (including defaults for interval and series_type, ranges for time_period, and the month format) are already documented. The description restates the function enum verbatim without adding calculation semantics, which is the correct baseline-3 case.

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 a technical indicator time series for a ticker') and enumerates the 14 supported indicators, so an agent knows exactly what it computes. It does not, however, distinguish itself from the sibling 'uw_technicals', leaving the boundary between the two unresolved.

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 alternative tool is named. The indicator list implies the tool's scope but does not tell the agent when to prefer it over 'uw_technicals' or how it relates to the other market-data siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safe-read profile is covered. The description adds that this is scoped to the calling user's alerts and that filters/query_grammar gate valid configuration, but says nothing about pagination, result volume, or auth/account requirements for creating configurations.

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 one-line purpose followed by a tight bulleted command list, and it closes with the actionable ordering rule. The opening sentence is slightly generic ('access ... alerts and configurations') but nothing is wasted.

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

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

No output schema exists, and the description compensates by describing what each command returns ('Get triggered alerts for the user', 'Get alert configurations'). The one real hole is that the empty input schema gives no clue how a command is selected, which the description gestures at but does not resolve.

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 input schema is an empty object with no declared properties, yet the description implies a command selector (alerts/configurations/filters/query_grammar) that an agent must supply somehow. With zero schema coverage of that implied parameter, the description leaves the actual invocation mechanism ambiguous rather than compensating for it.

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

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

States a specific verb and resource (access UnusualWhales user alerts and configurations) and enumerates the four sub-commands with a one-line purpose each. It is clearly distinguishable from the market-data siblings (uw_options, uw_flow, etc.) by domain, though it never explicitly contrasts itself with 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?

Gives concrete ordering guidance: 'Call filters and query_grammar before constructing an alert configuration' and explains why (they describe valid fields, values, expressions). It does not state when to prefer alerts vs configurations or any when-not conditions, so it stops short of full 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, idempotentHint, and openWorldHint, so the safety and idempotency profile is covered. The description adds the command taxonomy and the required-name constraint for congress_trader, which is useful context, but says nothing about data freshness, pagination, or result size for an open-world data feed.

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?

Structure is clean and front-loaded: one scoping sentence followed by a compact bulleted command list. Every line carries information, with no redundant restatement of the tool 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 output schema and an empty input schema, the description carries the full burden and does explain the four commands and two of their arguments. But it never explains how a caller actually selects a command or passes 'name' given the empty schema, leaving a real invocation gap for an agent.

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 input schema has zero properties, so by the baseline rule this starts at 4. The description earns that by naming the parameters that exist only at the command level (required 'name' for congress_trader, optional 'last_traded_within_months' for politicians), which the schema does not document at all.

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 (access UnusualWhales congress trading data) and enumerates the four sub-commands, making it clear the tool is the congress-trading surface. It distinguishes itself from the many sibling tools by data domain, though it never explicitly contrasts with close neighbors like uw_insider or uw_potus.

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 command list implies when each mode is appropriate (recent trades vs. late reports vs. a specific politician), and it flags that congress_trader requires a name. However, there is no explicit when-to-use guidance or alternative routing between this tool and sibling tools such as uw_insider.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered by structured data. The description adds no behavioral context beyond that: no note on data freshness/delay, rate limits, pagination, or how large the whale feeds are. The supported-value lists it does provide are parameter-domain facts rather than 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?

Front-loaded purpose sentence followed by a tight bulleted command list and two valid-value lists; no sentence is filler. Structure mirrors how an agent needs to read it — command first, argument requirements in parentheses.

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 command-multiplexed tool with an empty input schema and no output schema, the description supplies the command surface, argument requirements and enum domains, which is most of what an agent needs. It omits pair-format conventions, limit defaults/ceilings, and any indication of return shape or pagination, which are the remaining gaps.

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

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

The input schema is empty, so the description is the sole source of parameter meaning, and it documents per-command required vs optional arguments (e.g., pair required for state/ohlc; limit/date optional) plus the valid candle sizes and blockchain values. It stops short of specifying pair formatting (e.g., BTC-USD vs BTC) or default/max limits, so it does not fully close 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 opening sentence names a specific verb (Access) and resource (UnusualWhales crypto data) and enumerates the data families: prices, OHLC candles, whale trades, whale transactions. The domain word 'crypto' immediately separates it from siblings like uw_options, uw_stock and uw_flow, so an agent can route 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?

The command list gives implied usage — pick 'state' for current pair state, 'ohlc' for candles, 'whales_recent'/'whale_transactions' for whale activity — and flags required parameters per command. However, it never states when not to use this tool or which sibling to prefer for overlapping needs, leaving the routing decision to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so safety and determinism are covered by structured data. The description adds the substantive constraint that price_levels requires a ticker with an optional date, but says nothing about data recency, pagination, or rate limits for a market-wide trade feed.

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 one-line purpose followed by a tight bulleted command list and a single filtering sentence. Every sentence carries information; the only minor cost is that the filter sentence is vague enough to be near-wasted text.

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

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

With no output schema, the description should say more about what is returned (trade records? aggregated volume?) and how commands map onto an actual invocation, especially given the empty input schema. It adequately covers the command surface but leaves the call contract and return shape underspecified.

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 input schema declares zero properties, so an agent has no structured way to express a command, ticker, or date. The description partially compensates by naming the commands and the required/optional fields for price_levels, and by mentioning premium, size, and volume range filters — but it never gives those filters names, types, or formats, so a valid call cannot be constructed from description plus schema alone.

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 ('Access UnusualWhales darkpool trade data') and then enumerates three concrete sub-operations (recent, ticker, price_levels) with their scope, so an agent knows exactly what data domain this covers. It does not explicitly contrast itself with the other uw_* domain tools, but 'darkpool' is distinctive enough that sibling disambiguation is largely 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?

Each command is annotated with when it applies: 'recent' for market-wide trades, 'ticker' for a single symbol, and 'price_levels' for volume concentration by price. That is clear selection guidance within the tool, though there is no guidance on when to prefer this tool over a sibling like uw_flow or uw_market.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds the enumeration of the three commands, which is useful context, but discloses nothing about return format, latency, or data freshness beyond that.

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

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

Front-loaded with the core purpose, then a tight bulleted command list with no filler. Every line carries invocation-relevant information, though the '(ticker required)' note is redundant given it says ticker twice.

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 data tool with no output schema, the description explains the available operations but leaves a significant gap: it implies command and ticker arguments that the empty schema cannot carry, so an agent cannot actually invoke the advertised commands as described.

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 schema declares zero parameters, so the baseline would be 4. However, the description references a command selector and a required ticker argument for the 'ticker' command that do not exist anywhere in the empty input schema, creating a mismatch rather than genuinely compensating semantics.

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

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

States a specific verb and resource: it accesses UnusualWhales earnings data and enumerates the earnings schedules available (premarket, afterhours, ticker). This is clear and actionable, though it does not distinguish itself from sibling tools like get_earnings_history that plausibly overlap.

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 command list implies when each sub-operation applies (premarket vs afterhours vs historical ticker data), which is useful routing information. However, there is no explicit when-not guidance and no mention of alternatives such as get_earnings_history, 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 already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the command-mode structure and states 'ticker required' for every command, which is genuinely useful context. But that requirement directly conflicts with the declared input schema, which has zero properties, leaving the agent unsure how to actually supply a ticker.

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

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

The purpose sentence is front-loaded and the bulleted command list is easy to scan. There is no filler or repetition. The repeated '(ticker required)' on every line is slightly redundant and could be stated once, but it does not meaningfully bloat the description.

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

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

With no output schema and no annotations explaining returns, the description carries most of the burden and does describe the rough shape of each command's data. It omits return-format details, pagination or result-size expectations, and never resolves the contradiction between 'ticker required' and an input schema that declares no parameters.

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?

Parameter count is zero, so the baseline is 4. The description does add real information by stating that each command requires a ticker, which the empty schema does not convey. It stops short of giving ticker format (symbol casing, exchange suffix) or any other argument syntax.

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

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

The opening sentence names a specific verb+resource ('Access UnusualWhales ETF data') and enumerates the covered data domains (holdings, exposure, inflows/outflows, weights). The five subcommands make the scope concrete. It does not explicitly contrast itself with siblings like uw_stock or uw_options, but the ETF-specific resource is clearly distinct from those asset classes.

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 command list implies which operation to pick for a given data need (info vs holdings vs exposure vs in_outflow vs weights), which is useful routing information. However, there is no explicit when-to-use guidance, no statement of when-not-to-use it, and no named alternative among the many sibling tools for overlapping needs such as fundamentals or sector data.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds behavior the annotations don't: per-command required vs optional arguments, and special return semantics such as flow_alert returning all legs for multi-leg alerts and all transactions for RepeatedHits. It omits pagination, rate limits and return shape, but the added command semantics are substantive.

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

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

Front-loaded with the resource summary, then a clean bulleted command list, then the flow-group values and filtering notes in separate blocks. It is long, but the length is justified by the number of commands; the only near-redundant tails are the two 'filtering options include...' sentences.

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

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

With no output schema and a high-complexity, multi-command surface, the description covers essentially all the commands and their required inputs, which is what an agent needs to invoke it. It leaves gaps on how arguments are actually passed (the schema exposes no properties despite the description implying required params) and on return values.

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 structured schema has zero properties, so the description bears the parameter burden and mostly delivers: it flags required arguments per command (id, date, flow_group, expiry, ticker) and marks the rest optional. It stops short of giving formats for those arguments (date format, ticker syntax, premium-range syntax) beyond naming the filter families.

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 ('Access') and the exact resource domain (UnusualWhales options flow data), then enumerates the distinct sub-resources: flow alerts, full tape, net flow, group flow, lit exchange flow. An agent can immediately separate this from siblings like uw_darkpool, uw_options or uw_alerts 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?

For a dispatcher this is strong: every command is annotated with its required/optional parameters (e.g. 'group_greek_flow_expiry (flow_group, expiry required; date optional)'), which tells the agent exactly which variant to pick for a given intent. What's missing is an explicit statement of when to prefer this tool over sibling hubs such as uw_options or uw_alerts, so no exclusions are 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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds which data domains are reachable (revenue segments, RSU data, EBITDA, capex, earnings surprises), which is useful content-scope context, but says nothing about rate limits, auth, caching, or how a command is actually dispatched.

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

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

The opening sentence is front-loaded and the command list is consistently formatted, with each entry earning its place by naming a data domain and its contents. Slightly long, but there is little filler to 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?

For a zero-parameter schema with no output schema, the description omits the most important mechanics: how a command is selected, how a ticker is provided, and what the return payload looks like. It also leaves unresolved how this tool relates to the six sibling tools that appear to expose the same commands individually, leaving the agent unable to invoke it confidently.

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

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

The input schema declares zero properties, and the stated baseline for 0 params is 4. However, the description repeatedly implies inputs that do not exist in the schema — a command selector and 'for a ticker' — creating a real mismatch between what the agent is told it must supply and the structured contract. The command enumeration itself is genuine semantic value, but the implied parameters are undocumented.

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

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

The description states a specific verb and resource ('Access fundamental financial data for stocks including financial statements, earnings, and revenue breakdowns') and enumerates the subcommands, so the domain is unambiguous. It fails to differentiate from siblings, however: get_income_statements, get_balance_sheets, get_cash_flows, get_fundamental_breakdown, and get_stock_financials appear to be standalone equivalents of its listed commands, and the description never explains why an agent would pick one over the other.

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 lists available commands but gives no when-to-use context, no when-not-to-use, and no routing against the near-identical sibling tools. An agent has no basis for choosing uw_fundamentals versus get_income_statements or get_stock_financials. Usage is implied only by the command names themselves.

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, openWorldHint=true, and idempotentHint=true, so the safety profile is covered by structured data. The description adds little behaviorally beyond noting the data categories available; it says nothing about rate limits, auth, or freshness.

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 one-line purpose followed by a compact, scannable command list; each bullet earns its place by pairing a command with its required argument. No redundant or padded prose.

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 empty-schema dispatcher tool with no output schema, the description supplies the essential missing information: the command set and the required inputs for each. Return fields and pagination are unstated, but given no output schema this is a minor gap.

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

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

With 0 parameters in the schema, the baseline is 4, and the description usefully compensates by documenting the command-scoped inputs (comma-separated ticker_symbol example, required sector/ticker per command). It doesn't describe the full filter surface for the 'transactions' command beyond mentioning 'filters'.

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

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

The description names a specific resource ('UnusualWhales insider trading data including transactions and flow') and enumerates the four supported commands, making the tool's scope concrete. It is clearly distinguishable from topical siblings like uw_congress or uw_institutions, though it doesn't explicitly route against 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?

The command list functions as usage guidance: each of the four modes is named and its required input is stated ('sector required', 'ticker required'), so an agent can pick the right command. It stops short of stating when-not-to-use or naming alternative 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, openWorldHint=true, and idempotentHint=true, so the safety and side-effect profile is covered. The description adds the command surface but says nothing about authentication, rate limits, pagination, or return shape. With annotations carrying the safety burden, this is adequate but not rich.

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

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

Front-loads the one-line purpose, then presents a scannable bulleted command list with required/optional inputs inline. No filler sentences; each line maps to a distinct operation. Only the missing invocation detail costs it the top score.

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 multi-command tool with an empty schema and no output schema, the description covers the command menu and their inputs but never explains the dispatch mechanism (e.g., how 'command' is supplied), which is critical given the empty properties object. Otherwise it is reasonably complete for the data it exposes.

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 input schema is an empty object, so the description is the only place command-level parameters are documented (name required, ticker required, date/start_date/end_date optional for activity_v2). This is doing real work the schema does not, though it leaves the list command's 'filters' unspecified and never explains how a command is actually passed.

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 (access) and resource (UnusualWhales institutional holdings and ownership data), then enumerates the concrete operations (list, holdings, activity, sectors, ownership, latest_filings). An agent can distinguish this from sibling data domains like uw_insider or uw_options without opening a schema. It stops short of explicitly naming which sibling to use instead.

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

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

Provides clear intra-tool routing: each command is paired with its scope and required inputs (name for holdings/activity/sectors, ticker for ownership), which tells an agent which command fits which request. It lacks any when-not guidance or explicit exclusion versus sibling tools, so it's context rather than full selection logic.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the full command surface and each command's return subject, which is useful. But it never discloses the dispatch mechanism: with an empty input schema, the agent is not told how a command is actually selected, which is a meaningful behavioral gap for a router-style tool.

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 overall purpose is front-loaded in one sentence, followed by a tight one-line-per-command catalog. Every line carries distinct information with no filler, and the bulleted structure makes scanning 17 commands tractable.

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 17-command router with no output schema and an empty input schema, the description is thorough about what each command returns but omits the one thing needed to invoke it: how commands and their arguments are passed. The gap between the documented per-command parameters and the empty schema leaves the agent unable to construct a call confidently.

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

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

The schema exposes zero parameters, so the baseline is 4, and the description genuinely earns it by documenting per-command parameters (date, otm_only, interval_5m, sector, ticker, direction, limit, etc.). The weakness is that these parameters live nowhere in the schema, so it is unclear whether they are separate arguments or a nested command payload.

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 (UnusualWhales market-wide data) and enumerates exactly which datasets are covered: market tide, sector ETFs, economic calendar, FDA calendar, and 13 more. It clearly differentiates from per-instrument siblings like uw_options, uw_stock, and uw_flow by scoping to market-wide aggregates.

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 command line implies when that command applies, and required vs optional parameters are noted per command (e.g. 'sector required', 'ticker required'). However, there is no explicit routing guidance telling the agent when to pick uw_market versus uw_options, uw_flow, or uw_screener for overlapping concepts like options volume or net premium.

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, openWorldHint=true and idempotentHint=true, so the safety profile is covered by structured data. The description adds that filters such as major_only exist, implying a filtered read, but says nothing about rate limits, paging behavior, or freshness that would go beyond the annotations.

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

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

Two short lines, front-loaded with the purpose followed by the command list. No filler, though the command-list format is slightly over-structured for a single command.

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-parameter, read-only news lookup with no output schema, the description gives enough to understand what is returned and the filters available. The residual gap is that the filter parameters are described but absent from the schema, leaving the agent unsure how to actually supply them.

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 input schema is an empty object, so by the zero-parameter baseline this would score 4. But the description advertises filters (ticker, sources, search_term, major_only, page) that the schema does not expose or type, creating ambiguity about how they are passed — that mismatch costs a point.

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 (access) and resource (UnusualWhales news headlines), and the command list pins it to news retrieval, which distinguishes it from siblings such as uw_options or uw_earnings. It stops short of explicitly contrasting with other data-domain tools, but the resource is unambiguous.

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

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

Lists the single available command (headlines) and its optional filters, which implies intended usage. However, it never says when to choose this tool over neighboring UnusualWhales tools, nor does it set exclusions or prerequisites.

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, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds the contract-symbol format for 'id' ('AAPL240119C00150000'), which is genuinely useful context, but says nothing about rate limits, data freshness, or response shape beyond the annotation coverage.

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 one-line purpose is front-loaded, followed by a tight bulleted command table; every line carries information (command name, required and optional params) with no filler or redundancy.

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

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

For a multi-command dispatcher with an empty schema and no output schema, the description covers the command set and per-command parameters adequately. The main gap is the mechanism for selecting a command — with zero declared properties, an agent cannot tell whether to pass a 'command' argument or some other convention, and the relationship to the sibling uw_flow is unaddressed.

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

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

The input schema is an empty object with no properties, so the description carries the entire parameter burden and does so well: each command lists required vs optional parameters (id required; side, min_premium, limit, date optional) plus a concrete example for id. It falls short of 5 because it never states which parameter actually selects the command or gives formats/units for side or min_premium.

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

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

The opening sentence names a specific verb and resource ('Access UnusualWhales option contract data') and enumerates the four data domains available (flow, historic, intraday, volume profile), which is more precise than the sibling names. It does not, however, differentiate itself from the sibling uw_flow tool, which an agent could easily confuse with the 'flow' command here.

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 command list implies what each subcommand returns and annotates which parameters are required vs optional, which is useful invocation guidance. But there is no explicit statement of when to choose this tool over uw_flow or uw_stock, and no exclusions or prerequisites are 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=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds that the tool exposes two distinct data domains (social posts and a public schedule) but says nothing about freshness, rate limits, or data availability windows 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?

Two framing sentences followed by a tight bulleted command list; every line carries information and the tool's identity is front-loaded in the first clause. No filler or repetition.

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

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

With no output schema and an empty input schema, the description should explain how an agent actually selects between posts and schedule, yet there is no 'command' parameter in the schema and none is implied by the description's parameter lists. An agent knows what data exists but not the invocation mechanism, which is a material 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 input schema declares zero parameters, so the baseline is 4 and the description is the only place any parameter information appears. It usefully documents limit, page, search_term (posts) and date, limit, page (schedule), though it provides no types, defaults, or date 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?

States a specific verb ('Access') and a precisely scoped resource ('UnusualWhales data on the President of the United States'), then enumerates the two subcommands (posts, schedule). The presidential scope cleanly distinguishes it from uw_congress, uw_insider, and uw_news without the agent needing to open other schemas.

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

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

'Useful for tracking potentially market-moving statements and events' implies when the tool is relevant, which is more than nothing. However, it names no alternatives, no when-not conditions, and no comparison to sibling tools like uw_news or uw_congress that might also surface political content.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the multi-command router structure, which is useful behavioral context, but discloses nothing about rate limits, data freshness, or auth requirements.

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

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

Purpose is front-loaded, then a clean scannable command list, then the category enum. Efficient for a nine-command router, though the phrase 'prediction market' is repeated heavily and could be tightened.

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

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

For a nine-command router with no output schema, the description covers every command and its arguments adequately. It falls short only on the invocation mechanism (no command selector in the schema) and any return-shape 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?

The input schema is empty, so the description is the sole source of parameter info, and it does a good job specifying per-command required (q, asset_id, user_id) and optional (categories, limit, offset, min_price, max_price) arguments plus the category enum values. It does not explain how the command selector itself is passed, which is a gap.

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

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

States a specific verb (Access) and resource (UnusualWhales prediction market data) and enumerates the data domains it covers, clearly distinguishing it from siblings like uw_options, uw_crypto, and uw_earnings. An agent can immediately tell this tool is the prediction-market surface.

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 command list effectively documents when to use each sub-operation and marks required vs optional params per command, giving strong intra-tool routing guidance. It does not, however, state when to prefer this tool over sibling tools or any prerequisites/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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds that results are screener/filter outputs and notes params are optional for one command, but says nothing about rate limits, result volume, pagination, or how subcommands are selected.

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 one-line purpose followed by a scannable command list; no filler sentences. It is appropriately sized for a multiplexed screener, though the parenthetical for unusual_activity is a touch verbose.

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

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

For a multi-mode screener the description enumerates the modes but never explains the invocation mechanism (how a command is selected or how filters are passed) and there is no output schema to cover return values. An agent can identify the tool's scope but not clearly construct a call.

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 schema declares zero properties, so the baseline for an empty parameter set is 4. The description does hint at a command selector and 'all params optional' for unusual_activity, which is useful, though it slightly conflicts with the empty schema by implying parameters exist.

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 ('UnusualWhales screeners') and enumerates four screenable domains (stocks, option_contracts, analysts, unusual_activity), which is more specific than a bare name restatement. It only loosely differentiates from siblings like uw_options or uw_flow, aside from the 'unusual' flow comparison.

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 subcommand list implies when each mode is appropriate (e.g., unusual_activity for the live options flow 'unusual' view), but there are no explicit when-to-use/when-not rules and no guidance on choosing this screener over uw_options, uw_flow, or uw_stock. Usage must be inferred from the command labels.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful command-mode context and notes that the data shows historical performance patterns, but it does not disclose freshness, rate limits, authentication needs, or output shape.

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

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

The description is front-loaded and uses a compact command list that maps directly to the four supported operations. Every line contributes to command selection or required input, 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 multi-command historical-data tool with an empty input schema and no output schema, the description gives enough structure to select a command and know the required fields. It is not fully complete because it omits return-value expectations and deeper semantics for the optional performers filters.

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 input schema exposes zero parameters, so the baseline is 4. The description compensates by naming the command variants, required month/ticker arguments, and optional performers filters, though it does not define the types or semantics of filters such as min_oi or order_direction.

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 identifies the resource as UnusualWhales seasonality data and specifies the historical-performance domain. The command list further clarifies four distinct sub-operations, though it does not explicitly differentiate this tool from siblings such as uw_market or uw_stock.

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 lists the available commands and required inputs for performers, monthly, and year_month, which helps an agent choose how to invoke the tool. However, it gives no guidance on when to use this tool instead of related sibling tools, nor any when-not-to-use conditions.

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?

While annotations handle basic safety (readOnlyHint: true), the description provides essential behavioral transparency by enumerating the specific data points available (short interest, FTDs, volume ratios). This defines the full operational scope of the tool.

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 structure is highly effective for a command-based tool. It is concisely front-loaded with the overall topic, followed by a clean, easily parsable list format where each command is clearly separated and defined.

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

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

Given the complexity of the tool (seven sub-commands) and the absence of an output schema, the description is complete. It defines the purpose and required inputs for every single available operation, allowing the agent to select and invoke correctly.

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

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

Because the input schema is empty, the description must carry the semantic weight. It clearly defines that all available commands require a 'ticker' parameter, providing the crucial definition that the schema fails to deliver.

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 tool's purpose is immediately clear: accessing UnusualWhales short selling data. It goes beyond a simple statement by detailing seven specific sub-purposes (FTDs, interest float, volume ratios), defining its specialized domain within finance.

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 functions as a detailed usage guide by mapping distinct user intents to specific commands (e.g., use 'ftds' if you need failure to deliver data). This allows the agent to precisely select the correct function within the tool family.

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

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

Annotations already establish the safe read-only, idempotent, open-world profile. The description adds behavior beyond that: 'spot_exposures_by_expiry' is marked DEPRECATED, and 'ownership' is marked PREMIUM with an explicit contact support@unusualwhales.com upgrade requirement, which is genuine auth/plan context. It stops short of describing rate limits or output shape.

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

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

The length is justified by the 50-command dispatcher surface, and it is front-loaded with the purpose sentence before the command list. Each command line is a compact single entry, though the description never names the dispatch parameter itself, leaving the calling convention implicit.

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 very high-complexity tool with an empty schema and no output schema, the description covers the command surface but omits key mechanics: how the command is passed, and what any of the commands return. It is workable but leaves obvious gaps an agent would need to close by trial.

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 input schema is an empty object, so the description is the sole source of parameter documentation, and it does compensate by listing required and optional arguments for all ~50 commands. It still omits types, formats, and enum values (candle_size, stance, option_type, side), so the compensation is partial rather than complete.

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 ('Access UnusualWhales stock data') and enumerates the data domains covered (options chains, greeks, IV, OHLC candles, open interest). It is clear what the tool does, but it does not distinguish itself from overlapping siblings like uw_options and uw_flow, which cover the same options/greeks/flow surface.

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 per-command list implies when each sub-command applies and embeds useful routing hints (required vs optional args, DEPRECATED and PREMIUM flags). However, there is no explicit guidance on when to use this aggregate tool instead of uw_options/uw_flow/uw_technicals, so the agent must infer the boundary from the command names 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 establish readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds real value by listing the supported indicator set, but it says nothing about data granularity, lookback windows, rate limits, or what the time series returns.

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 one-line purpose followed by a tight bulleted command and a compact indicator list; little waste. The indicator enumeration is long but earns its place as the only source of that vocabulary.

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?

The schema is an empty object with no properties, yet the tool is described as taking a command and a ticker. The description never explains how an agent supplies those inputs, and with no output schema it also omits any hint of the returned data shape. This is a material gap 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?

With zero parameters in the schema, the baseline is 4. The description usefully supplies the indicator vocabulary the empty schema lacks, though it does not clarify how ticker, indicator choice, or timeframe are actually conveyed at call time.

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

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

The description names a specific verb+resource ('Access technical indicator data for stocks') and enumerates the supported indicator set (SMA, EMA, RSI, MACD, etc.), which clearly scopes the tool. However, it never distinguishes itself from the sibling tool 'get_technical_indicator', and the internal 'command' named technical_indicator collides with that sibling name, leaving the boundary ambiguous.

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 versus uw_stock, get_technical_indicator, or any other sibling, and no stated prerequisites or conditions. The single 'command' is mentioned but the description never explains when an agent should reach for it over the alternative technical-indicator tool.

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