Silicon Floor

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the 2–12 symbol operating range and the fact that each company's fundamentals come with a stated date and basis, which tells the agent the figures are point-in-time and comparable.

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

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

Two sentences, zero filler, with the returned measures and the cardinality bound front-loaded before the usage trigger. Every clause carries information an agent can act on.

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

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

There is no output schema, so the description carries the return burden and does it: it enumerates the compared measures and notes the date/basis provenance. The single parameter is fully specified in the schema, so nothing needed to call this correctly is missing.

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

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

Schema coverage is 100% and minItems/maxItems already enforce the 2–12 bound, so the description's '2 to 12 companies' is confirmatory rather than additive. It does not clarify accepted symbol formats (ticker vs. name) or that names are resolved, so the baseline 3 is appropriate.

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

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

States a specific verb+resource ('Returns 2 to 12 companies side by side') and enumerates the measures compared (price move, market cap, revenue/growth, margins, price/sales, trend). The multi-symbol scoping clearly separates it from the single-company get_company and the criteria-driven screen_companies.

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

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

Gives an explicit trigger — 'Use it when the user asks to compare companies' — so the agent knows the intent that selects this tool. It stops short of naming alternatives (e.g., screen_companies for criteria-based discovery or get_company for a single name), so there are no stated 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 it read-only, non-destructive and closed-world, so the safety profile is covered. The description goes well beyond that: it discloses data provenance (SEC XBRL filings, sec.gov page numbers, FINRA settlement data) and freshness semantics ('Every figure carries the date it holds for'), plus how debt and float are counted. That is meaningful context 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?

Front-loaded correctly with the verb and resource, and the use-case sentence closes it. However, the entire payload is crammed into one run-on sentence of roughly a hundred and fifty words with nested parentheticals, which makes it hard to scan and would benefit from breaking the coverage list into a short structured list.

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

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

There is no output schema, so the description carries the full burden of describing what comes back, and it does so exhaustively, section by section, including freshness and source per figure. Nothing an agent needs to decide whether this tool answers a given company question is missing.

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

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

There is a single parameter with 100% schema description coverage, including ticker-vs-name examples and case-insensitivity, so the schema does the work. The description adds only the implicit 'one company' framing and no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Returns one company's current snapshot') and then enumerates the payload precisely: price/session, performance, 52-week range, SEC XBRL fundamentals, balance sheet with sec.gov page references, beta/r², FINRA short interest and volume, SEC profile. An agent can tell this is the single-company aggregate snapshot rather than a list or comparison tool. It never names or contrasts the overlapping siblings get_financials, get_price_history or get_market, so it stops 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?

Ends with an explicit trigger: 'Use it when the user asks about one company's price, market cap, valuation, fundamentals or risk.' That is clear context for invocation. There are no exclusions and no routing to alternatives, which is a real gap given siblings like get_financials and get_price_history that cover a subset of the same ground.

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

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

Annotations already cover safety (readOnlyHint=true, openWorldHint=false, destructiveHint=false), so the bar is lower, yet the description adds real behavioral context: the projection cap rule ('projections never exceed the measured coverage'), the foreign-issuer fallback, and the reliability caveat 'Estimates, not advice.' Missing details like pagination or data freshness keep this from 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?

The return contents are front-loaded in the first clause, followed by the fallback modes and the usage trigger. It is dense but every sentence carries information; the multi-clause first sentence is slightly heavy but not padded.

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

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

