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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile and external-data reach are covered. The description adds genuinely new behavior beyond that: the briefing bundles three distinct source types and guarantees 'every item cited', which tells the agent the output is sourced and verifiable — a trait not present in the annotations. It omits latency/cost implications of a composite multi-source call, so a 4 rather than 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?

A single dense sentence that front-loads the tool's identity and then enumerates outputs, with no filler. The trailing 'Every item cited' is a compact, load-bearing guarantee rather than 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, so the description carries the burden of describing the return, and it names the three content blocks adequately. But for a two-parameter composite tool it leaves the 'days' window semantics unexplained and gives no clue about result shape (sectioned? per-source counts?), so an agent knows roughly what it gets but not how the inputs shape 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 description coverage is 0% for both parameters. The description never mentions 'ticker' (2-6 char string) or 'days' (1-30 window), so the agent gets no explanation of what the window controls — presumably it bounds filings and headlines but not the annual revenue trend, which is left ambiguous. With the schema silent and the description silent, the parameter layer is a real gap.

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

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

States a specific verb+resource ('one-shot briefing on a chip company') and enumerates its contents: SEC filings, revenue trend, and headlines. However, it never distinguishes itself from the siblings chip_news and chip_company_filings, which cover subsets of exactly this payload, so an agent can't tell from the description alone why it would pick this composite over the granular tools.

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

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

The phrase 'one-shot' implies an aggregate call versus the narrower sibling tools, which is a usable hint, but the description never says explicitly when to prefer it over chip_news or chip_company_filings, nor does it state any prerequisites such as ticker format or freshness expectations. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: the upstream data source (SEC EDGAR), the form types returned, the exact coverage universe, and a deliberate data gap (no stock prices). It still omits pagination/limit behavior, but with annotations present this is a solid addition.

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 tightly-packed sentences with zero waste; the resource and data source are front-loaded, and the exclusion is a natural trailing clause. Nothing could be cut without losing information.

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

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

The description establishes data source, covered entities, and one exclusion, which is good. But with 0% schema coverage and no output schema, it leaves the calling behavior of `limit` (max 30) and `includeRevenue` unexplained, so an agent still has gaps to call it optimally.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It partially compensates: the ticker list constrains valid `ticker` values and the enumerated form types inform the `forms` parameter. But `limit` and the non-obvious `includeRevenue` boolean are left 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?

States a specific verb+resource: retrieves recent SEC EDGAR filings (10-K, 10-Q, 8-K, etc.) and annual reported revenue. It also enumerates the exact company set covered, which pins down scope tightly and clearly separates it from news- or briefing-oriented 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 resource ('filings and revenue for these tickers'), and there is one useful negative boundary: stock prices are excluded. However, no alternative is named and there is no explicit when-to-use or when-not-to-use guidance relative to siblings like chip_news or chip_briefing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety/freshness profile is covered. The description adds genuine behavioral detail beyond that: results come from external publisher RSS feeds and links point to the publisher. It omits default recency window, default result count, and ordering, which matter for a news feed.

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

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

Three tight sentences with the resource and sources front-loaded, then filter semantics, then link behavior. No filler and nothing repeated from the name or 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 does well to say results are headlines whose links go to the publisher. But for a 3-parameter tool at 0% schema coverage, the missing defaults and ranges for 'days' and 'limit' leave an agent guessing at the shape of a minimal 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%, so the description must carry the load. It does explain 'query' well (all words must appear in the title, with examples), but 'days' and 'limit' are entirely undocumented — no defaults, no indication that days is capped at 30 or limit at 40 — so half the parameters remain opaque.

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

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

States a specific resource and scope: 'Recent chip/semiconductor headlines from publisher RSS feeds', and even enumerates the five sources, so an agent knows exactly what content comes back. However, it never contrasts itself with the closest sibling, chip_briefing, which likely also returns news-like content; the differentiation is left to the reader.

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

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

The description establishes context (publisher headlines) and that the keyword filter is optional, with examples ('nvidia', 'tsmc 2nm', 'export'). It gives no guidance on when to prefer this over chip_briefing, chip_company_filings, or export_control_lookup, so usage is implied rather than stated.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds meaningful behavior beyond them: the response is provenance-backed with per-figure source URLs and verbatim quotes, and the tool resolves either canonical ids or common names. It does not discuss failure modes for unknown inputs, which keeps it short of a 5.

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

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

Two sentences, both front-loaded: purpose and the citation guarantee come first, then accepted inputs. The id enumeration is bulky but earns its space given the absence of an enum or parameter description in the 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 must carry return-value expectations and does so at a high level (figures, source URLs, exact quotes). For a single-parameter, closed-domain lookup it is nearly self-sufficient; only the concrete response structure and error behavior for invalid ids remain unstated.

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 there is no enum, so the description carries the full burden and does: it defines the accepted value domain (id or common name), gives worked examples (H100, MI300X, TPU v6e), and enumerates all ten canonical ids. That is more than the schema's bare minLength/maxLength constraints convey.

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 ('spec sheet for one accelerator') plus the differentiator that every figure carries an official source URL and exact quote. The singular scope ('one accelerator') cleanly separates it from compare_chips and list_chips in the sibling set.

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 through the singular scope; the description never explicitly says when to pick this over compare_chips or list_chips, nor states prerequisites such as when a common name vs. canonical id is acceptable. The enumerated ID list is helpful context but is input guidance rather than when-to-use 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 only declare readOnlyHint and openWorldHint=false. The description adds real behavioral context beyond that: each cell is cited (sourcing/provenance), unpublished values render as '—' (missing-data handling), and dense vs sparse throughput are kept separate (no aggregation). It does not mention rate limits or latency, but for a read-only tool the disclosure 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?

