MORVS

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the covered universe size, that ERAs are included alongside RIAs, and the exact field set returned including the Item 11 disciplinary-disclosure flag. It does not discuss match behavior (exact vs prefix vs fuzzy) for the name query.

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

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

Three short sentences with zero filler: scope first, returned fields second, coverage caveat last. Everything is front-loaded and each sentence carries distinct information.

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

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

With no output schema, the description correctly takes on the burden of naming the return fields (CRD, type, RAUM, state, Item 11 flag) and the population covered. That is close to complete for a read-only lookup; only ranking/pagination behavior and the name-matching semantics 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 100%, so both q (name, >=2 chars) and limit (default 25, max 100) are fully documented in the schema; baseline 3 applies. The description reinforces that search is by firm name but adds no syntax, matching, or ordering 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 ("Search SEC-registered investment advisers") and scopes it to firm-name lookup, with explicit inclusion of Exempt Reporting Advisers and the covered universe (~23.4k). It stops short of differentiating from the closest sibling, advisers_flagged, so an agent must infer the boundary between the two.

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 "by firm name" and by the required q parameter, so an agent can reasonably infer this is the name-lookup entry point. However, there is no explicit when-to-use guidance, no mention of when to prefer advisers_flagged for the disciplinary-disclosure angle, and no stated fallback if the name is not found.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: the result ordering by disclosure count and the approximate dataset size (~2,291 advisers), which helps the agent anticipate result 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 tight sentences, zero filler. The primary purpose (what the dataset is) is front-loaded, with the filtering options relegated to the trailing clause.

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, but the description compensates by naming the underlying filing (Form ADV Item 11), the ranking dimension, and the dataset magnitude, which is enough for an agent to know what comes back. It stops short of describing pagination behavior for the limit parameter.

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

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

Schema coverage is 100%, so the schema already documents each parameter, giving a baseline of 3. The description goes further by spelling out the value vocabularies for 'type' (RIA/ERA) and 'kind' (criminal/regulatory/civil), which the schema lacks as enums and only describes in loose prose.

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 (SEC-registered investment advisers), the exact data basis (Form ADV Item 11 disciplinary disclosures), and the ordering (ranked by disclosure count). An agent can distinguish this from adviser_search because the description scopes it to disciplinary-flagged entities only.

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 enumerates the filters (state, type, kind) so the agent can infer how to narrow a query, but it never states when to use this tool versus the sibling adviser_search, nor any exclusions or prerequisites. Usage is implied rather than guided.

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 readOnly, idempotent, non-open-world, non-destructive behavior, so the safety profile is covered. The description adds real context beyond that: the place_id key format, the 2022 dataset vintage, and the fact that this is an aggregate federal statistic with zero PII.

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

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

Two dense sentences, front-loaded with the search action and the returned identifier before the downstream payoff. 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-value burden and does so by specifying the place_id format and what it unlocks. It stops short of describing result shape or pagination behavior for limit, 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?

Schema coverage is 100%, so q and limit are fully documented in the schema itself. The description adds nothing about parameter semantics (e.g., how partial names match, what limit controls), so the baseline 3 for schema-carried parameters 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 (Search) and a precisely-scoped resource (USDA Census of Agriculture) filtered by county/state name, and even names the return artifact (place_id). No sibling tool shares this resource, so an agent can route to it without ambiguity.

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: search by name to obtain a place_id that another tool consumes for farm-economy figures. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., crop_insurance_search), leaving the agent to infer the workflow.

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?

Although annotations already declare readOnlyHint=true and openWorldHint=true, the description adds substantial behavioral context: data freshness rules (verdicts become unknown after 9 days), error handling (failed reads reported as temporarily unavailable), response size limits (~25 KB), and nuanced caveats about robots rules not being a licence and refusal vs no answer. This goes well beyond the annotations.

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

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

The description is a single, extremely long and dense paragraph with run-on sentences. The purpose is front-loaded but buried inside a sprawling first sentence, and the volume of detail, while informative, makes it hard to scan. Every sentence may earn its place in terms of content, but the structure is not concise.

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

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

Given the tool's complexity (6 optional parameters, no output schema, annotations already present), the description is thorough: it covers filtered and unfiltered outputs, response limits, data freshness, error handling, and important caveats about interpretation. An agent has enough context to call the tool correctly.

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

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

Schema description coverage is 100%, so all parameters are already documented in the input schema. The description lists the filters and gives examples, but adds little semantic detail beyond what the schema provides—for instance, it repeats that token shows a home-path verdict, which is already in the schema description. 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 specifies what data the tool returns—rows and headlines from the Closed to Machines register—and details the optional filters. It does not, however, explicitly distinguish itself from sibling tools like agent_access_institution or agent_access_route, leaving the agent to infer its role as the general query endpoint.

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

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

The description explains what happens when filters are provided versus when no inputs are given, which implies usage. But it offers no explicit guidance about when to choose this tool over alternatives such as agent_access_changes or agent_access_check_url, and no exclusions are stated.

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

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

Annotations only cover read-only/idempotent/open-world, while the description adds genuinely operational facts: append-only from a build-day baseline, never backfilled, capped at 25 entries newest-first, verdicts go unknown when data exceeds 9 days, failed reads return 'temporarily unavailable' rather than an empty answer, and responses stay under ~25 KB. A large share of the remaining text is policy caveat (robots-not-licence, refusal vs no-answer) that is useful context but less actionable.

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

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

One enormous run-on sentence plus several dense paragraphs of disclaimers; the invocation-relevant content (since/host/kind, 25-entry cap, ordering) arrives late. Substantial material — which agencies and countries are registered, curl and urllib checks from a residential vantage, no person is named — is background that does not help an agent decide or call.

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 cover response shape (uncertainty[], as_of, vantage, source page, notes), failure behavior, staleness and result limits — enough to call it correctly. It is complete on substance but achieves that completeness by dumping everything rather than prioritizing.

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 schema already defines since, host and kind with formats and examples. The description echoes the same meaning ('a host the register covers', 'a change kind ID, such as register_created') without adding syntax or selection logic beyond the schema, which is the baseline-3 case.

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

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

The core purpose (a change log of the Closed to Machines register, filtered by since/host/kind) is stated, but it is buried mid-way through a 200-word opening sentence dominated by register provenance detail. Nothing distinguishes it from the closely related siblings agent_access, agent_access_institution, agent_access_route or agent_access_check_url, so an agent cannot tell from the text which entry point 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?

There is no when-to-use or when-not-to-use guidance, and no sibling is named. The description explains what the register contains and what the answers look like, but never says why an agent would call this change log rather than agent_access or agent_access_institution.

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?

Even with readOnly/idempotent/openWorld annotations already present, the description adds substantial behavior: the server never requests the site, verdicts go unknown after 9 days, register read failures surface as temporarily unavailable rather than empty, answers are capped near 25 KB, and refusal vs no-answer semantics are spelled out. It also pre-empts a likely misinterpretation by stating that a robots rule is a request, not a licence, and that no record shows a reason for a refusal.

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 content is dense and largely earns its place, but it is delivered as a single run-on opening sentence and a wall of subordinate clauses; key facts (no network request, 9-day staleness, default token) are not front-loaded. An agent must parse a paragraph to reach the operational essentials.

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 tool with rich enum-style outputs and no output schema, the description enumerates the robots.result classes, the edge observation, the official route sub-object, and next_step, plus absence and error behaviors. Nothing material needed to call or interpret the tool 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 already 100%, so the baseline is 3; the description still adds value by explaining that the exact path and query are evaluated (not just the host), that product_token defaults to MORVS when omitted, and that an unlisted token is evaluated without a group. That meaningfully exceeds the schema text.

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

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

The description states a specific verb and resource: it evaluates a register's archived robots.txt rules for one exact URL and one product token, under RFC 9309, without fetching the site. It implicitly differentiates from siblings like agent_access and agent_access_institution by stressing per-path verdicts ("the same host gives different verdicts for different paths"), but it never names those siblings explicitly. The purpose is unambiguous once parsed, though it is buried inside an enormous opening sentence.

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 rather than stated: you submit a URL (and optional token) when you want the robots verdict for that exact path. It tells the agent how to read results (next_step values, unknown for uncovered hosts, staleness handling) but gives no explicit when-to-use/when-not versus the many sibling agent_access_* tools.

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

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

Beyond the read-only and idempotent annotations, it discloses important behavioral caveats: robots rules are not licences, refusals are edge responses rather than institutional policy, absent data is not proof of no route, stale data beyond 9 days makes verdicts unknown, and failed reads are reported as temporarily unavailable. It also states the response size limit and privacy boundary (organisations only, no named individuals), which materially helps the agent interpret results.

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

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

The description is a dense wall of text with nested qualifications and caveats, not front-loaded or structured for quick parsing. While much of the content is useful, it is far longer than needed and would benefit from bullet points or separate sections.

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

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

Given the tool's complexity and the absence of an output schema, the description thoroughly enumerates the returned fields: institution, authority, CISA registry match, result class, robots facts, token verdicts, dated checks, routes, change log, and GSA scanning. It also covers data freshness, error handling, and response-size limits, so an agent has enough context to invoke it correctly.

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

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

Schema coverage is 100%, so the single query parameter is already well documented. The description adds examples and the multiple-match behavior, but does not add syntax or format details beyond what the schema provides; 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 states a specific resource and scope — one row of the Closed to Machines register — and explains what that register contains. It does not explicitly differentiate itself from sibling tools such as agent_access, agent_access_changes, or agent_access_route, leaving the agent to infer which one to use.

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 specifies acceptable query forms (host, institution name, jurisdiction, ISO code, row ID) and notes that multiple matches are returned in short form. However, it gives no explicit when-to-use guidance relative to the closely named sibling tools, 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?