With no output schema and two optional parameters, the description responsibly covers both calling modes, the ranking cap behavior, the fallback for unranked issuers, and the estimate caveat. An agent has enough to call it correctly, though the shape of the numeric fields (yield units, currency) is left unspecified.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining what omitting 'symbol' actually yields (the highest-yielding payers and possible initiators) and by framing 'limit' as ranking rows, reinforcing the schema text rather than merely repeating parameter names.

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 and resource ('Returns a company's dividend data') and then enumerates the exact contents: yield, per-share amounts, growth, cash-flow coverage, and observed payments. This is clearly distinguishable from sibling tools like get_financials or get_price_history, and the no-symbol fallback (highest-yielding payers, possible initiators) is stated up front.

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

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

Explicitly states the triggering user intents: 'Use it when the user asks whether a company pays a dividend, how much, or which companies yield the most.' It also implicitly defines the two calling modes (symbol vs. omitted symbol). It stops short of naming an alternative tool or an explicit when-not-to-use case, so it is clear guidance without exclusions.

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

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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), so the description's job is to add context — and it does: eight-quarter history depth, the SEC filing behind each period, pre-restatement values, and a permanent page address for citation. That is meaningful behavior beyond the annotations, though it says nothing about rate limits or response 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?

Two sentences: the first front-loads what is returned and its depth, the second routes to the sibling tool. Every clause earns its place with no 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, the description carries the return-value burden and does so: it enumerates the filing linkage, prior/restated values, and permalink. For a two-parameter, annotated, read-only tool this is sufficient to call correctly.

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

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