Two dense sentences, zero filler. The metric scope and the 2–6 range lead, and the output-format caveat (cited cells, '—' for unpublished) is packed into the trailing clause 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?

There is no output schema, and the description does compensate by describing the return surface (per-metric cells, citations, dash for missing values). The remaining gap is that a portion of the metrics enum and the chip-identifier input format are left for the agent to decode from the raw schema.

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

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

Schema description coverage is 0%, so the description carries the burden. It partially compensates by enumerating metric families (memory, bandwidth, FP8/BF16/FP4 throughput, power, process) and restating the 2–6 range, but it omits several enum members (memoryType, int8, transistors) and says nothing about the string identifier format expected in 'chips'.

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 (Compare) and resource (accelerators/chips) plus the scope of the comparison (memory, bandwidth, throughput, power, process). It is distinguishable from chip_specs and list_chips by the word 'side by side', though it never names those siblings or explicitly contrasts with them.

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

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

The use case (comparing multiple accelerators at once) is implied by 'side by side' and the 2–6 cardinality, but there is no explicit when-to-use statement and no routing guidance versus chip_specs (single-chip lookup) or list_chips. An agent must infer that this is the multi-chip comparison path.

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 read-only/open-world safety profile, and the description adds real context beyond them: what the call returns (license requirement/policy and Federal Register citation) and a material legal caveat that results are advisory only. It stops short of disclosing matching behavior (fuzzy vs exact) or result-count handling.

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

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

Front-loaded with the core action, then filters, then return value, then caveat — a sensible ordering. The parenthetical list enumeration is long but carries genuine disambiguation value, so it earns its place; only slight compression would help.

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 correctly assumes responsibility for the return value ('license requirement/policy and Federal Register citation'). Combined with the source list, filter coverage, and legal caveat, an agent has enough to call it correctly, though match semantics remain unaddressed.

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

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

Schema coverage is 0%, so the description must compensate. It names the 'list' and 'country' filters and effectively decodes the cryptic enum values by spelling out the underlying lists (Entity, MEU, Denied Persons, Unverified, Treasury/State), but the required 'name' parameter and the 'limit' cap are never explained, leaving part of the burden unmet.

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 ('Screen') and resource ('US government's Consolidated Screening List') and enumerates the constituent lists (BIS Entity List, MEU, Denied Persons, Unverified List, Treasury/State). An agent immediately knows this is a sanctions/export-control name check, which is wholly distinct from the chip-focused 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 phrasing ('Screen a company or person name') and the 'screening aid only, not legal advice' caveat signals its role, but there is no explicit statement of when to use this versus any alternative, nor of prerequisites such as minimum name length. Adequate but not directive.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds useful dataset context ("curated, source-cited spec dataset"), but says nothing about return format, ordering, or result size for a list operation.

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

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

A single front-loaded sentence with the verb and resource first, and the optional filter last. Tight, though the parenthetical vendor list slightly crowds the core statement.

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

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

For an optional single-param list tool with no output schema and read-only annotations, the description covers purpose, data source, and filtering. Only the return shape and pagination behavior remain unspecified, which is a minor gap.

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

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

One parameter at 0% schema description coverage, so the description must carry the load. It does explain the vendor filter's purpose and names plausible values (NVIDIA, AMD, Google TPU, AWS Trainium), but does not specify expected casing or exact accepted strings.

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

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

States a clear verb (List) and resource (GPUs/AI accelerators in the spec dataset), and scopes the dataset with concrete vendor examples. It does not explicitly distinguish itself from chip_specs or compare_chips, which is the only gap.

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

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

"Optionally filtered by vendor" implies when the vendor param matters, but there is no explicit when-to-use or when-not guidance and no routing to alternatives like chip_specs for a single chip or compare_chips for comparisons.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and data-source bounds are covered by structured fields. The description adds genuine value beyond them by scoping the content to 'leading-edge logic' nodes and asserting per-entry citation from the foundry's own page, establishing provenance. It does not describe return shape or whether the node list is 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?

Two tight sentences, content-first, with the scope qualifier and provenance claim front-loaded and no filler. It packs foundry list, covered attributes, and the chip-mapping secondary purpose into minimal space.

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

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

For a read-only reference lookup with one optional parameter and no output schema, the description covers subject matter, facets exposed, scope boundary, and source provenance. The remaining gap is the omitted-parameter behavior and any indication of result size or ordering.

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

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

The single 'foundry' parameter has an enum that enumerates its legal values, but schema description coverage is 0%, and the description never references the parameter at all. It therefore leaves the default behavior (what is returned when foundry is omitted) unstated, though the enum keeps the baseline at a middling 3.

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 (leading-edge logic process nodes at TSMC/Samsung/Intel Foundry) and names the payload fields (transistor type, production status) plus a chip-to-node cross-reference. It is clearly distinguishable from chip-level siblings like list_chips or chip_specs, though it never names those siblings explicitly.

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

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

There is no when-to-use guidance or alternative routing. Nothing tells the agent when to consult this map versus chip_specs or compare_chips, and nothing explains that the foundry argument is an optional narrowing filter rather than a requirement.

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