Although annotations already declare a safe read-only, idempotent, open-world operation, the description adds substantial behavioral context: uncertainty handling, as_of freshness, vantage, robots-not-licence caveats, route-state distinctions, failed-read semantics, and output size limits. It actively prevents common misinterpretations, such as treating a single answer as permission or a no-answer as a refusal.

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

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

The description is extremely long, with multiple nested parentheticals and caveats packed into enormous sentences. The core action and required parameter are buried inside a dense first sentence, making it hard for an agent to quickly scan the tool's purpose and call requirements.

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 compensates by explaining the returned fields, route review states, uncertainty[] lead, as_of, vantage, source page, and licence. It also covers freshness degradation, malformed-read handling, and absence of permission, so an agent has enough context to interpret results 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 100%, so both parameters are already documented in the input schema. The description repeats the supported institution_or_host forms and record_type examples, and adds the useful detail that up to 25 matching rows are returned, but it does not materially expand parameter semantics 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 clearly states that the tool finds official machine routes to an institution's data, gives the retrieval key, and describes the record types returned. It does not explicitly distinguish itself from sibling tools such as agent_access, agent_access_institution, or agent_access_check_url, so an agent must infer which one to use.

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

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

The description implies when the tool is useful: looking up an institution's reviewed data route by host, name, jurisdiction, ISO code, or row ID. It does not state when to use this tool instead of nearby siblings or what alternatives exist when a lookup fails or when a different view is needed.

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, the description discloses the return shape and many operational constraints: up to 5 buyers, year-delivered estimated values, rank, five largest notices, outside-totals notices, side-by-side FARA records, withheld single-person firms, and the treatment of names matching only withheld strings. It also states important semantic limits, including that values are estimates, not prices or payments, and that records are never added or sequenced.

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

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

The purpose is front-loaded, but the description is extremely dense and repetitive, repeatedly restating that side-by-side records are never added or sequenced with notices. It contains useful caveats, but they are packed into long run-on sentences that make the definition harder to scan than necessary.

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

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

With no output schema and a very complex return payload, the description supplies extensive detail about returned fields, value semantics, FARA side-by-side treatment, withholding rules, and legal caveats. An agent would have enough context to understand what the tool returns and how to 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?

The schema already documents the single required name parameter at 100% coverage, including case-insensitivity and an example. The description adds meaningful matching semantics: substring matching across the buyer name, the purchaser as printed in notices, or a DOJ country string.

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: it looks up a buyer government in the Arms Sales Register by substring of its name, purchaser string, or DOJ country string. It also enumerates the returned buyer-level records and distinguishes the buyer view from notice-level data by describing notices, values, ranks, purchaser strings, FARA money, and side-by-side fields.

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 context is clear: this is the buyer-oriented lookup tool for matching a name or country string against the register. However, it never names or explicitly contrasts sibling tools such as arms_sales_notices, arms_sales_contractor, or arms_sales_summary, so the agent must infer the boundaries.

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?

Far exceeds what the annotations declare: it discloses the 5-family result cap, that empty columns are a non-result rather than a negative fact, that estimated values are shared and never split or treated as revenue, that side-column records must not be summed or date-sequenced with notices, withholding behavior for single-person firms, and that withheld-only matches are indistinguishable from no match. Annotations only supply read-only/idempotent/open-world hints, so this context is genuinely additive.

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 massive paragraph where the front-loaded first sentence is strong but the body repeats the same caveats three or four times ('shared, never split', 'never added together', the notice-is-not-a-sale warning). The critical search semantics are buried under legal and provenance boilerplate with no structural separation.

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 one parameter, the description carries the full burden and does: it enumerates every returned column group, the provenance and as-of dates for each, the caption and licensing carried with answers, and the FEC restriction quote. An agent knows what comes back and how to 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% and the schema parameter already says case-insensitive substring of family name or printed company string, up to 80 chars. The description largely mirrors that but adds that matching is against the reviewed family name specifically and that up to 5 families come back — modest but real added meaning.

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

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

The first sentence states a specific verb and resource — look up a contractor family in the Arms Sales Register by a substring of the reviewed family name or of a printed company string — and the return payload is enumerated concretely. It never names the sibling tools it sits beside (arms_sales_buyer, arms_sales_notices), so the agent must infer the routing from the tool name alone.

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

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

There is no statement of when to reach for this versus arms_sales_notices, arms_sales_buyer or arms_sales_summary; the description only describes behavior once called. The 'institutions only' restriction constrains what queries are meaningful but does not route the agent between alternatives.

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

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

Annotations already declare read-only, idempotent, open-world and non-destructive behavior, but the description goes far beyond them: 25-row cap, most-recent-first ordering, full count inclusion, held company names, totals excluded for undated and withdrawn notices, separate treatment of enhancement reports, and the mandatory question note and caption. This is exceptionally rich behavioral 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?

The key purpose and filters are front-loaded in the opening sentence, but the description then sprawls into a dense paragraph with repeated caveats (e.g., value never added across families appears more than once). Much of the latter content is valuable, but the whole is longer and less scannable than ideal.

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 tool with no output schema, the description supplies all the return-shape, exclusion, total, and disclaimer information an agent needs to interpret results correctly. It is arguably overcomplete, but nothing essential 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%, so every parameter is already documented, including the type enum and contractor's notice-only restriction. The description repeats those semantics rather than adding new syntax or defaults beyond the schema, so 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?

First sentence states a specific verb (list) and resource (proposed sales notified to Congress in the Arms Sales Register), plus the filter dimensions. It clearly distinguishes this as the general list versus narrower siblings like arms_sales_buyer or arms_sales_contractor, 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?

The description explains behavioral conditions well—contractor filter applies to notices only, without a contractor filter you get counts and values, with one you get per-family counts—but it never states when to use this tool instead of sibling tools such as arms_sales_summary or arms_sales_buyer. Usage is implied rather than routed.

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 read-only and idempotent safety, but the description adds substantial behavioral context: values are estimates never prices or contracts, enhancement reports are counted apart and never summed with 36(b)(1) values, separate record types must not be combined, withdrawn and undated notices are listed outside totals, and every answer must carry a question note, as-of dates, source and licence. It also discloses the FEC restriction and that single-person firms are withheld, which goes well beyond the annotations.

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

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

The description is a dense wall of semicolon-linked clauses that enumerates every section of a very large output. While each clause carries some content, the lack of paragraphing and the run-on style make it hard to scan, and the core purpose is buried under enumeration; it is over-specified rather than under-specified.

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

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

For a zero-parameter, no-output-schema summary tool, the description covers the returned sections extensively (totals, top buyers, windows, contractor families, counter-findings, gaps, trust fund, headlines) and the required accompanying caveats. It is nearly complete on content, though the dense structure reduces how usable that completeness is.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description appropriately focuses on output content rather than inventing 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 opening states a specific resource and scope: totals from the Arms Sales Register built from Federal Register 36(b)(1) notifications since 2017. It is clear what the tool returns in aggregate, but it never distinguishes itself from siblings like arms_sales_notices, arms_sales_buyer or arms_sales_contractor, so an agent cannot tell from the description alone why it should pick this summary over those detail 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?

There is no explicit when-to-use guidance, no statement of alternatives, and no exclusions about when other sibling tools are more appropriate. The long caveats about not adding records together are interpretive rules, not routing guidance, so the agent is left to infer that this is an overview 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?

The description adds substantial behavioral context beyond the annotations: it identifies the underlying data source (CBP monthly use-of-force and assault files, FY2021 onward), explains the return content (yearly or monthly figures for incidents, force types, officers/agents using force, assaults), clarifies counting semantics (officers counted per incident, not unique people injured), notes that the current fiscal year is labeled partial, explicitly states that no rates or causation are provided, and describes non-match behavior. This is rich, transparent 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?

The description is front-loaded with purpose and scope, then moves through return content, counting semantics, and limitations. It is dense but mostly earns its length given the complexity. Some phrases (e.g., repeating that an area is 'never a city or an operation') could be trimmed, but overall it is well-structured.

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 a good job explaining the content of the return (yearly or monthly figures, incident counts, force types, etc.). It could be more explicit about the response structure (e.g., list of matching areas with nested data), but for an agent selecting and invoking the tool, the description covers the essential context, including data provenance and limitations.

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 schema already documents all three parameters thoroughly. The description repeats the key semantics (area as a sector/field-office substring, fiscal_year behavior) but adds little beyond what the schema provides. Baseline 3 is appropriate 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?

The description states a specific verb and resource: 'Look up a CBP area of responsibility in the Border Force Register... by sector or field-office name substring.' It is clear what the tool does. However, it does not mention the sibling tool border_force_national, so an agent cannot tell from the description alone how this differs from the national-level lookup.

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: you need a sector or field-office name substring, and the area must be a CBP office area, not a city or operation. But there is no explicit statement of when to use this versus border_force_national, nor any when-not guidance. The agent must infer the appropriate context.

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 read-only/idempotent annotations, the description discloses important provenance and interpretation constraints: revisions are as-published versions not corrections, DHS and CBP use different definitions and are never merged, and no rates or causation are provided. This is exactly the kind of contextual nuance annotations cannot convey.

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

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

The description front-loads the primary national totals before secondary DHS-table and revision-log caveats. It is dense and somewhat run-on, but every clause carries relevant data-provenance or interpretation information rather than filler.

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

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

With no output schema, the description still provides a thorough account of what is returned: yearly totals by force type, personnel counts, assault incidents, source files and dates, optional revision logs, DHS table status, and definitions caveats. An agent has enough context to call and interpret the tool correctly.

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

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

The only parameter is fully documented in the schema, so the baseline is 3. The description adds meaningful semantics by explaining that fiscal_year also brings that year's revision-log entries and by reinforcing that those entries are as-published versions, not corrections.

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

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

