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

With no annotations, the description carries the full burden, and it does disclose useful behavior: the delisted flag, first/last dates of price history, and the free-tier 12-month coverage limitation. However, it says nothing about permissions, error behavior, or whether the symbol must be a US-listed ticker, so it is only partially complete.

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, both load-bearing: the field inventory is front-loaded and the free-tier caveat follows. No filler, though the second sentence could be tied more explicitly to why it matters for this 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 and no annotations, the description usefully enumerates return fields and notes the data coverage window. For a single-parameter reference lookup, this is close to sufficient; only permission/format details are 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 should compensate. It implies the symbol is a US stock or ETF ticker, which adds some meaning beyond the bare 'Symbol' property, but it never clarifies format, exchange suffix, or case sensitivity.

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 the specific resource (reference profile for a US stock or ETF) and enumerates the exact fields returned, so an agent can tell it apart from data-heavy siblings like fundamentals, prices_daily, and financial_statements. It lacks an explicit verb and never names a sibling, so it is clear but not maximally differentiated.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. The closing note about free-tier data being limited to 12 months implies context about coverage but does not route the agent to or away from any sibling.

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

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

With no annotations, the description carries the full burden and does well: it discloses row ordering (newest week first), units (contracts), and a tier constraint (free tier limited to the last 12 months). It omits pagination, rate limits, and what happens if market/code are both omitted, which is a real gap for a zero-required-param 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?

Dense and front-loaded: the dataset definition comes first, then the recommended usage, then report meanings, then behavioral notes. Slightly long sentences with embedded clauses, but no 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 5-param tool with no annotations, no output schema, and no schema descriptions, the description covers a lot but leaves the start/end date parameters and the semantics of calling with no market/code at all undefined. There is no way to know the default result scope of a no-argument 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?

Schema description coverage is 0% across 5 params, so the description must compensate. It does for market (a word from the market name), report (three enumerated values with column semantics), and code (delegated to cot_markets), but start and end are never mentioned at all, leaving two parameters entirely 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?

Names a specific dataset (CFTC Commitments of Traders), its cadence (weekly), its shape (long/short/net contracts by trader group) and its domain (futures markets). It also names the sibling cot_markets as the lookup path, so an agent can separate the two without opening either schema.

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

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

Gives a concrete recommended invocation (market="gold" with report="legacy_fo"), names valid report alternatives (disagg_fo, tff_fo), explains what each column family means, and routes exact-code lookups to cot_markets(query=...). When-to-use and the alternative are both explicit.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful traits: the default report (legacy_fo), the shape of each result (name and code), and a real constraint — free-tier dated COT history is limited to the last 12 months. It omits pagination, rate limits, and whether markets vary by report, so it is not exhaustive.

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

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

Front-loads what the tool returns, then filtering, then the hand-off to 'cot', then the tier caveat. Four compact clauses 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?

Covers output contents, parameter usage, downstream tool routing, and a tier limitation — enough for an agent to call and use the result despite no output schema or annotations. The missing enumeration of valid 'report' values is the one notable 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 must compensate. It does well for 'query' by giving concrete examples ('gold', 's&p 500', 'crude') that clarify matching behavior, and it names the default for 'report'; however, it never enumerates valid report values, so an agent can only safely use 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 and resource ('list of futures markets available in the Commitments of Traders data') and specifies what each entry contains (name and code), which distinguishes it clearly from the sibling 'cot' tool that consumes its output.

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?

Tells the agent to pass 'query' to filter by market name and explicitly routes downstream work to the 'cot' tool using the returned code/market, which is a concrete usage flow. It does not state when to choose this over 'cot' directly or when a non-default report is appropriate, 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?

With no annotations present, the description carries the burden and does add real behavioral context: the free-tier restriction to the last 12 months is a meaningful availability/limit disclosure, and the explicit 'No EPS or forecasts' sets scope expectations. It omits any auth or error behavior, but for a read-only lookup this is solid.

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

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

Three tight sentences with no filler. The core resource and source are front-loaded, the scope exclusion follows, and the tier limitation is placed last where it belongs.

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

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

For a single-parameter, no-output-schema tool, the description covers what is returned, from where, and the coverage limitation, which is enough to call it correctly. It does not address behavior on invalid tickers or symbols with no filings, 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?

One required parameter at 0% schema description coverage. The description conveys the parameter's role ('for a ticker') but says nothing about expected ticker format, exchange suffixes, or case sensitivity, so it does not fully compensate for the empty schema description.

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

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