Schema coverage is 100% and both parameters are already documented, including the enum. The description restates the four metric options but adds no syntax or format detail (e.g., acceptable ticker vs. name handling beyond the schema's own example). Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource — returns one figure for one company over the last eight quarters — and enumerates the covered metrics. It explicitly distinguishes itself from get_financials, so an agent can route between 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 an explicit when-to-use ('when the user wants a figure verified, cited or traced to its filings') and names the alternative with the condition that selects it (every statement line over 12 quarters / 6 fiscal years → get_financials). Nothing is left to inference.

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

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

With readOnly/destructive annotations already covering the safety profile, the description still adds real behavioral context: insiders are excluded unless requested, insider activity is aggregated over 90 days by filer role rather than name, and filings are dated by acceptance time rather than filing date. These are non-obvious semantics an agent could not infer from structured fields.

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

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

Front-loaded with what is returned, then exclusions, then the usage trigger. Dense but every clause carries information; the trailing classification list ('amount, coupon, maturity, status, the sentence it comes from') is slightly verbose but still earns its place.

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

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

For a 3-parameter read tool with no output schema, the description covers return content, the extra insiderFlow90d field, default exclusions and date semantics. It stops short of describing ordering of results or what happens when no filings exist, minor gaps given the strong coverage.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining the meaning of `insiders` (what gets included and how insiderFlow90d is computed) and the acceptance-time basis for ordering/limit. `limit` itself gets no extra detail beyond the schema.

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

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

States a specific verb and resource ('Returns a company's recent SEC filings') plus the classification scheme and the fields each carries. It also distinguishes itself from insider-oriented siblings by explicitly scoping out Forms 3/4/5/144 by default.

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?

Ends with an explicit trigger: 'Use it when the user asks what a company has filed, announced, borrowed or raised recently.' It clarifies the insider opt-in condition, but does not name a sibling (e.g. get_insider_trading) as the alternative when the user wants insider data, so routing is implied rather than stated.

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

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

Annotations already cover safety (readOnly, non-destructive, closed-world), and the description adds substantial operational detail beyond them: null means the company did not file that line, computed lines are labeled, cash outflows are negative, amounts are in filing currency, and FPI/20-F vs 6-K treatment. This is exactly the extra context the annotations do not carry.

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

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

It is front-loaded with the core purpose, but the body is one dense block cramming multiple special cases (20-F, 6-K, ASML/Nebius/STMicro, TSMC releases, guidance trio) without structural breaks. Most content earns its place, yet the density and lack of segmentation cost readability.

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

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

No output schema exists, so the description carries the full return-shape burden and does so thoroughly: period coverage, line count, per-period filing linkage, null semantics, sign conventions, currency, and the alternate breakdowns/outlook modes. An agent has enough to call and interpret it correctly.

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

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

Schema coverage is 100% so the baseline is 3, and the description still adds real semantic meaning: it explains what statement=breakdowns and statement=outlook return, what revenueBy and customerConcentration expose, and the fiscal-year-vs-quarter behavior of basis for foreign issuers. Labels like 'Customer A' are clarified beyond the schema.

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

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

States a specific verb and resource (returns income statement, balance sheet, cash flow as filed in XBRL) with scope (last 12 quarters / 6 fiscal years, 30+ lines). It is clearly distinguished from siblings like get_filings and get_company because it enumerates the exact statement content plus derived fields (revenueBy, customerConcentration, guidance).

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

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

Explicitly says when to use it: 'Use it when the user asks for a company's revenue, earnings, balance sheet or cash flow over several periods.' It lacks an explicit when-not / named-alternative clause (e.g., pointing to get_filings for raw filings), so it is strong context without exclusion guidance.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial domain behavior: the 45-day 13F filing deadline, what the default quarter resolves to, the 'wave' behavior for quarters still being filed, and the crucial caveat that flows are share changes valued at quarter price rather than changes in declared value.

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

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

The purpose and routing are front-loaded, but the middle is one very long semicolon-chained sentence enumerating every returned sub-section; against the absence of an output schema this earns most of its length, yet it is denser than it needs to be.

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

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

With no output schema, the description compensates by enumerating the return contents, and it supplies the default-resolution logic, filing-window semantics, and caveats an agent needs to interpret results correctly. Nothing material is missing.

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

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

Schema coverage is 100%, so both parameters are documented. The description still adds meaning for 'quarter' by explaining the default ('latest quarter whose 13F deadline has passed') and the wave behavior, going beyond the schema's terse enum description; it says less about 'limit'.

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 (returns) and resource (what institutional managers did with tracked AI/semiconductor stocks from SEC Form 13F filings), and distinguishes itself from siblings by explicitly naming get_holders and get_ownership as the tools for single-fund or single-company questions.

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

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

Explicit when-to-use trigger ('Use it when the user asks what hedge funds or institutions bought or sold in a quarter') plus clear routing to alternatives for one fund/person and one company's shareholders.

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

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

Beyond the annotations (readOnly, non-destructive, closed-world), the description discloses genuine caveats: `coverage.complete` false means figures are a floor, `performance` measures declared picks rather than a fund's return, and a person can have two divergent figures for one company (Form 4 shares vs Schedule 13D/G beneficial ownership) that must be disambiguated. These are non-obvious data-quality warnings an agent could not infer from annotations.

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

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

Purpose is front-loaded, but the explanatory block is one enormous, comma-spliced sentence whose clauses (heldSince, history, performance, follow, breakdown) are hard to scan. The volume is defensible for a five-parameter multi-mode tool, but the structure is dense enough to impede rapid parsing.

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

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

There is no output schema, so the description must carry the return-value burden, and it does: it enumerates the fields returned in each mode (positions with shares/value/weight, sectors, flows, 13D/G declarations, history since 2019, performance with rank, follow/Atom feed, person breakdown). Nothing an agent needs to interpret results is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description still adds meaning: it spells out the accepted `holder` forms (key, company name, person name plus ticker such as 'Larry Ellison (ORCL)') and what each `list` mode returns. It goes beyond restating the schema, though the schema already covers most of this ground.

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

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

The opening sentence gives a specific verb and resource ('Returns what investors hold in the tracked AI and semiconductor companies, from SEC filings') and immediately splits the behavior into the with-`holder` and without-`holder` modes. It names sibling tools (get_ownership, get_insider_trading, get_fund_flows) as key sources, so an agent can place it in the toolset without opening a schema.

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

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

It states clearly when to use it: 'Use it when the user asks what a fund, an investor or a person owns, or which managers bought, sold or performed most,' and describes the conditions that select each mode. It stops short of explicit when-not guidance or a direct alternative ('use get_ownership instead when...'), so it earns a 4 rather than a 5.

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

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

Annotations already cover the read-only, non-destructive safety profile, and the description layers on rich domain behavior: what is counted vs excluded (grants, option exercises, tax withholding, gifts, inter-insider transfers), the quarter-boundary rules and the two-business-day Form 4 deadline, data availability from Q3 2024, and the Rule 10b5-1 caveat on large sales. This is well 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?

Front-loaded with the purpose and tightly written, but the middle is one dense semicolon-chained sentence covering counting rules; it is long, yet most clauses carry information an agent needs. Slightly heavier than necessary but no padding.

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

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

There is no output schema, and the description fully enumerates the returned structures (totals, largest sellers/buyers with role/company/dates/holdings, most-bought/sold companies, by-role and by-month totals, first Form 3 filers). Combined with the default and range semantics, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so both parameters are already documented. The description nevertheless adds meaning the schema lacks: why the default is the last *closed* quarter, what `quarter: 'current'` means ('the quarter in progress, to date'), and the range floor (Q3 2024). The `limit` parameter is left to the schema.

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

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

States a specific verb and resource ('Returns the purchases and sales that executives, directors and 10% owners ... reported on SEC Form 4 for one quarter') and enumerates the exact contents returned. It explicitly separates itself from siblings get_ownership (one company) and get_holders (one person), so an agent can route without opening either schema.

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

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

Gives an explicit trigger ('Use it when the user asks what insiders bought or sold in a quarter') plus two named alternatives with the condition that selects them: get_ownership for one company, get_holders for one person. Nothing is left to inference.

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

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

Annotations only declare a safe read of a closed world; the description adds real substance with the valuation methodology ('that day's close (adjusted for share splits only) × the shares outstanding at that date from SEC filings'), units (USD, weights as fractions), and the fact that the last point is today's. It omits any note on refresh cadence, data latency, or cost, so it falls just short of a 5.

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

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

Front-loads what is returned and the trigger condition before the methodology digression, which is the right order. Sentences are long and dense with parentheticals, and the `view: 'map'` behaviour is effectively stated twice, so there is mild redundancy, but no filler.

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

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

With no output schema, the description carries the return-shape burden itself and does so: it names the series fields, the map fields, units, and the time granularity (daily up to a year, weekly over five years). It also pre-empts a likely misreading by explaining that `enteredOn` denotes an IPO rather than a data gap, which is exactly the kind of edge case an agent would otherwise bungle.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by tying the parameters together — how `view: 'map'` pairs with `date`, how `sector` switches the breakdown from segment-level to company-level, and how `range` drives point spacing. It still repeats rather than extends the schema's segment enumeration, keeping it out of 5 territory.

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

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

Opens with a specific verb and resource ('Returns the tracked companies as one market over time: combined market cap, the weight of each segment or company, and traded dollar volume') and then distinguishes its two modes. It is clearly separable from siblings like get_market_overview and get_price_history.

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?

States an explicit trigger ('Use it when the user asks how the sector, a segment or a company's weight has changed over a period, or where trading volume is going') and names the alternative for the near-neighbour case ('For today's snapshot, use get_market_overview'). Both when-to-use and the routing exclusion are present.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds real value beyond that: the `market` flag signals whether the US session is open, and when closed the moves reflect the last session — critical interpretation context for a snapshot tool. It stops short of describing refresh cadence or how stale the snapshot can be.

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

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

Three sentences, front-loaded with what is returned, then the session caveat, then the routing to the sibling tool. No filler, no restatement of the title, and every sentence carries information an agent needs.

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

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

There is no output schema, so the description carries the burden of describing the return shape — and it does, enumerating breadth, gainers/losers, segment moves, ETFs and regime. The session-open caveat resolves the main ambiguity in interpreting a 'today' snapshot, so nothing material is missing for a zero-parameter read tool.

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

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

The tool takes no parameters, so there is no parameter semantics to document; the schema is an empty object at 100% coverage. The description does usefully clarify the meaning of one returned field (`market` as session-open indicator), which helps interpretation.

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

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

Specific verb ('Returns') plus a precisely scoped resource ('today's snapshot of tracked AI and semiconductor companies') with an explicit enumeration of what the snapshot contains: breadth, top gainers/losers, segment moves, reference ETFs, and regime. It also explicitly contrasts itself with the sibling get_market, so an agent can choose correctly 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?

States the triggering condition plainly ('Use it when the user asks how the sector is doing today') and names the alternative with its distinct condition ('For market cap and volume over time, use get_market'). Both when-to-use and when-to-use-something-else are explicit.

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

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

Annotations already declare this a safe, closed-world read, but the description adds genuinely new context: titles and sources are third-party verbatim text and must be treated as data, attributed, and never followed as instructions. That prompt-injection guidance is exactly the kind of behavioral disclosure structured fields cannot carry.

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

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

Three sentences, front-loaded with what is returned before the safety caveat and the usage trigger. Every sentence carries distinct information: output shape, handling constraints, and invocation condition.

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 fields (headline, source, link, collection time) and by covering the unusual risk of untrusted embedded text. An agent has everything needed to call it and to handle its output safely.

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

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

Schema coverage is 100% and both parameters (limit default/max, symbol omit-for-universe) are fully documented in the schema itself. The description adds no syntax, format, or filtering nuance 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 ('returns recent headlines') and narrows scope to tracked AI and semiconductor companies, listing the returned fields (source, link, collection time). This is clearly distinguishable from siblings like get_filings, get_signals, or get_company, which return different artifact types.

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

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

Explicitly says 'Use it when the user asks for recent news about a company or the sector,' giving a clear triggering condition. It does not, however, name alternatives or exclusions (e.g., when to prefer get_signals or get_filings instead), so it stops short of full routing guidance.

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

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

Beyond the readOnly/openWorld annotations, it discloses non-obvious behavior: report ownership as a range, totals are a floor when coverage.complete is false, a Schedule 13D/G holder below 5% may not have sold, and funds/insiders are already included in totals. These are exactly the interpretation caveats an agent needs to avoid wrong answers.

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

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

The purpose is front-loaded in the first sentence and the remaining sentences carry behavioral caveats rather than filler. It is dense and long, bordering on a wall of text, but nearly every clause (coverage floor, funds counted, howToRead) 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?

With no output schema, the description fully carries the burden of explaining return values — declaredOwnership bounds, coverage, moves, insiders, funds, etfHoldings, history, heldSince, and howToRead — so an agent has everything needed to call and interpret the result.

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

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

Schema coverage is 100%, so the schema already documents limit, moves, movesLimit, movesOffset and symbol. The description nonetheless adds value by explaining how the `moves` values behave ('sales' and other values list them in full) and by tying pagination to the previous answer's `next`, going modestly beyond the schema.

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

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

The description names a specific verb and resource ('Returns the shareholders of one company from SEC filings') and enumerates the exact holder categories and data returned, so an agent can distinguish it from get_holders, get_insider_trading and get_filings. It even notes the `holder` field is accepted by the sibling get_holders, reinforcing the boundary.

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

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

It gives explicit trigger conditions ('Use it when the user asks who owns a company, who its largest shareholders are, or who bought or sold its shares') plus how to interpret and report results. It does not, however, state when to prefer a sibling tool (e.g., get_holders) instead, leaving the alternative-selection decision implicit.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), yet the description adds substantive behavior beyond them: the adjustment methodology (split-adjusted into today's shares, dividends/spin-offs excluded), the row-ordering convention (oldest first), the column ordering, and the hard 5-year horizon. These are exactly the traits an agent needs to interpret the numbers correctly.

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 and dense: the return shape, adjustment policy, encoding, and usage trigger each get roughly one sentence with little padding. The 'Compact: `fields` names the columns once...' sentence is slightly opaque and refers to a non-existent parameter, mildly weakening the structure.

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

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

With no output schema, the description carries the full burden of describing the return value, and it does: columns, row ordering, column-major encoding, and the adjustment caveat. Combined with the documented depth limit and the usage trigger, nothing essential for a correct call is missing.

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

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

Schema coverage is 100%, so the schema already documents both symbol and sessions, making 3 the appropriate baseline. The description does contribute the 'about 1,260 sessions / five years' ceiling that contextualizes the schema's max of 1300, but it also references a `fields` parameter that does not exist in the schema, which muddies rather than clarifies parameter semantics.

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

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

The description gives a specific verb and resource ('Returns daily bars') and enumerates the exact columns (date, open, high, low, close, volume), the depth (up to five years / ~1,260 sessions), and the adjustment policy. By stating that 'dividends and spin-offs [are] not subtracted,' it implicitly separates itself from the sibling get_dividends, so an agent can route correctly without opening another schema.

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

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

It provides a clear positive trigger: 'Use it when the user needs price data for a chart or a calculation.' That is real usage guidance rather than mere restatement, but it names no alternative sibling (e.g. get_dividends for dividend-inclusive data, get_figure_history for charts) and states no exclusions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: every edge is a filed fact tied to a proving document, private companies appear as nodes with no price or financials, and depth=2 fans out to neighbours' relationships. It stops short of describing result ordering, pagination shape, or behavior when the center is ambiguous.

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

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

The core purpose is front-loaded, but it is then delivered as a single sprawling em-dash sentence stuffed with dozens of illustrative examples (Fabrinet, Cirrus Logic, TeraWulf, ZT Systems, and more) that repeat what the enumerated nature list already conveys. The length is far beyond what an agent needs to select and call the tool, and the run-on structure hurts parseability.

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 complex multi-parameter graph tool with no output schema, the description does substantial work: it explains what each relationship carries (title, stated value, term, megawatts, signing date, document) and what changed hands for acquisitions. Missing is any indication of ordering, truncation behavior with limit, or how empty results present, which the absent output schema would otherwise have to cover.

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

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

Schema coverage is 100%, so every parameter including center's accepted id forms, natures, status, minShare and since is already documented in the schema. The description's depth:2 explanation largely restates the schema's own wording ("its neighbours' too"). With the schema doing the heavy lifting, baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource ("Returns the relationship graph around a company, an investment house or a person") and enumerates the exact edge types it yields (owns, invests_in, holds_rights_in, customer_of, agreement_with, acquired) with concrete examples. It explicitly differentiates itself from siblings get_ownership and get_holders, so an agent can route correctly 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?

It states the trigger conditions directly: "Use it when the user asks how companies are connected, who is behind a company, or what links two of them." It also names the two alternatives and the conditions that select them — get_ownership for a full shareholder list with bounds and moves, get_holders for one investor's portfolio.

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 read-only, non-destructive, closed-world behavior, so the safety bar is covered. The description goes beyond them by disclosing the scorecard's replay windows (1, 5, 20 sessions over five years benchmarked against SMH), which meaningfully characterizes the output content.

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 return content before the usage guidance. The first sentence is dense but every clause (replay windows, benchmark) carries information; nothing is redundant.

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

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

For a read-only, two-parameter, no-output-schema tool, the description sufficiently explains both what is returned (signals plus historical return scorecard) and when to call it. Nothing needed by an agent to invoke it correctly is missing.

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

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

Schema description coverage is 100%, with limit (default 20, max 50) and symbol (omit for whole universe) fully documented in the schema. The description adds no parameter-level detail 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 — returns rule-based technical signals logged on tracked companies — plus the scorecard of historical replay returns. This is clearly distinguishable from siblings like get_price_history or get_market, which cover price data rather than logged signals and their backtest performance.

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

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

Explicitly says when to use it: user asks about recent technical signals or how a signal type has performed historically. It gives clear context but names no alternatives or exclusions, so an agent must infer that other tools cover raw price/news 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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the returned attribute set (ticker, name, segment, market cap) and the fact that filtering is optional, which matters because there is no output schema. It omits pagination or result-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 sentences, zero padding, with the core listing behavior front-loaded and usage tucked behind it. Every clause carries information the schema does not.

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, non-destructive, two-optional-parameter listing tool with full schema coverage and annotations, the description covers purpose, usage and return fields. No output schema exists, and the description compensates by naming the returned columns.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description restates the segment filter and the name/ticker search without adding syntax, casing rules, partial-match behavior, or defaults, so the baseline of 3 is correct.

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

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

The description names a specific verb and resource ('Lists the AI and semiconductor companies tracked by Silicon Floor') and enumerates the fields returned (ticker, name, segment, market cap), which is more than a restatement of the name. It does not explicitly distinguish itself from adjacent siblings such as screen_companies or get_company, so it stops short of a 5.

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

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

It gives concrete intended uses: 'find a company's ticker' or 'see which companies a segment contains.' That is clear when-to-use context, but it names no alternative tool (e.g. screen_companies for richer filtering) and states no exclusions, so it falls short of the explicit when/when-not/alternatives bar.

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 this a safe read (readOnlyHint, destructiveHint=false), and the description goes further by disclosing non-obvious edge semantics: a company lacking the filtered figure is NOT treated as below threshold but surfaced in `notComparable` with a reason. That is exactly the kind of behavior an agent could otherwise get wrong.

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, zero filler: purpose and filter set first, usage trigger second, edge-case return semantics last. Every sentence earns its place and the most decision-relevant information is front-loaded.

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

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

With no output schema, the description carries the return-value burden and covers the most important non-obvious part (notComparable plus reason). It is nearly complete for a 9-param tool, though the shape of the main comparable result list is left implicit.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's '40% / 60%' example usefully reinforces that margins and growth are passed as fractions, but it adds no syntax or format detail beyond what the schema already documents for each parameter.

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 (filters) and resource (tracked companies) plus the exact filter dimensions and sort behavior, which cleanly separates it from enumerating siblings like list_companies and single-entity siblings like get_company.

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

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

Explicitly says when to use it — 'when the user asks which companies meet numeric criteria' — and reinforces with a concrete example (

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

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

Annotations cover only the safety profile (readOnly, non-destructive, closed-world), yet the description discloses the window default and 90-day cap, the default materiality ranking order, line-grouping behavior for repeated filings, and the meaning of `move`/`moves`/`previousPercent`/`changeVsPrevious`. Critically, it explains the `complete: false` truncation signal and the remediation ('narrow `since` or pass `symbol`'), which no annotation or schema field conveys.

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

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

Front-loaded with purpose and default behavior before drilling into field-level detail, and every sentence is informative. It is nonetheless a dense single block with heavy em-dash nesting, and the 13D/G and 13F field explanation sits close to the boundary of what belongs in a tool description versus a response schema.

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

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

With no output schema, the description carries the full burden of return-value semantics, and it does: it defines the default vs raw modes, the ranking, the row-level `move`/`moves` fields, and the `complete`/`coversFrom` contract. An agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains why `highlights` groups rows by materiality and what `detail: 'events'` yields (raw chronological list). It reiterates defaults already in the schema (7-day window, limits), which is redundant, but the mode semantics are genuinely additive.

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

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

States a specific verb and resource — 'returns what was recorded since a given date' — and enumerates the exact event classes it covers (SEC filings, restatements, technical signals, ownership declarations). It sets the tool apart from siblings by declaring 'Price moves are not events here (see get_company)', so an agent can separate this cross-source digest from per-source feeds.

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

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

Gives explicit use cases ('a daily or weekly brief, or when the user asks what changed since a date') and an explicit exclusion that routes the agent elsewhere ('Price moves are not events here (see get_company)'), naming the alternative tool by name. This is when/when-not guidance, not inference.

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