The description states a specific resource and scope: national yearly totals from CBP use-of-force and assault files, broken down by force type, personnel, and assault incidents. The explicit 'National yearly totals' scope distinguishes it from the area-level sibling tool without needing to name it.

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

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

The description gives clear context for when this national/yearly dataset applies, including the FY2021+ range and the partial-current-year label. It does not explicitly name the sibling border_force_area as the alternative for sub-national data, so it stops 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 read-only, idempotent and open-world, and the description goes well beyond them: it discloses the ~25 KB answer cap, licence-per-checkbook, the absence-note semantics for empty results, the rule that figures are never summed across governments with differing periods/units, and that payee names come from a reviewed allow-list and some fields are withheld. These are behavioural facts an agent cannot infer from structure.

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

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

The description is a several-hundred-word run-on built from semicolon-chained clauses with no headings, lists or paragraph breaks, and it repeats the same points ('never summed', 'each with its own period and unit', 'kept apart') multiple times. The purpose is front-loaded, but the density makes the payload hard to extract and several sentences do not earn their 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?

There is no output schema, and the description takes on that burden fully: it enumerates the per-government payload (totals by family, up to 25 payment rows, with row-level fields), the multi-government shape, the no-filter shape, and the metadata envelope (as_of, retrieved, licence, question, absence notes). For a tool of this complexity, nothing an agent needs in order to call it and interpret the response 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 the schema descriptions already enumerate the accepted forms for government (name, name+state, state, 2/5/7-digit FIPS), vendor (name or printed alias) and family (ID or label, panel family under lane=panel). The description restates essentially the same content, adding only marginal linkage such as 'a state, or a vendor, family or lane on its own' triggering the multi-government mode, 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?

The opening sentence names the resource concretely (checkbook payments reported by city/county/state governments to reviewed vendors) and grounds it in the 'Bought by Your Police' register, so an agent knows what it returns. However, it reads as a long noun phrase rather than a clean verb+resource statement, and it never distinguishes this tool from the sibling bought_by_your_police_vendor.

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 does describe what each argument combination produces (one government = full detail, multiple governments = totals with for_rows, no filters = headlines), which implicitly tells the agent how to shape a query. But it never states when to prefer this tool over siblings, and the closest relative, bought_by_your_police_vendor, is never mentioned.

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

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses substantive behavior: three columns kept apart and never summed, figures never aggregated across governments, an explicit absence note for empty results, a ~25 KB answer cap, a reviewed allow-list restricting payees, person-naming rows dropped, withheld structured fields, and the caveat that payments are not contract values or deployment evidence. This is unusually rich behavioral context.

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

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

The description is an enormous single block that runs through register architecture, lane definitions, caveats, licensing and output fields in comma-spliced prose. It is front-loaded only in the sense that the purpose appears first; everything after is undifferentiated and hard to scan. Much of the enumeration could be trimmed or structured.

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 and does so: it enumerates the reviewed entry's columns, the per-government figures and lanes, the no-payments-found list, the metadata carried in the answer, and the key interpretive caveats. An agent has enough to interpret results correctly, even if the presentation is unwieldy.

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

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

Schema description coverage is 100%, and the schema already documents the vendor parameter with examples (Clearview AI, TALX, Axon) and the 80-character limit. The description's phrase 'its name, or a payee alias as a checkbook prints it' largely restates the schema, adding little beyond it. Baseline 3 applies 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?

The first clause states a specific resource: one reviewed vendor in the Bought by Your Police MORVS register, looked up by vendor name or payee alias. That is a clear verb+resource and distinguishes it from the aggregate sibling bought_by_your_police. Clarity is degraded only because the purpose sentence is buried inside a very long, comma-chained enumeration of return contents.

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

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

The description implies the usage case (look up a single reviewed vendor by name or alias) and mentions the alias input route, but never states when to use this instead of bought_by_your_police or the other vendor-related siblings, nor any exclusions. Usage is left to inference from the tool name and the 'one reviewed vendor' framing.

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/idempotent/open-world safety, and the description goes further by explaining the return shape (per-state notice IDs and counts), the three-day pairing rule for WA/DE records, and the fact that paired dates may legitimately disagree with neither declared correct. It does not mention result caps, pagination, or cost of broad substrings. The 'notifying org may differ from breached org' note is genuinely useful 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?

Front-loaded with the resource and scope, then layered caveats. Five dense sentences, though the 'non-match never means no breach' point appears both in the description and in the parameter description, and the closing caveat about notifying vs. breached organisation slightly undercuts the otherwise tight 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?

For a one-parameter search tool with no output schema, the description explains the returned structure (per-state IDs and counts, paired notices), the pairing rule, and the semantic limits of a non-match. It stops short of stating result-count limits or how pairs with dates beyond three days are surfaced.

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 additionally explains that matching is on public names only (withheld names are excluded from the index entirely, not just from results), which tells the agent that a withheld-name search returns empty rather than a false negative to be interpreted.

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

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

States a specific verb ('find'), a specific key ('public notifying organisations by name substring'), and an explicit corpus ('Washington, Delaware and California Attorney General breach-notice lists'). The state scope alone lets an agent distinguish it from the broader sibling `breach_notices` 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 strong interpretive guidance on when NOT to conclude anything: non-matches never mean 'no breach' because of list coverage, reporting thresholds and name variation, and withheld names are never searchable. It never routes the agent to an alternative tool (e.g. `breach_notices`) for other jurisdictions, so selection guidance is contextual rather than 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 cover read-only/idempotent/non-destructive, and the description adds substantial context beyond them: records omit permitted delays such as law-enforcement requests and omit enforcement outcomes, the timing flag is not a legal finding, and California has no discovery date so no timing is computed. It also discloses data-handling rules — withheld individual-identifying names are never returned or searchable.

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 in the first sentence, followed by interpretation constraints. The caveat block is dense and long, but nearly every sentence carries semantic or legal-interpretation weight rather than filler.

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

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

With no output schema, the description takes on return-value explanation itself — what the timing labels mean, that resident counts are notices sent rather than unique people and are never summed across states, and that Delaware also reports the company's stated total. That leaves little an agent needs to interpret results 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, but the description adds real meaning: the year parameter maps to notice year for WA/DE versus reported year for CA, and beyond_window is scoped to WA/DE and framed as a date-interval label rather than a legal conclusion. It also explains that the notifying organisation may differ from the breached one, which changes how the organization filter should be used.

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 — searching the WA, DE, or CA AG breach-notice lists — plus its filtering dimensions (organisation name, year). It is concrete enough to separate from the sibling breach_notice_organization, but it never names or contrasts with that sibling explicitly, so it falls short of full sibling differentiation.

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

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

Gives clear usage context: filtering is by public notifying-organisation name and year, with the year meaning differing per state, and it warns that absence from these three lists is not evidence of no breach. It does not state explicit exclusions or point to alternatives such as the per-organisation sibling 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?

Annotations already declare the safe-read profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds real context: corpus size (~109,812 facilities, ~32,883 active), the covered service classes, and the explicit exclusion of ownership data. It does not mention pagination or result ordering, which keeps it 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?

Three tight sentences with no filler: scope, corpus magnitude, returned fields, and boundary of coverage. The corpus statistics earn their place by setting result-set expectations. Slightly dense but well 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 and a trivial 2-parameter input, the description carries the return-value burden and does it: it enumerates the returned fields (service, channel, frequency, community, status, license expiration) and bounds the corpus. Nothing needed to call 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% and both parameters are documented in-schema (q as call sign/city with a >=2 char minimum; limit default 25 max 100). The description only restates that q accepts a call sign or community, adding no format or matching-behavior detail beyond the schema, 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?

Specific verb+resource ("Search the FCC broadcast station directory") plus the exact lookup keys (call sign or community of license). The closing scope note ("Station facts only — no ownership") carves it away from the sibling fcc_grantee_search, which the agent can act on 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?

The "no ownership" exclusion implies when to reach for an ownership-oriented sibling instead, but no alternative is named and no when-not conditions or prerequisites are stated. Usage is inferable from the scope note rather than 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral value beyond that: it names the exact returned fields (warnings, component shut-ins, facility shut-ins) and the dataset scope (~674 operators, 1948-2026). It stops short of pagination or result-ordering 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 with zero filler, front-loading what the tool is and following with the return payload and dataset scope. Every clause conveys usable information.

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

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

With no output schema present, the description usefully enumerates the returned enforcement metrics and the dataset's size and time span. It is nearly complete for a simple two-parameter search, missing only routing guidance against sibling tools.

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 q and limit are already documented in the schema with format and bounds. The description only echoes the 'by name' search intent, adding no syntax or matching-behavior detail beyond the structured fields.

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 (Search) plus a well-scoped resource (BSEE offshore operators) with geographic coverage and the returned data named. It clearly distinguishes itself from generic sibling searches, though it never explicitly contrasts with bsee_worst_operators, the nearest related 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?

There is no when-to-use / when-not guidance and no mention of the obvious alternative, bsee_worst_operators, or any sibling. Usage is only implied by the 'by name' wording in the description.

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, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds a genuinely useful interpretive caveat that counts are raw BSEE records and unadjusted for operator size or activity. It does not describe the return shape or ordering ties, which is the remaining gap.

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

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

Two sentences, front-loaded with the ranking purpose followed by the important caveat, with no filler. Every clause carries information.

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

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

For a simple two-parameter read tool with annotations covering safety, the description is adequate, but with no output schema it never states what a result row looks like (operator identity plus count) or how ranking ties/ordering are handled. That leaves the return contract to inference.

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

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