States a specific resource (past earnings release dates for a ticker), the authoritative source (SEC 8-K Item 2.02 filings), and the exact fields returned (report date, filing time US Eastern, before-open/after-close). This is immediately distinguishable from siblings like company_profile, fundamentals, or financial_statements.

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 resource name rather than stated. The negative scoping line 'No EPS or forecasts' usefully redirects an agent away from this tool for estimate data, but no alternative sibling is named and no prerequisites or when-to-use condition 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?

With no annotations, the description must carry the behavioral burden. It does disclose real traits: values are in US dollars, output is one row per period, and the free tier silently truncates results to periods filed in the last 12 months. It does not state read-only nature, error behavior for unknown tickers, or how many periods are returned on paid tiers.

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-loaded with the resource and then the parameter meanings, followed by the units and tier constraint. Every clause carries information, though the semicolon-chained structure is slightly heavy to parse.

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

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

For a 3-parameter, no-annotation, no-output-schema tool, the description covers parameter value sets, currency, row granularity, and a tier-based data limit. Missing only ticker format conventions and paid-tier history depth, which are minor for correct invocation.

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

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

Schema description coverage is 0% and no enums are declared, so the description must compensate—and it does: it enumerates the accepted 'statement' values (income, balance, cashflow) with the fields each contains, and the 'freq' values (quarterly, annual). Only 'ticker' format is left implicit, though it is self-evident.

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 (standardised financial statements from SEC filings) with a clear scope qualifier (US company) and enumerates the statement types it returns. It does not distinguish itself from the overlapping sibling 'fundamentals', so an agent cannot tell from the description alone which of the two to pick.

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 resource (fetch a company's income/balance/cashflow statements) and the free-tier note hints at a data-availability constraint, but there is no explicit when-to-use guidance, no named alternative, and no mention of prerequisites such as a valid ticker or subscription tier.

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?

No annotations are provided, so the description carries the full disclosure burden. It does well on two fronts — the exact return shape (concept, unit, value, start, end, fy, fp, form, filed) and the tier-based 12-month limitation on results. It stops short of covering pagination/row limits or the fact that many concepts may be absent for a given filing.

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

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

Three sentences, front-loaded with the resource and return columns, then narrowing behavior, then the sibling alternative and tier caveat. Every clause carries information; nothing is redundant padding.

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

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

With no output schema, the description compensates by naming the returned columns, and it covers the concept filter and the free-tier scope limit. It is nearly complete for a two-parameter read tool, missing only result-volume/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 0%, so the description must compensate, and it does for the ambiguous parameter: 'concept' is explained as a single us-gaap concept with three concrete example tags (NetIncomeLoss, Assets, RevenueFromContractWithCustomerExcludingAssessedTax). 'ticker' is left implicit as an obvious company identifier, with no format guidance.

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

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

States a specific verb+resource ('Raw SEC XBRL facts a company reported in its 10-K/10-Q filings'), enumerates the returned columns, and explicitly distinguishes itself from the sibling financial_statements. An agent can tell instantly that this is the raw-fact tool rather than the derived-statement 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?

Gives both directions of routing: use this tool for raw facts, optionally narrowed by concept; 'For ready-made income statements, balance sheets and cash flows use financial_statements instead.' It also adds a scope caveat (free tier returns only the last 12 months), which affects tool selection.

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

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

With no annotations, the description carries the full burden and does add real behavior: one row per transaction, the fields returned (shares, price, value), currency semantics, and a 12-month history cap on the free tier. It omits permissions/auth requirements, pagination or result-size limits, and what happens when both filters are omitted, so it stops short of full disclosure.

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

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

Three sentences, front-loaded with purpose, then output shape, then the tier constraint — no filler. It is slightly dense but every sentence contributes, and the most decision-relevant facts come first.

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 commendably describes the returned row shape, and it flags the free-tier history cap. However, for a four-parameter, no-required-parameter tool it leaves the date filters and the both-filters-omitted case unexplained, so an agent cannot fully predict the query 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 description coverage is 0% across four parameters, so the description must compensate. It loosely covers ticker and owner, but 'start' and 'end' are never mentioned, and no format (date string shape) or filtering semantics are given for the date range that the 12-month note implies exists.

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 resource (insider transaction filings) and enumerates the subtypes it covers (buys, sells, option exercises) plus the query keys (ticker and/or owner name). This is unambiguous against siblings like company_profile or fundamentals, though it never explicitly routes the agent away from any other tool, which is what a 5 requires.

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 company ticker and/or an owner name' implies the conditions under which the tool is the right pick, and the free-tier note tells the agent a limitation exists. There is no explicit when-to-use/when-not guidance and no named alternative, 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?

With no annotations, the description carries the full behavioral burden and does real work: it specifies the return shape (one row per observation date), the unit semantics (series' own units, index points/percent/millions), and an important tier constraint (12-month history cap with older dates clipped). It stops short of disclosing error behavior for invalid series IDs or any 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?

Three front-loaded sentences, each carrying distinct payload: what it returns, in what units, and under what tier limit. 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?

There is no output schema, and the description usefully covers the return shape in its place. But with zero annotations and two of three parameters undocumented in both schema and description, plus no pointer to how series IDs are obtained, an agent still has gaps before it can call this reliably.

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 3 parameters. The description meaningfully clarifies 'series' by giving example values, but 'start' and 'end' are untyped-string params with no stated format (ISO date? YYYY-MM-DD?), no relationship to the 12-month clipping rule, and no default behavior. Partial compensation, not full.

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 ('time series for a macroeconomic indicator') and grounds it with concrete series IDs (CPIAUCSL, UNRATE). An agent immediately knows it fetches a numeric history. However it never distinguishes itself from the sibling macro_search, which is presumably how you find those series IDs, 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?

There is no when-to-use or when-not-to-use guidance and no mention of the macro_search alternative for discovering series identifiers. The only implicit context is that you supply a series ID, which the example list partly conveys. Usage is left entirely 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?

Without annotations, the description carries the burden and adds useful behavioral context: it discloses keyword matching against series id and title, the exact return fields, and a free-tier limitation on fetching history. Minor omissions like pagination or limit semantics prevent 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?

Three tightly written sentences, front-loaded with the core action and followed by return details and a critical caveat. Every sentence earns its place with no filler.

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

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

For a simple search tool with no output schema and no annotations, the description covers purpose, matching behavior, return fields, and a tier limitation. It omits details about the limit parameter and result pagination, so it is not fully exhaustive.

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

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

Schema description coverage is 0%, so the description must compensate. It explains query (keyword matched against series id and title) and category, but does not mention the limit parameter at all, leaving a clear 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 (search) and resource (catalogue of macroeconomic series), and distinguishes itself from the sibling macro tool by explaining it is used to pick a series id for that 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?

Clearly indicates the tool is used to find a series id before calling the macro tool. Lacks explicit exclusion criteria (e.g., what to do if the id is already known), but the 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?

With no annotations, the description carries the full burden and does well: it discloses the row granularity, listing currency, default adjustment behavior, the free-tier 12-month cap, and that clipping produces a free_tier_note in the result. It omits auth requirements, pagination, and error behavior, so it falls 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?

Two dense sentences with the core purpose front-loaded and no filler. The parentheticals ('e.g. AAPL', the adjust default, the free-tier note) all carry information, though the second sentence is slightly overloaded.

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 the description does describe the return shape and an extra result field well, and it flags the tier limit. However, with four undocumented-in-schema parameters, the missing start/end semantics leave the definition incomplete for correct invocation.

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

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

Schema description coverage is 0%, so the description must document all four parameters. It covers symbol (with an AAPL example) and adjust (splits/dividend, 'splits' by default), but says nothing about start or end — no date format, inclusivity, or defaults — leaving the two filtering parameters undocumented everywhere.

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

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

The description uses a specific verb+resource ('Daily OHLCV bars for a stock symbol') and even spells out the columns returned (open, high, low, close, volume). It is unambiguously a price-history tool, which no sibling covers, although it never explicitly distinguishes itself by name from the fundamental/macro siblings.

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

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

Usage is implied by the domain ('daily bars for a symbol') and the free-tier clipping rule gives useful context on when results are trustworthy, but there is no explicit when-to-use/when-not statement or pointer to any alternative tool.

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

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

With no annotations, the description carries the burden and does fairly well: it discloses the granularity of the result, the units ('share counts, not dollars'), and an important behavioral limit (free tier clips history older than 12 months). It still omits whether the call is read-only, pagination/row limits, and any auth or rate-limit 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 tight sentences, zero filler, and the payoff (what you get back) is front-loaded before the free-tier caveat. 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?

Since there is no output schema and no annotations, the description's explanation of the returned rows and the tier-based truncation is valuable and mostly sufficient for the return side. However, with three undocumented parameters and no output schema, the undefined start/end semantics leave a real gap for an agent trying to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate for start/end/ticker, and it does not. The date range parameters get no format, timezone, or default-behavior explanation, and only 'ticker' is self-evident from the sentence.

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

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

It names a specific verb+resource (short interest history for a ticker) and describes the returned row shape ('one row per settlement date with shares sold short and related figures'). That is clearly distinguishable from insiders/cot/prices_daily, though it never names an alternative, so it stops short of a 5 by the rubric's sibling-differentiation bar.

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 you call this to obtain short interest data for a ticker, and the free-tier clipping note gives a practical constraint. There is no statement of when to prefer this over a sibling tool (e.g., cot) and 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.