Schema description coverage is 100%, and the schema already documents both 'sort' values and the 'limit' default/max, so the baseline is 3. The description merely restates the sort options already present in the schema without adding format or behavior detail.

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 ('Ranks offshore oil and gas operators') and scopes it to BSEE incidents of noncompliance with the exact ranking dimensions. This clearly separates it from sibling search tools like bsee_search and other 'worst/top' rankers such as chemical_accident_worst or fails_to_deliver_top.

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 what the ranking measures but gives no guidance on when to choose this tool over bsee_search or other BSEE-related siblings, and no exclusions or prerequisites. The enumeration of sort options is parameter detail, not usage guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds meaningful context beyond them: the exact place_id format ({state_fips}-{county_fips}), the covered span (2015-2025), the structure-type breakdown, and a provenance/PII note. It doesn't cover pagination or result-count behavior, but the annotation coverage lowers the burden.

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

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

Front-loads the action (search the survey by county/state name) and then the return value, with no filler sentences. The content-list clause is dense but earns its place by telling the agent what data the place_id unlocks.

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 by specifying the place_id format and downstream data. Combined with full schema coverage for inputs and rich annotations, an agent has enough to call and chain it, though pagination/limit behavior is left to the 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 100%, so both q and limit are already documented in the schema, making the baseline a 3. The description confirms q accepts county/state names and clarifies the output key format, adding marginal value but no syntax or matching-behavior details 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 (Search) plus resource (Census Building Permits Survey) and scope (by county/state name). No sibling covers building permits, so the resource alone differentiates it, and the description's detail on content makes the tool's domain unmistakable.

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?

Implies a two-step workflow by stating it returns a place_id 'to pull a county's residential-construction permit history', giving clear context for when to reach for it. It stops short of naming the follow-up tool or stating when not to use it, so no explicit exclusions or alternatives.

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

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

Annotations cover the safety profile (readOnly, idempotent, not open-world), and the description adds genuinely new behavioral context: the index is partial/local, and returns are limited to counts, products, and narratives that CFPB actually published. It also points to /coverage for completeness verification, which the annotations do not convey.

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

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

Three short sentences, front-loaded with the core action, then scope caveats. No filler or repetition of the title.

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

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

With no output schema, the description usefully sketches the return shape (indexed complaint counts, products, narratives) and warns about data completeness. The main remaining gap is that it never says how to interpret or paginate results, but for a single-parameter read tool this is close to sufficient.

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

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

One parameter with 100% schema description coverage ('Financial firm name (substring)'), so the schema already carries the semantics. The description's 'by company' adds only a restatement, matching the baseline for fully documented schemas.

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

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

States a specific verb and resource ('Search ... CFPB complaint index by company') and immediately qualifies the scope as MORVS's partial local index. An agent can distinguish it from generic search or other *_by_company tools without opening the schema.

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

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

The line 'Check /coverage; this is not the full CFPB database' gives a useful precondition, but there is no explicit when-to-use vs when-not guidance and no named alternative among the many siblings (doj_by_company, company_risk_flags, etc.). Usage is implied rather than directed.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value beyond the structured fields: dataset size (~99k facilities), the FOIA-only provenance, and the semantic meaning of the counts (releases, fires, explosions, deaths).

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 verb and resource, then the return shape, then the scale/provenance. Dense and mostly waste-free, though the closing 'ledger EPA keeps FOIA-only' phrase is more color than operational detail.

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

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

With no output schema and only annotations covering safety, the description correctly compensates by naming the returned fields (accident count, location) and setting expectations about dataset breadth. Minor gaps remain around result ordering and pagination semantics, but nothing needed to invoke it 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%, so both parameters (q, limit) are already documented in the schema. The description restates the facility/parent-company search key and adds nothing about matching behavior (prefix vs. substring, case sensitivity) or the limit, so baseline 3 applies.

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

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

The description gives a specific verb (Search) and resource (EPA RMP hazardous-chemical facilities under Clean Air Act 112(r)) and states the lookup key (facility or parent-company name) plus what is returned (accident count + location). It is clear what the tool does, but it never names the obvious sibling `chemical_accident_worst`, so the agent must infer the split between name-lookup and ranking.

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 framing — it is a name/keyword lookup rather than a ranked list — but there is no explicit when-to-use/when-not statement and no named alternative for cases like 'show me the worst facilities.' Minimum-viable guidance only.

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, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value with the caveat that counts are unadjusted for company size or facility count, which prevents a common misinterpretation of the ranking; it does not describe return ordering or result limits.

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

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

Two tight sentences: the ranking behavior and source lead, and the caveat follows. No filler and nothing repeated from structured fields.

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 ranking tool with no output schema, the description covers what is ranked, the metric, the default, and a key interpretation limit. It omits how many companies are returned and the sort direction, but nothing essential blocks a correct 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 coverage is 100% and the schema lists the three accepted values, so the baseline is 3. The description goes slightly beyond by naming the default ('deaths'), which the schema does not state.

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

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

States a specific verb and resource ('Ranks parent companies by harm') plus the data source (EPA Risk Management Program accident histories), which distinguishes it from chemical_accident_search at the entity level. It does not name the sibling explicitly, so an agent must infer the ranking-vs-search split.

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

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

The description implies usage (ranking parent companies by harm) and documents the sort options with a default, but gives no explicit when-to-use versus chemical_accident_search or when the ranking view is preferable to raw accident search. Guidance is inferred 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?

Beyond the annotations, the description discloses important behavioral context: the returned fields, the distinction between filing (备案) and registration (登记), that neither grants approval, that filings are not distinct models or companies, and that no match does not prove absence. These are substantive caveats that materially affect interpretation.

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

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

The description is dense but front-loaded with the search action, then filters, return shape and caveats. Every sentence carries useful information, though the single-paragraph format could be more scannable.

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

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

For a six-parameter, read-only lookup with no output schema, the description covers searchable fields, filter behavior, return columns, and crucial interpretation limits. It is complete enough for an agent to invoke and interpret results 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 already 100%, so the baseline is 3. The description still adds meaning beyond the schema by clarifying which fields q searches, that brand uses an exact filer legal-name allowlist, that us_list uses confirmed tier A crosswalks, and that province applies only to generative AI rows with a CAC province field.

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

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

The description states a specific verb and resource: search the CAC public generative AI, deep-synthesis and algorithm lists by named fields. It is clear what the tool does, but it does not explicitly differentiate itself from the related sibling china_ai_us_lists, leaving a small gap against the top score.

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 filter-level usage guidance, such as registry defaulting to all and province applying only to generative AI rows, and explains us_list and brand semantics. However, it never explicitly states when to use this tool instead of alternatives like china_ai_us_lists, so usage is implied rather than fully directed.

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 read-only, idempotent, non-destructive and open-world behavior, yet the description still adds substantive context: what each entry returns (list name, start date, evidence type and text, matching CAC record IDs), how the two US regimes differ (export-licence vs investment ban), and explicit caveats that it does not resolve corporate identity and that absence from a list is not a clearance.

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 and query mode are front-loaded in the first two sentences, and the rest is layered supporting context. It is longer than typical and the DHS DeepSeek order and MORVS disclaimers sit slightly off the core task, but each sentence carries information an agent would otherwise have to guess.

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 return-value burden well by enumerating the fields per entry, and it preempts the two most likely misinterpretations (regime conflation and 'not listed = cleared'). It does not mention result-count limits, pagination, or what happens when q is omitted, which for an optional-parameter tool is a real gap.

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

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

Schema coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description goes beyond the enum by explaining the evidentiary meaning of tiers A and B and the consequence of tier B falling outside headline counts, which the schema does not 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?

The opening sentence gives a specific verb and resource: a curated crosswalk from CAC filer legal names to the US Entity List and Treasury NS-CMIC list. This is clearly distinguishable from siblings such as sanctions_check, watchlist, and china_ai_filings, which an agent could otherwise confuse it with.

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

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

It states the query mode (Chinese or English entity-name substring) and that tier defaults to A, and it explains what each tier means and which one belongs in headline counts. It stops short of explicitly naming an alternative sibling tool or stating when-not-to-use, though the pointer to 'the separate US actions timeline' gestures at routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the data source (ClinicalTrials.gov) but omits freshness/latency, ordering, and result-set behavior, so it contributes only modest extra context.

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

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

Three short sentences, front-loaded with the source and scope, then filters, then the use case. No filler or repetition of 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?

For a read-only search tool with no output schema and fully documented parameters, this is close to sufficient. The main gap is that 'recent' is never defined in the description (the window is only implied by the limit parameter's latest-update-date wording).

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

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

Schema description coverage is 100% and documents limit, phase enum, status values, and sponsor substring matching. The description merely restates that phase/status/sponsor are filters, adding no syntax or default information beyond the schema, 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 resource and source: 'Recent clinical trial activity from ClinicalTrials.gov,' plus the filterable dimensions (phase, status, sponsor). No sibling tool covers clinical trials, so no differentiation is needed, but it stops short of describing what a returned record contains or how 'recent' is bounded.

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

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

'Use for drug pipeline questions' gives one implied use case but no when-not guidance and no named alternative tools. For a specialized data source with no close siblings this is minimally adequate, leaving the agent to infer query-construction intent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds an interpretive framing (conviction signal) plus the cluster criteria, but says nothing about result ordering, caps, or return shape.

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

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

Two tight sentences with the screening criteria front-loaded and no repetition of the title or schema. The second sentence is interpretive rather than informational, which slightly dilutes it but still earns its place as the rationale.

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 three-parameter screener with full schema coverage and a complete annotation set, the description is nearly sufficient. With no output schema, a brief note on what is returned (issuer list with insider/value counts) would close the remaining gap.

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

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

Schema coverage is 100% and every parameter carries its own default, max, and minimum constraints, so the schema does the heavy lifting. The description adds no syntax or semantics beyond what is already structured, making the baseline 3 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 signal and its criteria: companies with multiple distinct insiders buying open-market stock within a window. An agent can tell what the tool screens for. However, it never names its obvious counterpart cluster_sells, so the differentiation from the sibling is left to the name alone.

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

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

"Strong conviction signal" implies when the tool is useful (bullish insider-conviction screening), which is real but indirect guidance. There is no explicit when-not or named alternative such as cluster_sells or company_insider_pulse.

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 read-only, idempotent, non-destructive query, so the safety profile is covered. The description usefully narrows scope to open-market sells by distinct insiders, but says nothing about result ordering, thresholds applied server-side, or empty-result behavior.

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

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

Two compact sentences with the qualifying condition front-loaded and a short reinforcing tag. No filler, though the 'Mass-exit detector' fragment is marketing flavor rather than functional information.

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

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

With no output schema, the description does not say what a returned record contains (issuer, insider count, aggregate value) or how results are ranked, which an agent needs to interpret results. For a zero-required-parameter query tool it is minimally adequate but not complete.

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

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

Schema description coverage is 100%, so days, min_usd and min_insiders are already fully documented with defaults and bounds. The description only echoes the 'multiple distinct insiders' and 'window' concepts, adding no format or interaction 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 concrete resource (companies) and the precise qualifying condition: multiple distinct insiders selling open-market stock within a window. 'Mass-exit detector' reinforces the intent. It never names its obvious counterpart cluster_buys, so sibling differentiation is left to the agent.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as cluster_buys or company_insider_pulse, despite a near-identical sibling existing. The 'mass-exit detector' label hints at a use case but offers no routing logic.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the fact that it covers 'every Medicare facility' the owner controls, the sector scope, and the PE/REIT flagging, which tells the agent what kind of intelligence it will get back.

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 the purpose and the returned signal set, the second carries the input prerequisite. No filler, no restatement of the title, and the parenthetical endpoint reference is the only detail an agent actually needs to source the id.

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, yet the description compensates by naming the concrete return fields (facility_count, per-sector breakdown, PE/REIT flags, state spread). With one required parameter fully documented and the annotations covering safety, nothing needed to invoke 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 description coverage is 100% for the single parameter, and the schema already says 'Numeric CMS owner associate id', so baseline is 3. The description goes further by identifying the provenance of that id (the largest-owners and private-equity endpoints) and constraining it to a single organization owner, which reduces the risk of passing a person-level or facility-level id.

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 ('Trace one organization owner across every Medicare facility it controls') and enumerates the sectors covered (hospital/hospice/home-health/skilled-nursing). An agent can immediately distinguish this owner-centric rollup from facility-search siblings such as epa_facilities or building_permits_search.

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 supplies the operative precondition — the tool 'takes a CMS owner_associate_id' — and names the endpoints that produce that id (/api/v1/owners/largest, /owners/private-equity), routing the agent to the right upstream data. It does not state when NOT to use this tool or name a competing sibling, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds domain substance by clarifying that Form 4 entries are executed trades while Form 144 entries are proposed sales, which is useful behavioral context not in the annotations. It says nothing about return ordering, volume of results, or pagination.

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

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

A single sentence with the scope ('one company') front-loaded and the two constituent data sources stated compactly. No filler and nothing deferred to later sentences.

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

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

For a read-only, 100%-documented, two-parameter lookup with annotations carrying the safety profile, the essentials for invoking correctly are present. However, in a sibling set dense with insider/ownership tools, the description leaves the agent unable to disambiguate scope, and with no output schema it offers no hint of the timeline's shape.

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%: the window semantics (calendar days, default 90, max 365) and the ticker/CIK format with padding example are fully documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description names the specific resource (insider filings) and distinguishes the two data sources it unifies: executed Form 4 transactions and proposed-sale Form 144 filings, scoped to 'one company'. That is concrete enough to know what comes back without opening a schema, though it does not name or rule out any sibling.

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

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

There is no when-to-use guidance, no exclusions, and no routing to alternatives despite several adjacent siblings (cluster_buys, cluster_sells, upcoming_sales_pressure, entity_timeline, dossier). An agent cannot tell from this text why it would pick this over those.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond the annotations by disclosing the concrete contents and time windows of the response (7/30/90d insider activity, upcoming Form 144 sales, FY+quarterly financials), which is exactly what matters for an agent when no output schema exists.

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

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

A single front-loaded sentence that names the resource first and then itemizes contents; there is no filler. It runs long as an enumerated list, but each item earns its place by describing returned data.

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 one-parameter, read-only tool with no output schema, the description compensates well by enumerating return contents, and the annotations carry the safety profile. The remaining gap is disambiguation from the near-identical sibling 'dossier'.

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, so the schema fully documents that the argument accepts either a ticker or a 10-digit CIK. The description adds no syntax or format detail beyond that, 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 resource and scope ('Comprehensive dossier for one SEC-filing company') and enumerates the exact content domains (filings, insider windows, Form 144, financials, 13F holders, peers). It differentiates from non-SEC siblings, but never distinguishes itself from the overlapping sibling 'dossier', leaving a real ambiguity an agent must resolve.

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 never says when to pick this tool over the many adjacent siblings (dossier, fund_holdings, company_insider_pulse, entity_timeline) nor states any prerequisites or exclusions. Usage can only be inferred from the content list, which is guidance by implication at best.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the coverage scope of the scan (which source categories are checked), which is useful, but it says nothing about latency, data freshness, empty-result behavior, or what a flag object contains.

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

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

A single front-loaded sentence with no filler; the parenthetical examples are informative rather than padding. The parenthetical list is fairly dense, but each item adds distinguishing coverage information.

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

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

With no output schema, the description should ideally indicate what is returned (flag structure, severity, per-source fields) or how results are ordered/filtered. It tells the agent what is scanned but not what comes back, leaving a real gap for a detector-style tool.

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

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

Schema description coverage is 100% and the single parameter (ticker_or_cik) is fully documented with format examples in the schema itself. The description adds no syntax, format, or lookup guidance beyond what the schema already provides, so the baseline of 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+resource ('red-flag detector for one company') and then enumerates the exact signal classes covered (8-K 4.02 restatements, auditor changes, officer departures, insider cluster sells, Form 144 pressure, 13D filings, FDA recalls). This 'multi-source aggregate for one company' framing clearly separates it from single-signal siblings like cluster_sells, company_insider_pulse, or upcoming_sales_pressure.

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 scope ('for one company') implies a due-diligence/screening use case, but there is no explicit when-to-use guidance and no mention of when to prefer alternatives such as dossier, screen_all, watchlist, or entity_material_events. Usage is inferable but not 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 (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context: it runs the 'full 40-source screen for each' entity and returns both scores, a verdict, a risk gap, and per-vertical differences. It doesn't discuss latency/cost of a doubled screen, but 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?

Three tight sentences, front-loaded with the definition and followed by mechanics and use case. Minor redundancy between sentence one and the 'which counterparty is riskier' closer, but nothing wasteful.

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

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

With no output schema, the description usefully enumerates the return payload (both scores, verdict, gap, per-vertical deltas), which is exactly what an agent needs. Params are fully schema-covered and annotations carry safety. Only the ambiguous entity-matching behavior is left unaddressed.

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

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

Schema coverage is 100% with both params documented ('First/Second entity name, >=3 chars'). The description only adds that the inputs are 'two entities'; it contributes no extra meaning about names, matching, or resolution behavior, 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+resource: 'Side-by-side compliance-risk comparison of two entities.' The comparison framing inherently differentiates it from single-entity siblings like screen_all or sanctions_check, but it never names an alternative explicitly. An agent can still tell what it does without opening the schema.

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

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

Usage is implied by 'Answers which counterparty is riskier in one call,' suggesting you reach for it when comparing two entities rather than screening one. There is no explicit when-not guidance and no named alternative (e.g., screen_all for a single entity), so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the shape of the payload (counts, top NOS, recent cases), which matters since no output schema exists, but it omits how "recent" is bounded, whether the lookup is fuzzy, and pagination limits.

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

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

Two tight sentences: the returned fields are front-loaded, and the payoff questions are given last. No filler, no restatement of the tool name.

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

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

For a one-parameter read tool with no output schema, the description does the important work of telling the agent what comes back and why it would be called. The remaining gap is that "recent" is undefined and there is no routing to the sibling courts_recent.

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

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

Schema coverage is 100% and the single name parameter is fully documented in the schema, including the substring-match behavior. The description adds only that the scope is "one company," which restates what the schema already conveys; 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?

The description names a specific resource (a company's litigation docket) and enumerates what it returns: docket count, top Natures of Suit, recent cases. It never names or contrasts with the obvious sibling courts_recent, so an agent must infer the entity-vs-recency split from the tool name alone.

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

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

The framing questions ("is this company being sued?", "for what?") imply the use case clearly, which is better than nothing. However, there is no explicit when-not guidance and no pointer to courts_recent or dossier for the temporal or aggregate alternatives.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low. The description usefully adds the data provenance (CourtListener) and confirms results are sorted/limited by recency, but says nothing about pagination, result shape, or what 'recent' concretely means.

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

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

Two tight sentences with the resource and source front-loaded, no filler. The 'filter by party, court, or Nature of Suit' clause partly restates schema fields, which keeps it from a perfect score, but the NOS glossary earns its 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 low-complexity read-only search with full schema descriptions, complete annotations, and no output schema, the description covers source, scope, and the non-obvious parameter vocabulary. The main untouched gap is the undefined recency window and the overlap with courts_by_party.

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%, giving a baseline of 3, but the description goes beyond the schema by decoding the opaque Nature-of-Suit codes (850=securities, 830=patent, 410=antitrust, etc.), which the schema only lists as numbers. That mapping genuinely helps an agent choose the right filter value.

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 (recent federal court dockets) plus the upstream source (CourtListener), so the agent knows exactly what it retrieves. It does not, however, differentiate itself from the close sibling courts_by_party, which overlaps on the party filter.

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 statement, no exclusions, and no routing to alternatives such as courts_by_party or courts_recent's nondocket siblings. The filter list reads as a feature enumeration rather than invocation 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 safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real value beyond them: the data source is an aggregate federal program statistic, it is explicitly PII-free, and the coverage window is 1989-2026. It stops short of noting rate limits, result truncation behavior, or that name matching may be fuzzy.

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 zero filler: the what, the return shape, the follow-on purpose, and the data provenance. Everything an agent needs is front-loaded in the first clause.

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 correctly carries the return-value burden by specifying the place_id format and what it unlocks. Data vintage and PII status round it out. Minor gap: it doesn't say what a result record otherwise contains or how matches are ranked, but that is not blocking.

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

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

Schema description coverage is 100% (q is documented as county/state name with a >=2 char minimum, limit as 1-100 with default 25), so the baseline is 3. The description reinforces the name-matching intent but adds no syntax, matching, or pagination nuance 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 (Search) and a precise resource (USDA RMA crop-insurance Summary of Business) scoped to county/state name. It also names the return artifact (place_id in {state_fips}-{county_fips} form), so an agent can distinguish it from the neighbor ag_census_county_search even 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?

It implies the follow-on use (resolve a place_id to pull county underwriting history, 1989-2026), which is meaningful chaining context. However, it never states when to prefer this over the similarly named ag_census_county_search or other county-level searches, and gives no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the multi-vertical qualifying criterion and the lookback-window scoping, but says nothing about result ordering, pagination, or the server-side cap noted in the schema.

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

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

Two sentences with no filler, and the core behavior (what the feed lists and under what condition) is front-loaded before the usage hint.

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 could have said more about the shape of the returned entity list (fields, ordering). Still, for a zero-required-parameter discovery feed whose annotations already cover safety, it gives enough to call the tool correctly.

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

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

Schema description coverage is 100%, so all three parameters (days, limit, min_verticals) are fully documented in the schema, including defaults, maximums, and the server cap on limit. The description only echoes the lookback window and the 2+ vertical threshold, adding 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?

The description states a specific verb and resource (list of entities with activity in 2+ regulatory verticals) and names the exact scope (SEC + FDA + contracts, inside the lookback window). It also distinguishes itself from the full-timeline sibling by framing itself as a discovery feed.

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

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

It gives a clear when-to-use: 'Use to find entities worth pulling a full cross-vertical timeline for,' which implicitly routes to the entity_timeline sibling. It stops short of naming that sibling explicitly or stating when not to use this feed (e.g., single-vertical lookups).

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: corpus size (~139 investigations), the nature of the records (independent root-cause investigations), and the relationship to the broader EPA RMP accident dataset. It does not discuss return shape or result ordering, but that is a minor omission against the annotation coverage.

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

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

Two sentences, front-loaded with the verb and resource, with the supporting context (corpus size, examples, dataset layer) packed into the second. No filler or restated boilerplate.

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

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

For a simple two-parameter search with no output schema, the description gives enough to call it correctly: what corpus is searched, what the query accepts, and what scale of result to expect. A brief note on what a result record contains would fully close the gap, but nothing essential 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%, and the description's 'by company, location, or keyword' largely restates the schema's 'Company / location / keyword' for q. The named example entities (BP Texas City, West Fertilizer, DuPont) give marginal help in shaping queries, but the description adds little parameter meaning beyond the schema, so the baseline of 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 (Search), a specific resource (U.S. Chemical Safety Board investigations), and the domain (major chemical incidents — explosions, toxic releases, fires) with concrete example cases. It even positions itself in the corpus hierarchy ('the deep-investigation layer over EPA RMP chemical accidents'), which implicitly distinguishes it from the sibling chemical_accident_search.

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: an agent can infer this tool is for CSB root-cause case investigations rather than general chemical accident data. However, it never explicitly says when to prefer this over chemical_accident_search or chemical_accident_worst, nor does it state exclusions. The 'deep-investigation layer over EPA RMP' phrase hints at the boundary without naming the alternative.

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 readOnly/idempotent/non-destructive and closed-world, yet the description adds substantial context: the two source registries and their year ranges, domain-based identity so name changes unify, matching normalization rules, no merging of multiple candidates, and the contents of each match. It also states the critical caveat that registration is self-reported and California-only, so a non-match is not a negative finding — behavior an agent cannot 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 and sources are front-loaded, and nearly every clause carries operative information. It is, however, a long, heavily comma-joined paragraph; the enumeration of returned fields could be tightened without losing meaning.

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 takes on the burden of describing returns and does so (filings, collection categories, sale/share recipients, governing laws, consumer-request counts, name history, broker page). Any parameter is optional, both are documented, and the non-match interpretation caveat is present — nothing material is missing for correct invocation or interpretation.

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

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

Schema coverage is 100%, so baseline would be 3, but the description goes well beyond field definitions: it explains that matching is by registrable domain or by normalised legal name/DBA/prior name, that case, punctuation and legal suffixes are ignored, and that matching is exact after normalization. That tells an agent how to shape inputs and what recall to expect, which the schema does not.

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 (checks whether a business is registered as a data broker) plus the exact source (MORVS California Data Broker Register) and the coverage window. An agent can distinguish it from the sibling data_broker_diff, which presumably compares registries rather than checking a single business.

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 input options ('Give a business name, a website domain or URL, or both') and an explicit exclusion ('Businesses only; queries shaped like a personal name are not run'). It stops short of naming the sibling data_broker_diff as the alternative for comparison work, so routing between the two is only implied by scope.

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/idempotent/closed-world safety profile, and the description goes well beyond them: it explains the classing logic (apparent leaver, re-registered at same domain, net new) and, crucially, warns that an absent registration is NOT an exit, merger, or finding because registration is self-reported and California-only. That is exactly the kind of interpretive caveat an agent needs.

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 verb and resource, and the method and caveats are packed efficiently. It is a dense single paragraph and slightly long, but nearly every clause (method, classing, caveat) carries information an agent uses.

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

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

No output schema exists, and the description compensates by specifying what is returned (counts and named registrations per group, plus the register's own published figures for consecutive files). Combined with the interpretation caveats, nothing an agent needs to call 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 coverage is 100%, so both year_a and year_b are already documented in the schema. The description reinforces the accepted formats ('named by its year, or the Attorney General's 2020-2023 list') but adds no syntax or ordering detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Compares two files of the MORVS California Data Broker Register') and pins down the exact domain (CPPA yearly registry or AG 2020-2023 list). An agent can separate this from the sibling data_broker_check without opening the schema.

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

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

The description implies usage by laying out the register's published comparison method and what the result means, but it never states when to reach for this tool over data_broker_check or other broker-related siblings, nor any exclusions. Usage is inferable from the resource described rather than being routed explicitly.

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, idempotent, closed-world safety profile, and the description goes well beyond them: publisher figures are non-comparable across companies, missing figures mean not reported rather than zero, national-security values stay banded, and aggregates cannot prove individual data requests. These are exactly the interpretive caveats an agent needs to avoid drawing false conclusions.

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?

Each sentence carries real information — the caveats about aggregation, missing values, and bands all matter for correct interpretation. The sector note is slightly redundant with the schema, and the caveats could be ordered more tightly, but there is 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 does the necessary work of explaining that the result is per-publisher headline rows with labels and how to read them. Combined with the safety annotations, an agent knows enough to call it correctly; only the sibling comparison 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 the single enum parameter is fully documented in the schema, including the no-add/no-rank note. The description's 'optionally restrict to one sector' adds nothing beyond the schema, 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?

The description names a specific verb and resource: it shows the latest headline row per publisher from the MORVS Government Data Demand Register, paired with each figure's label. That is far more specific than the title alone. It does not name or differentiate itself from its closest sibling, data_demand_source, which keeps it short of a 5.

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

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

It states the optional sector filter and, importantly, tells the agent how to interpret the output (never add or rank across companies, missing means not reported). But it gives no explicit when-to-use guidance and never points to data_demand_source or data_broker_check as the alternative when a different view is wanted, so routing must be inferred.

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, idempotent, non-destructive, closed-world), and the description still adds substantial non-obvious behavior: figures are per-publisher counts with inconsistent methodology, cross-company aggregation/ranking is invalid, missing means not reported rather than zero, national-security values stay banded, and the counts cannot reveal individual data requests. This is exactly the kind of interpretive constraint an agent cannot get 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 it returns, then the caveats, then defaults — a sound ordering for a caveat-heavy tool. Some phrasing is duplicated in the parameter schema (national-security bands, 'not reported, not zero'), which costs a little density but reinforces the highest-risk misinterpretations.

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

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

For a 7-parameter read tool with full schema coverage and annotations, the description supplies the interpretive guardrails that matter most. It does not describe the shape of returned facts (no output schema exists), so an agent knows the rules but not the payload structure — a modest remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining that filters select exact fact fields and that period falls back to the latest complete report. The units/methodology caveat also contextualizes what 'measure' and 'series' identifiers imply.

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 one publisher's figures for one report in the MORVS Government Data Demand Register.' The 'one publisher' scoping implicitly separates it from data_demand_compare, but no sibling is named outright. Purpose is clear without opening the schema.

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

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

It states the default behavior ('Defaults to the latest complete report') and that optional filters narrow to exact fact fields, which is useful context for invocation. However, it never says when to pick this over data_demand_compare or data_broker_check — the alternative routing is left to inference from the 'one publisher' phrasing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description then adds genuinely useful behavior beyond that: each row carries separate last-successful-observation and indexed-content watermarks, and each row states which timestamp drives the status. It stops short of describing pagination or result volume, so 4 not 5.

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

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

Two dense sentences, front-loaded with what the tool returns, with the optional filter mentioned last. Terminology is jargon-heavy (watermarks, cadence) but compact and waste-free rather than 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?

There is no output schema, so the description carries the full burden of describing return values, and it does so reasonably: per-dataset rows, status class, age in days, dual watermarks, and the driving timestamp. For a read-only single-parameter diagnostic tool this is nearly sufficient; only ordering or volume expectations are 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 100% and the single parameter's enum values are already documented in the schema, so the baseline is 3. The description only restates the filter as optional and re-lists the same four values, adding no new semantics about filtering behavior or defaults.

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

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

States a specific resource and verb-equivalent scope: per-dataset freshness across the federal data hub, with the status vocabulary and the two watermark types named. An agent immediately knows this is the source-cadence freshness report. It does not name or differentiate itself from any sibling, but the sibling list contains no close competitor, so 4 rather than 5.

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

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

There is no when-to-use statement, no prerequisite, and no alternative named. The only guidance is that the status filter is optional, which is a parameter detail rather than usage direction. Nothing tells the agent when this tool is the right choice versus the many search/dossier siblings.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive) and closed-world scope. The description adds genuinely useful context: the exact indexed sources and their sizes, plus the return semantics ("hit=true if any match") that no output schema discloses.

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 packed sentences with zero filler: sources first, return value second, use case last. The core purpose is front-loaded and every sentence 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 partially covers returns ("hit=true if any match"), which is the key output for a screening tool. It leaves minor ambiguity about whether matching entity details are returned, but otherwise gives enough to call the tool correctly.

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

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

Only one parameter with 100% schema description coverage, so the schema already carries the load (baseline 3). The description clarifies that the name is screened by substring but adds no format or normalization guidance 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?

Uses a precise verb ("Screen a name against") and names the exact resources: SAM Exclusions (~10k) and HHS OIG LEIE (~83k). This specificity inherently distinguishes it from overlapping siblings like sanctions_check and the screen_* family, which cover different data sources.

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

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

Provides clear usage context ("Use this for KYC + counterparty due diligence"), telling the agent the scenario it targets. It stops short of naming alternatives or exclusions, so the agent must infer on its own whether sanctions_check or screen_all is the better fit.

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 a safe, idempotent read, so the bar is lower; the description adds real value with dataset scale (~394,495 vessels), category coverage, and an explicit 'zero PII' constraint (no owner names or addresses). With no output schema, listing the returned fields also carries behavioral weight, though pagination behavior is left to the schema.

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, front-loaded with the action and lookup keys, then dataset scope, then return fields and the PII caveat. No filler sentences.

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

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

For a two-parameter dataset search with no output schema, the description supplies the domain, scale, returned fields, and an important PII limitation. Nothing an agent needs to call 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%, so the schema already documents both q and limit; the description's 'by name or official number' merely paraphrases q and adds nothing for limit. Baseline 3 applies 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 (Search) and resource (USCG documented vessels) plus the two lookup keys (name or official number), which is a precise, distinguishable purpose among the many dataset-search siblings. An agent can tell this retrieves US vessel documentation data without opening the schema.

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

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

The description implies usage through the lookup keys and dataset scope, but never states when to prefer this tool or which sibling to use instead. There are no exclusions or prerequisite conditions, leaving routing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and a closed-world corpus. The description adds real behavioral value on top: matching is a body-text substring scan over 266k+ press releases since 2009, which tells the agent to expect loose/false-positive matches rather than entity-resolved results. It stops short of describing result caps or ordering.

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 zero filler: purpose first, then coverage, then match mechanics and corpus bounds. Every sentence carries distinct information.

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

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

For a single-parameter search tool with no output schema and strong annotations, the description covers purpose, matching semantics, and corpus scope adequately. Minor gaps remain around result volume, ordering, and whether press releases are the only source type, but nothing essential to invocation is missing.

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

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

Schema coverage is 100% for the single parameter, so the baseline is 3. The description earns an extra point by clarifying that matching happens on body text via substring, not on a canonicalized company identifier — a distinction the terse schema description ('Company name (substring)') does not 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 verb and resource ('DOJ press release search for one company') and enumerates the enforcement categories covered (FCPA, antitrust, healthcare fraud, environmental crimes). This cleanly separates it from doj_recent (recency-based) and cfpb_by_company (different agency), 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?

The one-company framing gives clear context for when to reach for this tool versus a general search. However, it never explicitly names alternatives (e.g., doj_recent or courts_by_party) or states when this tool is the wrong choice, so routing still requires inference from the sibling list.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds source context (Office of Public Affairs) but leaves the meaning of 'recent' undefined and says nothing about sort order or result size 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 compact sentences with the resource and recency front-loaded before the filter options. The trailing list of component names is slightly padded with 'etc.' but still earns its place as routing signal.

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

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

For a simple read-only search with three fully documented optional parameters, the description is adequate but has a notable gap: 'recent' is never bounded by a time window or default lookback, which an agent needs in order to judge relevance. No output schema exists to absorb that ambiguity.

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 schema already documents q, limit and component including examples and the default/max bound. The description's component examples ('Antitrust Division', 'USAO - SDNY', 'ENRD') only mildly extend the schema's single example, so baseline 3 applies.

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

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

The description names a specific resource (DOJ Office of Public Affairs press releases) and scopes it to recent items, so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from the close sibling doj_by_company, which is the only thing keeping it from 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 implies usage by stating the two filter modes (free-text query or DOJ component), which tells the agent when filtering is appropriate. However, it gives no explicit when/when-not guidance and never names alternatives such as doj_by_company or courts_recent, so routing must be inferred.

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 readOnly, idempotent, non-destructive, so safety is covered. The description does add genuine behavioral value by clarifying role matching ('FDA recalls as firm', 'contracts as recipient'), but says nothing about result volume, truncation, or how ambiguous name substrings are handled.

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 with the cross-topic scope and source list front-loaded and no filler. It is efficient, though the noun-phrase fragment omits an explicit verb, leaning on the title for the action.

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 source enumeration is a reasonable stand-in for what comes back, but the description omits return shape and, critically, default behavior for a tool with zero required parameters. For an aggregating dossier across six datasets, that leaves a real gap.

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

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

Schema description coverage is 100% with only two optional parameters, so the schema already explains the substring semantics and the ticker-to-legal-name resolution. The description adds no parameter detail beyond that, making the baseline 3 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?

States a specific resource ('cross-topic dossier for one entity') and enumerates exactly which datasets are aggregated (SEC filings, 13F, fund holdings, FDA recalls, federal register, contracts). This distinguishes it from narrow siblings like fda_firm_dossier or patents_by_assignee, though it never explicitly names a sibling it competes with.

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

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

No when-to-use guidance and no routing to alternatives such as company_profile, entity_timeline, or compare_entities, all of which overlap. With zero required parameters, the description also never explains what happens if both name and ticker are omitted or which to prefer.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that: matching semantics, the shape of what comes back, and the critical caveat that absence from the register is not a compliance determination.

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 matching behavior are front-loaded and every clause carries information (list composition, match rules, return contents, caveat). The single long sentence is dense 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, the description carries the burden of describing returns (designations, naming government record, attached reference records, federal contract totals) and does so. For a read-only, two-parameter lookup this is complete enough to invoke correctly.

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

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

Schema coverage is 100%, with both parameters fully documented (matching rules for 'name', default/max for 'limit'). The description restates the matching rules but adds no format or edge-case detail beyond the schema, 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 ('Checks whether a company or agency is named in the MORVS Drone Register') and enumerates the constituent lists, which gives the tool a distinct scope. It never names a sibling (e.g. sanctions_check, drone_product_lookup, watchlist), so differentiation is implicit rather than explicit.

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 register's composition, and the closing caveat that a non-match 'is not clearance or a compliance determination' is a useful interpretation rule. But there is no explicit when-to-use/when-not guidance or routing to an alternative tool for related screening needs.

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 (read-only, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds real value by disclosing the return fields and the FCC Covered List exemption context, and by warning that an FAA declaration is the manufacturer's own statement rather than an approval. That interpretive caveat is behaviorally useful and not derivable 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?

Three sentences, front-loaded with the core action and scope, then returns, then the interpretation caveat. Efficient overall, though the enumerated list names are slightly heavy relative to the rest.

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 (company, list, action, date, source record) and the exemption context. Combined with 100% parameter coverage, an agent has enough to invoke and interpret results correctly, though it never mentions pagination or result limits beyond the 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 100%, so the schema already documents q, list and limit including the enum values and 2-character minimum. The description only echoes the query axis (model/product/category text) without adding syntax or format detail beyond the schema, matching the baseline for full coverage.

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

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

States a specific verb (finds) and resource (drone platforms, components and software) scoped to four named registers, with the query axis (model/product/category text) made explicit. An agent can distinguish it from drone_company_check and fcc_grantee_search without opening the schema.

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

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

The text implies the usage context (product/model text search across the drone register) but never states when to prefer this over sibling tools like drone_company_check or fcc_grantee_search, nor any exclusion conditions. Usage is inferable rather than guided.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully names the returned sections (indications, dosage, warnings, adverse reactions, interactions), but adds no auth, rate-limit, or matching-behavior detail beyond annotations.

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

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

Two sentences, front-loaded with the lookup action and searchable identifiers. Every clause earns its place; 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 single-parameter read tool with no output schema, the description compensates by enumerating the returned label sections, giving the agent enough to know what it will get. Nothing essential 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% and already documents the single 'name' parameter as brand or generic (substring, case-insensitive). The description adds 'substance' as an accepted input beyond the schema, a minor extension; baseline 3 applies 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 (look up) and resource (FDA drug label) plus the accepted identifier types. No sibling covers drug labels directly (fda_firm_dossier is firm-level), so the purpose is unambiguous even without explicit sibling differentiation.

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

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

Usage is implied by the searchable name types (brand, generic, substance), but there is no explicit when-to-use/when-not guidance or named alternative. Adequate but leaves routing to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive and open-world behavior. The description adds substantial non-obvious constraints beyond that: figures are never summed across blocks, CMS and White House estimates are quoted rather than recomputed, labels are given in each record's own words, and personal names are withheld as counts. These are valuable behavioral disclosures, though buried in excessive prose.

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

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

The description is extremely long and runs multiple dense semicolon-chained sentences. Caveats about captions, as-of dates, licence, institutional-only rules and label withholding are piled in, making the core purpose harder to scan. Only the first sentence is effectively 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 burden of explaining returns, and it does enumerate the fact sheets, annexes, notices, CMS models and caveats in detail. It is complete enough for an agent to understand what comes back, even though the delivery is excessively verbose.

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 schema already documents the single optional company parameter as a case-insensitive substring with an example and an 80-character limit. The description restates that it is a substring of a company as printed but adds no new syntax or format detail, so baseline 3 applies.

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

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

The first sentence states a specific verb and resource: listing the 2025-26 drug-pricing agreements in the Medicare Drug Money Register, with an optional company filter. It does not differentiate this tool from siblings such as drug_money_company or drug_money_summary, 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?

Usage is only implied through the optional company filter and the enumerated returned sections. There is no explicit when-to-use guidance, no exclusions, and no naming of alternatives like drug_money_company or drug_money_summary to help the agent choose correctly.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. Beyond that, the description extensively discloses data limitations (gross vs net, annual vs preliminary never combined, side columns never added, empty column is a search result, withheld names, FEC restrictions), far exceeding 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?

The description is extremely long and dense, with repeated caveats ('never added', 'never put in one series', 'separate records') that could be compressed. The key purpose is buried under many clauses, making it hard to scan despite containing useful 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?

Given no output schema and a complex, multi-source dataset, the description thoroughly covers what is returned (parents, labelers, side columns, preliminary vs annual years), what is excluded, and the register's question note and captions. It leaves little ambiguity about the tool's scope.

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

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

Schema coverage is 100% for the single 'name' parameter, so the schema already defines it as a case-insensitive substring of a parent company or labeler. The description adds that the name may also be a White House or proclamation-annex name, which is extra semantic meaning 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 states a specific verb ('Look up') and resource ('a drug company in the Medicare Drug Money Register') and specifies the matching basis. It does not explicitly name sibling tools or distinguish itself from drug_money_drug, drug_money_agreements, or drug_money_summary, so it falls short of a 5.

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

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

It gives constraints such as 'Institutions only' and 'no prescriber... is named', but never says when to use this tool instead of a sibling like drug_money_drug or drug_money_agreements. There is no explicit 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 annotations, the description discloses important behavior: it returns up to 10 brands, labels preliminary periods separately, never combines annual and quarterly periods, avoids treating gross cost as net savings, withholds labeler strings that read as person names, and says a withheld-only match answers like no match. These are substantive behavioral and data-limitation disclosures that an agent would not get from the annotations or schema alone.

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, but the description is a very long, dense paragraph with heavy repetition of CMS sourcing, naming conventions, and caveats. For a two-parameter lookup tool, much of the text is over-specified and hard to scan.

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

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

Given the high domain complexity and the absence of an output schema, the description is contextually complete: it describes returned fields, gross-versus-net caveats, preliminary-period labeling, negotiated-price reporting, withholding rules, and answer metadata such as the question note and as-of date. An agent has enough information to understand what a correct answer should and should not contain.

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

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

The schema already documents both parameters with 100% description coverage, including the name substring and period pattern. The description elaborates on the same semantics, such as annual versus preliminary periods, but adds little parameter-level meaning beyond the schema itself.

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

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

The description opens with a specific verb and resource: "Look up Part D drugs in the Medicare Drug Money Register by a substring of a brand or generic name... optionally limited to one period." This makes the tool's core purpose clear, but it does not explicitly differentiate itself from nearby siblings such as drug_money_company, drug_money_agreements, drug_money_summary, or drug_label.

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

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

The description implies when the tool is appropriate by specifying lookup by name substring and optional period, but it never states when to choose this tool over sibling tools. There are no explicit exclusions or alternative-tool routing instructions.

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 readOnly/idempotent/openWorld, and the description goes well beyond them: gross is never net, preliminary and annual years are never merged into one series, blocks are never added together, side-columns are never summed with drug cost, and specific items are excluded or withheld. It also discloses governance behaviour (question note, as-of dates, licence, FEC 30111(a)(4) restriction) and the institution-only rule for labeler strings, which an agent could not learn 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?

It is one enormous run-on block of semicolon-chained clauses; the useful front-load ('Totals from the Medicare Drug Money Register') is followed by dozens of nested caveats with no headings or paragraph breaks. Much of the content is substantive, but the packing makes it hard to scan and the core instruction is buried.

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

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

With no output schema and no parameters, the description must carry the entire return-value burden, and it does so exhaustively, including exclusions, withholding, and labelling conventions. What it omits is the routing dimension (which sibling answers a narrower question) and any hint about response size or pagination, which matter for a tool aggregating this many blocks.

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 the schema carries no semantics to supplement and the baseline of 4 applies. The description instead specifies what the zero-argument call returns, which is the only meaningful 'parameter' context here.

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

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

The opening sentence states a specific resource (the Medicare Drug Money Register) and a specific output shape (totals/aggregates), then enumerates the blocks returned, so an agent can tell this is the aggregate view rather than a per-entity lookup. It never names its obvious siblings (drug_money_company, drug_money_drug, drug_money_agreements), so the differentiation is inferred from the word 'Totals' rather than stated.

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 never says when to call this instead of drug_money_company, drug_money_drug, drug_money_agreements, or media_money_summary. An agent must guess from the tool name alone that this is the overview/rollup endpoint, and there are no prerequisites, exclusions, or routing conditions 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?

Well beyond the annotations (readOnly/idempotent/openWorld/non-destructive), it discloses data provenance (EAC 2024 survey, November 2024), that answers are self-reported and coded, that vendor counts overlap and must not be summed, and precise linguistic constraints on what the agent may claim. This is exactly the interpretive context annotations cannot 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 lookup operation, then layered caveats. Every sentence carries substantive interpretation guidance, though the block of caveats is dense and could be tightened marginally.

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 adequately conveys what comes back (coded equipment answers with make/model and MORVS-curated vendor labels) and how to interpret gaps. Minor omissions like pagination/limit behavior and the sibling-tool boundary keep it from a 5.

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 restates state code and jurisdiction name substring (adding only the 'literal' qualifier) and says nothing about the limit parameter beyond what the schema documents.

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?

Uses a specific verb ('Find') and resource ('jurisdiction') and states the lookup key (two-letter state code plus literal jurisdiction name substring) and the returned payload (coded equipment answers from the 2024 EAVS with make/model and vendor labels). It doesn't explicitly distinguish itself from the sibling election_voting_systems tool, so it falls short of full sibling differentiation.

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

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

Gives clear usage constraints: missing/Other answers don't mean no equipment, the survey doesn't establish equipment on a specific date, and directs the agent to Verified Voting and the state election office for verification. It stops short of routing between this tool and the election_voting_systems 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?

The annotations already declare read-only, idempotent, non-destructive, open-world behavior, and the description adds substantial domain context: default list behavior, how proposed EOL notices interact with certified status, legal caveats about federal versus state authority, and wording restrictions for decertified systems. No contradiction with annotations is present.

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 and the description is appropriately sized for a tool with several domain-specific cautions. It is dense but mostly earns its space, though some legal and notice wording overlaps with schema or annotation context.

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 still explains what is returned: EAC names, standards, dates, and source links. Combined with the default behavior, optional filters, and domain caveats, it gives an agent enough information to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the list enum and eol_notice behavior. The description reinforces the default list and domain meaning of vendor/eol_notice, but adds little parameter-level detail beyond what the schema already provides.

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

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

The description uses a specific verb, 'Filter', and a precise resource, the EAC's certified/under-test/withdrawn-or-decertified/terminated/e-poll-book systems, and it enumerates return fields. However, it does not explicitly name or differentiate against sibling tools such as election_equipment_jurisdiction, so the sibling distinction is implicit rather than stated.

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 default list and gives important domain cautions, such as federal certification being voluntary and how to refer to systems named in the April 2026 notice. It does not, however, explain when to use this tool versus alternatives or name a sibling tool for a different voting-system query.

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

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

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add behavior. It usefully discloses the high-signal filter (importance ≥ 60) and the event categories, but says nothing about ordering, pagination, or what an entity with no qualifying events returns.

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

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

Two sentences, front-loaded with the tool's identity and scope. The event list is long but each item defines the boundary of what counts as 'material,' so every element 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 carries the burden of describing returns, and it does so by enumerating the event categories emitted. It stops short of describing the shape, ordering, or empty-result behavior, but for a filtered-feed tool the scope disclosure is largely sufficient.

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

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

Schema description coverage is 100% – both 'key' (accepted identifier types) and 'days' (default 180, max 730, some sources undated) are fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 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?

The description states a specific resource ('cross-vertical alert feed for one entity') and enumerates the event categories it surfaces (Class I recalls, 13D filings, insider sales, restatements, etc.), so an agent knows exactly what it yields. It does not, however, explicitly contrast itself with near siblings like entity_timeline, cross_vertical_active, or company_risk_flags, which weakens true disambiguation.

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