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

With no annotations provided, the description carries the full transparency burden. It discloses that mixed geography levels will likely cause an API error, and that each place's value returns with margin of error. This adds meaningful behavioral context beyond the schema, though it does not mention authentication, rate limits, or explicit read-only status (which is inferred from '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?

The description is four sentences, each serving a distinct purpose: core functionality, parameter explanation, error warning, and return value/source. No filler or redundancy. Information is front-loaded with the primary action in the first sentence.

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 simple scope and the presence of an output schema, the description covers all essential aspects: parameter constraints, error conditions, return format, and data source. The presence of an output schema handles detailed return structure, and the description adds value with the MOE note and source attribution.

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

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains that 'metric' is the canonical_name, 'fips' is a list of 2-25 FIPS codes, and clarifies optional 'dataset' values ('acs1' or 'acs5') and 'year'. This adds critical meaning to every parameter, going beyond what the bare schema 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 clearly states a specific action ('Compare'), a specific resource ('a single US Census metric'), and the scope ('across 2 to 25 places at the same geography level'). This distinguishes it from siblings like get_census_place_metrics or explore_census_metrics, which focus on single places or exploration.

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 provides clear usage context (2-25 places, same geography level) and explicitly warns against mixed geography levels. It does not name alternatives or explicitly state when not to use it, but the constraints and purpose imply appropriate usage. A sibling tool like explore_census_geographies is naturally understood as complementary, though not named.

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

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

With no annotations provided, the description carries the full burden. It discloses critical behavior: 'never seasonally adjusted', 'single period', the year/month coupling rule, the 'month=13' annual-average row, and the data source. This goes well beyond the schema and provides the agent with essential constraints.

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 three sentences, front-loaded with the core purpose, followed by precise parameter details. Every sentence adds value, with no repetition or fluff.

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 (3 params, one required), the description fully covers all inputs and usage constraints. An output schema exists, so return-value details are not required. The description is complete enough for an agent to select and 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?

The schema has zero description coverage, but the description compensates fully: it explains fips format with a concrete example, the 10-county limit, the optionality and coupling of year/month, and the special month=13 value. This is exemplar parameter documentation.

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 'Compare LAUS unemployment metrics across up to 10 US counties for a single period', which clearly states the verb (compare), resource (LAUS unemployment metrics), and scope (counties, up to 10, single period). It also distinguishes from sibling tools like compare_state_unemployment by specifying county-level comparison.

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

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

The description provides clear usage context: it specifies 'Never seasonally adjusted', 'Maximum 10 counties per call', and the coupling requirement for year/month. However, it does not explicitly name alternatives or when-not-to-use, stopping 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?

With no annotations, the description carries the burden of behavioral disclosure. It explains defaults, constraints (max 10 states, year/month pairing), and special values (month=13), which is strong. It does not discuss error handling or output specifics, but the output schema covers that. It's thorough but not exhaustive.

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

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

The description is information-dense but well-structured. It leads with the core purpose, then parameter rules, then source. Every sentence adds value; no fluff or repetition.

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

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

Given the output schema exists, the description does not need to explain return values. It covers all parameters, their constraints, defaults, and the data source. This is a complete guide for invoking 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 0%, so the description must compensate. It fully does: explains fips format with examples, maximum states, adjustment options, year/month dependency, and the special annual-average month. This far exceeds the bare schema and gives the agent everything needed to correctly populate parameters.

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 the tool compares LAUS unemployment metrics across up to 10 US states for a single period. The verb 'compare' and resource 'LAUS unemployment metrics' are specific, and the scope distinguishes it from siblings like get_state_unemployment or compare_county_unemployment.

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

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

It provides clear usage context: when to use (multi-state comparison), how to specify parameters (fips format, adjustment, year/month pairing, month=13), and defaults (seasonally adjusted). However, it does not explicitly mention alternatives or when not to use this tool, 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?

With no annotations provided, the description carries the full burden and does so excellently. It discloses the one-time HMAC signing secret that must be saved and won't be shown again, plus the 402 error on free-tier. This is critical behavioral context beyond the schema and enriches the agent's understanding of side effects and prerequisites.

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 moderately long, but every sentence carries unique value: purpose, required params, optional params, return details, and error/plan restriction. It is well-structured and information-dense without being verbose.

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

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

Despite having an output schema, the description adds extra context the schema wouldn't provide: the one-time secret caveat, the HTTPS requirement, and the paid-plan error condition. It covers the full lifecycle of the call—inputs, outputs, and failure modes—making it highly 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 0%, so the description must explain all parameters. It does this thoroughly: url must be HTTPS, events uses examples like 'filing.created', filing_types narrows to form types like '10-K'/'8-K', and description is for user notes. This fully compensates for the empty 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 opens with a clear verb-resource pair: 'Create a webhook subscription.' It explicitly lists required and optional parameters, and the sibling tools (update_webhook, delete_webhook, list_webhooks) make it unambiguous that this is a creation tool. No 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?

The description gives clear context: required HTTPS URL and events, optional filing_types and description, and a note that webhooks require a paid plan. It doesn't explicitly call out when not to use it or reference alternatives, but the sibling tool names imply the distinctions. This is clear enough for an agent to select this tool for creation.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: irreversibility and the fact that delivery history is retained server-side while the subscription stops receiving events. This goes beyond the bare operation name and gives the agent important safety information.

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 two concise sentences: the first states the action, and the second covers key consequences. There is no extraneous information, and the structure is front-loaded with the verb.

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 delete operation with one parameter and an output schema, the description sufficiently covers the essential behavior (irreversibility, retention of history). It does not need to explain return values since an output schema exists, though it could optionally mention preconditions like the subscription needing to exist.

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

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

Schema coverage is 0% and the description does not mention the subscription_id parameter at all. While the parameter name is self-explanatory, the description fails to add any meaning beyond the schema, such as specifying that this ID identifies the webhook to delete.

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 'Delete a webhook subscription,' which is a specific verb+resource that clearly states the tool's action. It distinguishes itself from sibling tools like create_webhook, get_webhook, and update_webhook by using the explicit 'delete' verb.

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 provides clear context on the outcome: delivery history is retained, the subscription stops receiving new events, and the action is irreversible. However, it does not explicitly mention when to choose this over alternatives (e.g., update_webhook to disable), so it lacks explicit exclusions.

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

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

With no annotations, the description carries the burden. It implies a read-only discovery behavior and provides filter categories and source enumerations, adding useful context. However, it does not disclose whether results are paginated, limited, or how search semantics work (e.g., exact vs partial match).

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 focused sentences, front-loaded with the main purpose and immediately followed by usage guidance and parameter details. Every sentence 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?

The tool is a simple exploration interface with three optional parameters and an output schema to cover return values. The description explains purpose, when to use, and parameter values, making it sufficiently complete for onboarding. Minor gap: no mention of list size or examples, but not essential.

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

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

Schema description coverage is 0%, but the description compensates by explaining the query parameter as 'search by name' and enumerating valid values for category ('employment', 'wages', 'derived') and source ('ces', 'qcew', 'oews'). This adds meaning beyond the bare property names.

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

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

The description uses a specific verb 'Discover' and names the resource 'available BLS metrics and what data the API offers.' It clearly distinguishes this exploration tool from sibling tools like 'explore_census_metrics' and 'explore_sba_metrics' by naming BLS and labor market data.

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

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

Explicitly states to use it 'before making specific queries' to understand available data, providing clear usage context. It does not explicitly list alternatives or when not to use it, but the guidance is strong enough for an exploration 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?

No annotations are provided, so the description carries the full transparency burden. It discloses the data source (public-domain US Census Bureau data) and describes the output (geography levels and counts), implying a read-only operation. It does not explicitly state side-effect safety or return format, but the simplicity and list semantics make this adequate.

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 exactly two sentences: the first states the core purpose, the second adds usage guidance and source. Every sentence earns its place, with no redundancy or filler.

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

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

For a simple, parameterless discovery tool that outputs a list of levels and counts, the description is complete. It tells the agent what the tool returns, when to use it relative to a sibling tool, and provides source context. An output schema exists, so detailed return value documentation is unnecessary.

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 has zero parameters, and the input schema is empty, so parameter-level documentation is unnecessary. With schema coverage at 100% and no parameters to describe, the baseline of 4 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 clearly states the tool lists available US Census geography levels and the number of places at each level. It uses a specific verb (List) and resource (US Census geography levels), and distinguishes from sibling search_census_places by framing itself as a discovery step.

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 explicitly says 'Use this first to discover what levels exist before calling search_census_places', providing direct when-to-use guidance and naming an alternative to avoid.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals a 50-result cap, case-insensitive filters, and substring match behavior on query. It does not mention pagination or error handling, but for a read-only discovery tool this is reasonable. The description adds value beyond the schema by specifying match semantics and 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?

The description is compact and organized: purpose, usage guidance, parameter details, result limit, and source. Each sentence delivers distinct information without redundancy, and the most critical usage guidance is front-loaded.

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

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

For a simple two-parameter tool with an output schema, the description covers what the schema does not: workflow placement, search behavior, and result cap. It is sufficient for an agent to select and 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 coverage is 0%, so the description fully compensates. Query is defined as 'substring match on display_name or canonical_name', and category is illustrated with concrete examples ('demographics', 'economy', 'housing'). Case-insensitivity is also documented, which is not present in 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 identifies the tool as a discovery endpoint for US Census Bureau metrics, with the specific verb 'Discover'. It explicitly differentiates from sibling tools by stating its role: 'Use this to find the canonical_name of a metric before calling the place or breakdown 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?

It explicitly states when to use this tool versus alternatives: 'Use this to find the canonical_name of a metric before calling the place or breakdown tools.' It also distinguishes from BLS tools by mentioning 'US Census Bureau data', giving implicit selection criteria.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It does describe the output shape (canonical names with display name, category, unit, update cadence) and mentions the public-domain source, which adds useful context. However, it does not explicitly state read-only semantics, how the limit parameter behaves, or potential pagination/rate-limit behaviors, leaving some behavioral aspects opaque.

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 four sentences, front-loaded with the primary purpose, then param details, then output summary, sibling pointer, and source attribution. Every sentence provides distinct, useful information with no filler or redundancy. It is exemplary in both length and organization.

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 (3 params, output schema present, no annotations), the description covers the core purpose, parameter constraints (except limit), output contents, and the sibling relationship. The output schema supplies structured return details, so the description need not do that. The main gap is the undocumented limit parameter and lack of explicit pagination notes, but overall it is highly usable.

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

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

Schema coverage is 0%, so the description must compensate. It explains category (valid values 'volume', 'outcomes', 'characteristics') and query (free text, minimum 2 characters), which adds meaning beyond the schema's bare type definitions. But it completely omits any explanation of the `limit` parameter, which is one of the three parameters, so the compensation is incomplete.

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: 'Browse the SBA 7(a) metric catalog' and explains what it lets you do ('discover available metrics by category or keyword'). It distinguishes itself from siblings like get_sba_metric_detail and explore_bls_metrics by scoping to the SBA 7(a) metric catalog, making the tool's niche clear.

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

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

Explicitly states when to use this tool versus the alternative: 'Use get_sba_metric_detail to fetch the full definition for a single metric.' It also provides concrete search constraints (category values, query minimum length), giving clear guidance for invocation. The sibling differentiation is strong and actionable.

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

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

With no annotations provided, the description carries the full burden. It discloses the data source ('from proxy statements') and a notable behavior: historical tickers resolve to the current entity ('FB' resolves to META). This adds useful behavioral context beyond a generic read operation. However, it does not mention any limitations or side effects, though none are apparent for a 'get' operation.

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

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

The description is extremely concise: two sentences, with the first sentence stating the purpose and the second detailing the primary parameter. Every word adds value, no fluff, and critical information is front-loaded. This is an ideal 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?

The description is complete for the tool's core function and leverages the output schema to avoid restating return structures. It provides source, purpose, and key input variants. However, the absence of a description for the 'year' parameter is a notable gap, especially given its presence in the schema. Overall, the description is adequate but could be more complete with a brief mention of 'year'.

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 has 0% description coverage, so the description must compensate. It does an excellent job explaining the 'ticker' parameter with examples and accepted formats, but the 'year' parameter is not described at all. Since there are only two parameters and one is fully covered while the other is ignored, the description partially compensates but leaves a gap.

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

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

The description clearly states the tool's function with a specific verb ('Get'), the resource ('board of directors'), and the specific data fields returned (name, age, tenure, independence, committee memberships). This distinguishes it from sibling tools like get_executive_compensation, making the purpose unambiguous.

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

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

The description provides clear context for when to use the tool—when you need board of directors information from proxy statements. It also gives detailed input formats for the ticker parameter, which helps in practical usage. However, it does not explicitly mention alternatives or when not to use the tool, unlike the top-tier examples, but the context is still strong enough to guide an agent.

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

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

With no annotations, the description carries the transparency burden. It clearly indicates this is a read-only metadata lookup and adds context about public-domain data. It doesn't fully disclose possible failure modes or rate limits, but for a metadata retrieval tool this is adequate.

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 compact sentences: purpose, usage context, and parameter/source info. No filler, front-loaded with the most important information, and each 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?

Despite minimal schema and no annotations, the description covers the tool's purpose, input semantics, output contents, and data source. With a single parameter and an output schema available, this is complete for an agent to select and 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?

The schema gives no description for the 'metric' parameter, but the description explains it is the canonical_name and gives an example ('median_household_income'). This fully compensates for the 0% schema coverage and clarifies the expected value format.

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

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

The description clearly states the tool gets metadata for a single US Census metric, including source variables and margin-of-error formula type. It uses a specific verb and resource, and the phrase 'single metric' differentiates it from comparison tools like compare_census_metric.

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

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

Explicitly says 'Use this after explore_census_metrics to understand exactly what a metric measures,' providing a clear workflow placement. This tells the agent when to invoke this tool relative to 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?

No annotations are provided, so the description carries the burden. It discloses return fields, FIPS length rules, and public-domain source, which conveys a read-only nature. It does not cover invalid-input behavior or rate limits, but for a simple lookup the transparency is adequate.

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: purpose, param explanation, and source. Every sentence provides necessary information, front-loaded with the tool's core function, and no fluff.

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 output schema exists and the tool is a simple single-place lookup, the description covers purpose, return contents, parameter semantics, and data source. No significant missing context for this 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 0%, but the description fully compensates by explaining that 'level' is the geography level and 'fips' is the FIPS code, with specific length mappings (state=2, county=5, place=7, tract=11). This adds critical meaning beyond the bare 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 the tool gets detailed geographic information for a single US Census place, enumerating specific return fields (name, parent place, population, area, coordinates, child levels). This distinguishes it from siblings like search_census_places and get_census_place_metrics.

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 for a known single place by FIPS code, and the focus on 'geographic information' separates it from metric-focused siblings. However, it does not explicitly call out alternatives such as explore_census_geographies or search_census_places.

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

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

With no annotations, the description describes parent/child geography behavior, source of data, and optional parameters, but it does not disclose potential failure modes, pagination, or explicit read-only status. It is adequate but lacks deeper 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 three sentences: the main purpose, a concrete example, and parameter definitions. It is front-loaded, free of filler, and every sentence adds value.

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

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

The output schema covers return values, and the description provides purpose, example, source, and parameter semantics. It is fairly complete for an agent to select and invoke the tool, though it lacks explicit guidance on alternatives or 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 coverage is 0%, yet the description compensates by explaining every parameter: fips as parent FIPS, metric as canonical_name, dataset with allowed values ('acs1' or 'acs5'), and year as optional. It adds meaning beyond bare property names, though format details for fips/metric are light.

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 ('break down') and clearly identifies the resource: a US Census metric across child geographies of a parent place. The state-FIPS-to-counties example makes the scope concrete and differentiates it from sibling tools like get_census_place_metrics or explore_census_geographies.

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

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

It provides a clear example of when to use the tool (state FIPS to get county-level metrics) but does not explicitly name alternatives or state when not to use it. The context is sufficient to infer the intended use case, but exclusions are absent.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the default behavior (latest year, server-chosen) and clarifies that data is public-domain. It does not mention potential side effects, but as a read-only getter this is acceptable.

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 three concise sentences: function, behavior, and parameter explanation. It is front-loaded with the primary purpose and avoids any 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?

Given the tool's single parameter and the existence of an output schema, the description is complete. It covers the tool's role, the default year behavior, and parameter specifics without redundant return-value details.

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 only defines 'fips' as a string with no description (0% coverage). The description fully compensates by explaining what fips is and the length variations by geographic level. This is essential for correct use.

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: 'Get the full set of US Census metrics for one place, grouped by category.' This clearly states what the tool does. It distinguishes itself from siblings by positioning it as a 'Census profile' for a single place.

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 advises using this when you want a broad Census profile: 'Use this as a "Census profile" for a single place.' This implies when to choose it over metric-specific tools, though it does not explicitly name alternatives or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the series behavior, optional dataset, and source, but does not detail response format or error conditions. That said, the presence of an output schema means return values are already documented, so the description adds adequate value for a simple read operation.

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

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

The description is concise and well-structured: first sentence states the purpose, second explains the key behavioral variation, third defines parameters and source. No wasted words; information is front-loaded and easy 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?

The description covers all essential aspects for correct invocation: what the tool does, how to control the series length, what each parameter means, and the data source. It does not mention how to discover valid metric names, but this is implicitly handled by sibling tools such as explore_census_metrics, and the output schema defines the return structure.

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 has 0% parameter descriptions, so the description must compensate. It does so effectively: 'fips is the place's FIPS code; metric is the canonical_name; dataset is optional ('acs1' or 'acs5')' and the year behavior is explained. Every parameter is given meaning beyond the raw 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 the tool's specific function: 'Get a time series for one US Census metric in one place.' This includes a specific verb (Get), resource (time series for a metric), and scope (one place). It distinguishes from sibling tools like compare_census_metric or get_census_place_metrics by focusing on a single metric and single place.

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 provides clear context on how to use the tool: 'Omit year for the full series; provide year for a single observation.' It also explains parameter roles and optional dataset values. However, it does not explicitly mention when to use alternative tools or when not to use this one, though the purpose statement implies differentiation from 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?

No annotations are provided, so the description must carry behavioral weight. It discloses default behavior ('Default includes labor_context + lending_context') and ticker resolution rules ('FB resolves to META'), but does not explicitly state read-only operation or behavior when data is missing.

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 detailed but every sentence serves a purpose: purpose, usage, defaults, and parameter semantics. It's organized with a clear 'Args:' marker, and is not bloated despite its length.

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 an output schema present, the description doesn't need to explain returns. It covers purpose, usage, parameters, and defaults thoroughly enough for an agent to invoke correctly, though it omits potential error cases or data availability caveats.

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 descriptions are empty (0% coverage), so the description's detailed ticker formats ('10-digit CIK ("0000320193"), stripped CIK ("320193"), or historical ticker') and include composition are essential and well-documented.

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 the tool fetches a company profile with optional sub-resources ('Get company profile plus any combination of sub-resources in one call'). It lists specific sub-resources, differentiating it from sibling single-resource tools like get_financials or get_ratios.

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 explains when to use (to compose multiple sub-resources) and gives an example ('Pass include=... to compose exactly what you need'), but does not explicitly contrast with calling individual endpoints or state when not to use it.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds useful behaviors like default industry ('10'), default ownership ('private'), and omitting year/quarter for all data. However, it does not mention any potential side effects, error conditions, data lag, or authorization requirements, leaving notable gaps for a non-annotated tool.

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

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

Three sentences, front-loaded with the core purpose, followed by the most important parameter guidance. No filler or repetition; every sentence adds value.

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 5-parameter schema and output schema availability, the description covers the essential invocation context: data source, FIPS format, defaults, and optional time filtering. Minor omissions such as valid quarter range or ownership/industry codes are not required for basic use, but keep it just shy of fully 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 0%, but the description compensates strongly: FIPS format and example, industry default meaning 'all industries', ownership default, and explicit instruction to omit year/quarter for all available data. This transforms bare parameter names into usable invocation details, especially for the required fips.

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

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

The description uses a specific verb-resource pair ('Get quarterly employment data for a US county') and names the data source (BLS QCEW), clearly distinguishing it from siblings like get_county_wages and get_county_unemployment. The FIPS example further clarifies the exact scope.

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: it is for county-level quarterly employment from QCEW, with defaults and optional year/quarter behavior. It does not explicitly name alternatives or state when not to use the tool, so it misses the top tier for explicit 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?

With no annotations, description carries full burden. It discloses the default behavior (latest quarter if no period filters) and required period format. It notes the public domain source, but doesn't discuss error handling or rate limits, which are not critical for this data retrieval.

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 purpose and metrics, then usage, then parameter details. No fluff, every sentence provides value.

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 output schema exists, description doesn't need to explain return values. It covers purpose, default behavior, time series usage, parameter formats, and data source. Comprehensive for a data retrieval tool.

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

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

Description explains fips format with example, from_period/to_period format, and industry NAICS filter. It omits the year and quarter parameters present in the schema, meaning some parameters are not described, but key ones are covered with concrete examples.

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?

Description clearly states it returns quarterly SBA 7(a) loan aggregates for a single US county, listing specific metrics. This distinguishes it from sibling tools like get_state_lending or get_county_employment by its scope and data type.

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 usage context: without period filters returns latest observation, and instructs to supply both from_period and to_period for series. However, it doesn't explicitly contrast with alternative lending tools or exclude other parameters.

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

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

No annotations are provided, so the description carries the full burden. It discloses critical behavioral traits: never seasonally adjusted, no SA/NSA option, default latest-observation behavior, and the meaning of annual_only (M13 rows). This is strong transparency beyond what the schema offers.

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 slightly long but every sentence adds value—purpose, behavioral traits, parameter details, alternative tool, and source. It is front-loaded with the main purpose. The inclusion of source is extra but not 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?

Given the tool's moderate complexity and presence of an output schema, the description covers usage, parameters, behavior, and alternatives. Edge cases like default dates and annual_only are addressed, making it complete for an agent 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 has no descriptions (coverage 0%), so the description compensates fully: explains fips with a concrete example, specifies YYYY-MM format for from_date/to_date, and clarifies annual_only behavior. This is essential semantic info not present in 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 'Get monthly LAUS unemployment data for a single US county', which specifies the verb, resource, and scope. It distinguishes from sibling tools by explicitly noting 'single county' and pointing to compare_county_unemployment for multi-county comparisons.

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 explicit usage guidance: without dates returns latest, with both dates returns time series, annual_only option for annual averages, and explicitly mentions an alternative tool for comparing multiple counties. This helps the agent choose the correct tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the meaning of location quotients and the industry default, which is useful context. However, it doesn't disclose limitations like data coverage or response format, leaving some ambiguity.

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 three sentences long, front-loaded with the primary action, and contains no filler. Every sentence adds meaningful detail about the tool's output or parameters.

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

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

The description covers the core purpose and provides an interpretation of location quotients, but it leaves several optional parameters semantically unexplained. The presence of an output schema covers return structure, but the underdefinition of year, quarter, and ownership reduces completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It explains fips with a concrete example and clarifies the industry default, but year, quarter, and ownership are left undefined. This is a significant gap for a five-parameter tool.

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 the tool's function: 'Get a wage snapshot for a US county including location quotients.' It uses a specific verb and resource, and the mention of location quotients distinguishes it from sibling tools like get_county_employment and get_county_unemployment.

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 provides contextual guidance by explaining what a location quotient above 1.0 means and noting the industry default. This helps an agent understand when to use this tool for county-level wage analysis, though it doesn't explicitly compare to 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It explains ticker flexibility (CIK, stripped CIK, historical ticker resolution) and the all-companies default, but omits details like date formatting, category values, sorting, or pagination 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?

The description is compact and front-loaded. The first sentence captures purpose, the second explains scoping, and the Args block provides detailed parameter guidance without unnecessary fluff.

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 five-parameter read tool with an output schema present, the description is largely complete: it covers purpose, scoping modes, and ticker variants. Minor gaps around date/category formats are acceptable because the output schema exists and the core invocation is well explained.

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

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

Schema description coverage is 0%, so the description must compensate. It adds thorough semantics for ticker, but only vaguely mentions 'category and date range' without explaining valid date formats or category options. Limit is left entirely to schema 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?

The description clearly states the tool gets 8-K corporate events and enumerates specific event types (earnings, M&A, leadership changes, material agreements). It distinguishes itself from sibling tools by naming the exact SEC filing type and scope options.

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?

Guidance is clear: use ticker to scope to one company, omit to search all, and filter by category/date range. It does not explicitly name alternatives or when-not-to-use, but the context is sufficient for selecting this tool among many 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?

With no annotations provided, the description carries the full burden. It adds meaningful behavioral details: data source (proxy statements), included fields, conditional availability of CEO-to-median pay ratio, and historical ticker resolution ('FB' resolves to META). It omits error behavior or rate limits, but the core read-only behavior is well disclosed.

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 concise and front-loaded with the purpose, followed by precise argument details. Every sentence adds value; there is no redundant or vague phrasing.

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?

An output schema exists, so return values are covered. The description explains source, fields, identifier formats, and special cases, but the missing year parameter semantics and lack of usage context prevent a perfect score. It remains reasonably complete for a simple lookup 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 coverage is 0%, so the description must explain parameters. It thoroughly documents ticker, including examples and accepted formats, but completely omits the year parameter. This leaves ambiguity about fiscal year selection and default behavior—a clear gap.

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

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

The description clearly states the tool retrieves executive compensation (salary, bonus, stock awards, total) from proxy statements, naming specific data fields. This distinguishes it from sibling tools like get_financials or get_company, which cover broader or different financial data.

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 guidance is given on when to use this tool versus alternatives. It does not mention exclusions or compare to related finance tools, though it does provide accepted identifier formats. The dimension requires explicit when/when-not/alternative guidance, which is absent.

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

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

With no annotations, the description carries full weight. It discloses a nuanced behavior about per-point currency and taxonomy metadata being authoritative when a filer changes presentation currency mid-series. For a read-only data retrieval tool, this is meaningful context, though it does not mention rate limits, error handling, 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?

The description is front-loaded with the core purpose, followed by a brief metadata note and then organized metric lists by category. The metric lists are long but justified since they define the metric parameter. The 'Args' section is terse. Overall, it is dense but each sentence contributes value.

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

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

The description covers the tool's core behavior, metric vocabulary, and ticker formats, and an output schema exists to document return values. It lacks explicit guidance on period values (e.g., 'annual' vs. 'quarterly') and date range semantics, but those are inferable from the parameter names and defaults. Overall, it is sufficiently complete for a data-retrieval tool.

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

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

The schema has 0% coverage for parameters in the description, but the description compensates significantly by enumerating all valid metric names and detailing accepted ticker formats (including CIK and historical ticker resolution). However, period, from_year, and to_year are not explained beyond their schema defaults, leaving minor ambiguity around period values.

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 clear, specific verb and resource: 'Get a single financial metric over time.' It explicitly states the tool returns a time series for trend analysis, distinguishing it from sibling tools like get_financials (which presumably returns multiple metrics). The extensive list of supported metrics further clarifies scope.

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 to use the tool through 'single financial metric' and 'time series for trend analysis,' suggesting it's for one metric over a time range. It provides ticker format guidance including CIK and historical tickers, but does not explicitly name alternative tools or state when not to use it, so it falls short of a full 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?

It discloses useful behavioral details such as output metadata (taxonomy, currency, presentation format) and historical ticker resolution ('FB' → META). Since no annotations are provided, the description carries the full burden, but it omits potential edge cases like invalid ticker behavior, rate limits, or how the 'period' and 'quarter' parameters affect the response.

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 compact at three sentences plus an Args line, with the primary purpose front-loaded. However, the Args section only details ticker, which is slightly misleading because other parameters exist, and the structure could be improved by listing all parameters or explaining the period/year/quarter semantics more clearly.

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 parameters, 0% schema coverage, no annotations, but an output schema exists), the description covers the main entry points (statement type, years, ticker) and output metadata. However, it omits parameter semantics for year/quarter/period and lacks sibling differentiation, leaving noticeable gaps for an agent 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?

The description explains the ticker parameter in detail and mentions statement and years, but the input schema has 6 parameters with 0% description coverage. The 'year', 'quarter', and 'period' parameters are not explained at all, leaving the agent uncertain about how to request specific fiscal years or quarterly data. This is a significant gap for a tool with no schema-level descriptions.

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 it retrieves financial statements (income statement, balance sheet, cash flow) from SEC filings for US public companies, with a specific verb and resource. It distinguishes itself from sibling tools like get_financial_metric, which likely focus on individual metrics, by emphasizing full financial statements.

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

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

The description provides usage hints for statement='all' and years=N for trend analysis, which implies when to use different parameter configurations. However, it doesn't explicitly mention when to choose this tool over alternative sibling tools or when not to use it, leaving the guidance partly implied 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds value by revealing response fields (share counts, market values, 13F report_quarter, filed_at) and the input method, but the claim of accepting CIK contradicts the schema, creating confusion. It does not discuss permissions, rate limits, or side effects, though as a read operation the safety profile is implied.

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 two sentences with no filler. It front-loads the purpose and includes useful details efficiently. The minor CIK inconsistency does not detract from conciseness.

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

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

The presence of an output schema covers return value structure. However, with four parameters and zero schema descriptions, the tool description leaves limit, quarter, and position_type undefined. The CIK discrepancy further reduces completeness, making the description adequate but not fully informative.

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

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

Schema description coverage is 0%, so the description must explain parameters. It clarifies fund_name (and mentions CIK, though not a schema parameter) but does not explain limit, quarter, or position_type. The quarter parameter is only indirectly hinted by the response field report_quarter, but no explicit semantics are provided.

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 the tool retrieves a fund's portfolio holdings, with specific details about share counts and market values. It distinguishes from siblings like get_institutional_holders, which likely returns holders of a security, but a minor inconsistency ('Accepts fund name or CIK') is noted since the schema only includes fund_name.

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 not provide explicit guidance on when to use this tool versus alternatives or mention any exclusions. It implies use for fund holdings but offers no comparison to related tools such as get_holding_changes or get_institutional_holders.

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

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

No annotations are provided, so the description carries the full burden. It discloses the two usage modes and ticker format details (CIK, historical ticker), which is useful. However, it does not explain behavior around the 'limit', 'quarter', or 'change' parameters, nor what happens when both or neither of the key parameters are provided. Adds some value but is not comprehensive.

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 concise, with two sentences plus a focused note on ticker formats. It is front-loaded with the main purpose and provides the most critical usage detail without unnecessary filler. Slightly unstructured due to the inline 'Args' listing, but still efficient.

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 5 parameters and no annotations, the description is incomplete. It omits semantics for 'change' and 'quarter', which are essential for using the tool correctly. The output schema exists but does not offset the missing parameter guidance. It is adequate only for basic ticker/fund_name queries.

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

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

Schema description coverage is 0%, so the description must compensate. Only 'ticker' is explained in detail (with formats), and 'fund_name' is briefly described. The 'limit', 'change', and 'quarter' parameters are completely unexplored, leaving significant ambiguity for 3 of 5 parameters. This is a major gap.

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

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

The description clearly states the tool's function: getting quarter-over-quarter changes in institutional holdings. It distinguishes itself from sibling tools like get_fund_holdings or get_institutional_holders by focusing on changes (buying/selling) and explicitly explaining the two query modes (ticker vs fund_name).

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 concrete usage direction: use 'ticker' to see which funds are buying/selling a company, or 'fund_name' to see what a fund is buying/selling, and explicitly requires providing exactly one of these. It does not mention alternative tools or exclusions, but the primary use cases are clear.

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

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

No annotations are provided, so the description carries the full burden. It states what data is returned ('child industries and data availability') but does not disclose rate limits, authentication, or explicitly confirm read-only behavior. The 'Get' verb implies a read operation, but behavioral context beyond the output content is limited.

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 two concise segments: purpose and parameter note, with no filler. It front-loads the primary action and resource, then gives the essential parameter 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?

For a one-parameter tool with an output schema, the description covers purpose, usage context, and parameter semantics. The output schema presumably documents the return structure, so the description is complete without over-explaining.

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

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

Schema coverage is 0%, and the description fully compensates: 'naics is the NAICS code (e.g. '5112' for Software Publishers)' adds type, format, and a concrete example, making the parameter meaningful beyond the bare schema entry.

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 ('Get') and resource ('detailed information for a single BLS industry') with scope ('including child industries and data availability'). It clearly distinguishes from search_industries by emphasizing 'single' and 'drill into,' but does not explicitly differentiate from industry-specific siblings like get_industry_employment.

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 after search_industries to drill into a specific industry.' This establishes a workflow and implies when to use the tool, but does not mention exclusions or alternatives beyond search_industries.

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?

Since no annotations are provided, the description carries the burden of behavioral disclosure. It does a good job by explaining the default latest-observation behavior, that providing from_date/to_date yields a time series, that adjustment defaults to 'sa', and that geo/state/metro narrow the geography. It stops short of stating data freshness, missing-data behavior, or explicitly calling out read-only semantics, but the output schema covers return format.

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

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

The description is compact and efficient: two sentences plus a short param list. Each sentence adds value—first states the purpose, second explains default vs. time-series behavior, and the param list clarifies key inputs. There is no fluff or repetition.

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

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

Given the tool has 7 parameters, no annotations, and an output schema, the description covers the primary use case and main parameters but leaves gaps around geography parameter interactions (e.g., can state and metro be combined? what formats are accepted?). It is adequate for a simple call but not fully comprehensive for a 7-parameter tool.

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

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

The input schema has no parameter descriptions (0% coverage), so the description must compensate. It does: it defines naics as the NAICS code, adjustment as 'sa' or 'nsa', dates as YYYY-MM, and explains geo/state/metro as geography narrowers. However, it does not specify the required value formats for state/metro/geo or whether they are mutually exclusive, leaving some ambiguity.

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 action and resource: 'Get employment data for a BLS industry.' This clearly distinguishes the tool from siblings like get_county_employment or get_county_wages by focusing on industry-level employment. It also states the default behavior ('latest observation with year-over-year changes'), adding useful scope.

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 context by referencing 'BLS industry' and explains when to provide date ranges and how to set adjustment, but it never explicitly states when to use this tool versus alternatives such as get_county_employment or get_occupation_wages. There are no exclusions or alternative recommendations, so usage guidance remains implied 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?

With no annotations, the description carries the transparency burden. It discloses the default scope, the latest-observation default when no period filters are given, the requirement for both from_period and to_period for a time series, and the data source. It does not explain how the year and quarter params interact with period filters, which is a notable omission.

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 four sentences long, front-loaded with the core purpose, and every sentence adds useful detail about scoping, behavior, parameter format, or source. There is no filler or repetition.

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

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

The description covers the main use cases (national, state, county, time series) and the output schema exists to document return values. However, the year/quarter parameters are left unexplained, and the description does not explicitly differentiate from sibling lending tools, leaving the overall context incomplete.

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 description coverage is 0%, so the description must compensate. It does explain naics, geo, state/county, from_period, and to_period, including format examples. However, the year and quarter parameters are completely undocumented and their relationship to the period filters is unclear, leaving a significant gap.

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

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

The description uses a specific verb 'Get' and names the exact resource: 'quarterly SBA 7(a) loan aggregates for a NAICS industry.' It also immediately states the national default, which differentiates it from geography-specific sibling tools like get_county_lending and get_state_lending.

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 on when to use national scope vs. state/county scoping via geo/state/county parameters, and explains that period filters are needed for time series. It stops short of explicitly naming alternatives or saying when not to use this tool, so it earns a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses default behavior (latest observation) and that providing date range yields a time series. However, it does not explain the 'measures' or 'adjustment' parameters, nor the NAICS format expected, leaving gaps in behavioral expectations.

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 core purpose, followed by essential usage detail and a prerequisite. No redundant wording; 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?

The tool has 5 parameters and an output schema, but the description omits guidance on 'measures' and 'adjustment,' which are important for customizing queries. While the output schema may cover return format, the description is not fully complete for a tool of this complexity, though it does cover the main use case and default behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to from_date/to_date by specifying 'YYYY-MM' format and implying time series behavior, and it implies naics is an industry code. But it leaves measures and adjustment completely unexplained, so it only partially compensates for the schema's lack of descriptions.

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 the tool gets labor market turnover data (job openings, hires, quits, layoffs) for an industry by NAICS code. This specific verb+resource+scope distinguishes it from siblings like get_state_turnover and get_regional_turnover, which are geography-based.

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 provides clear context: 'Shows the latest observation by default. Provide from_date and to_date (YYYY-MM) for a time series.' It also instructs to 'Use search_industries first to find NAICS codes,' which is a useful prerequisite. However, it does not explicitly exclude alternatives or state when-not-to-use, so it falls short of a 5.

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

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

With no annotations provided, the description discloses key behavioral traits: default aggregation ('rows are aggregated transaction events... same-day 10b5-1 tranches collapsed'), the flat=True option for per-slice rows, and ticker resolution ('historical ticker resolves to META'). This adds value beyond the schema, though it does not mention rate limits, auth, or other side effects.

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 reasonably concise and front-loaded with the core purpose. The 'Args:' block is slightly redundant because it duplicates ticker details already covered in the prose, but the overall structure is clear and not overly verbose.

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

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

Considering 7 parameters, no annotations, and the presence of an output schema, the description covers the essential use cases: ticker scoping, filtering options, and default aggregation behavior. The lack of detail on 'limit' and transaction type values is a minor gap, but the description remains sufficiently complete for effective tool selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly explains ticker (including CIK, stripped CIK, historical ticker), explains flat=True, and mentions filtering by type, min_value, and date range. However, it omits the 'limit' parameter and does not specify allowed values or formats for 'type', 'min_value', or date range, leaving important gaps.

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 'Get insider trading transactions (Form 4)' and lists transaction types (purchases, sales, grants, option exercises), clearly defining the tool's scope. This distinguishes it from sibling tools like get_executive_compensation or search_filings by focusing specifically on Form 4 insider trades.

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 advises 'Use ticker to scope to one company, or omit to search across all companies' and mentions filtering by transaction type, minimum value, and date range, providing clear contextual guidance. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a full 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context beyond the name: response rows include report_quarter and filed_at, omitting quarter returns the latest available data, and historical tickers are resolved. It does not mention limit behavior or pagination, but for a read-only lookup this is sufficient.

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 tightly written in four sentences, leading with the core purpose and output, then efficiently covering parameter details with concrete examples in an 'Args:' section. No wasted words or redundant 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?

An output schema is present, so return values are covered there. The description sufficiently covers input formats, quarter default, and output row fields. Minor omissions like limit behavior and explicit differentiation from fund-holding tools prevent a perfect score, but overall it is complete for a focused lookup 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 coverage is 0%, so the description needs to compensate. It thoroughly explains the required ticker parameter (accepting CIK, stripped CIK, and historical ticker) and quarter semantics, but it does not mention the limit parameter at all, leaving it to the schema default of 20. This is a noticeable gap in an otherwise useful parameter explanation.

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 the tool's function with a specific verb and resource: 'Get which institutional funds hold a company's stock.' It distinguishes itself from sibling tools like get_fund_holdings by focusing on company stockholders rather than fund holdings, and lists output fields (shares held, market value, discretion type).

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 provides clear context on how to specify the company, including accepted formats like ticker, CIK, and historical ticker, and explains the quarter parameter's behavior when omitted. However, it does not explicitly mention alternative tools or when not to use this tool, so it stops short of full exclusion guidance.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the data source (US SBA, public domain), the quarterly history behavior, and the dependency between the two optional filters. This adds meaningful behavioral context beyond the schema, though it doesn't specify behavior for invalid IDs or period formats.

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 two sentences long, front-loaded with the primary purpose, and every clause adds value. The second sentence efficiently covers parameters, constraints, and source attribution without redundant 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?

Given the tool's simple get-by-id nature with optional filters, and the presence of an output schema, the description is complete. It covers what the tool does, the data source, filter semantics, and required dependencies, leaving no critical gaps for an agent 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 description coverage is 0%, but the description fully explains all parameters: lender_id identifies the single lender, and from_period/to_period define the quarterly range with format 'YYYY-Qq' and the constraint that they must be used together or omitted. This goes well beyond the schema's basic type and title information.

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 the tool's purpose: 'Get details and quarterly history for a single SBA 7(a) lender by lender_id.' This is a specific verb+resource+identifier, and it naturally distinguishes from siblings like get_lenders (plural) or get_county_lending.

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 provides clear parameter usage context: 'Optional from_period/to_period filters the quarterly history range... Both are required together for a range; omit both for full history.' It explains when to use the filters, but does not explicitly mention when to use this tool versus alternatives such as get_lenders.

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

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

With no annotations provided, the description discloses important behavioral constraints: the limit is capped at 50, sort accepts specific values with a default, and filter formats (FIPS, NAICS, YYYY-Qq) are specified. It does not describe pagination, but the output schema covers return structure, making this adequate for a read-only list tool.

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

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

The description is four concise sentences, front-loading the core action of listing ranked lenders. Each sentence adds necessary information (filters, sort, limit, source) without any fluff or repetition.

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

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

Given the 9-parameter schema and the existence of an output schema, the description covers all essential aspects: purpose, filters, sorting, limit, and data source. It is fully self-contained for an agent to select and 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?

The schema has 0% description coverage, but the description compensates thoroughly by documenting every parameter: state uses 2-digit FIPS, county uses 5-digit FIPS, industry uses NAICS, period ranges use YYYY-Qq, sort has three allowed values, and limit has a 50 cap. This exceeds the bare schema and adds essential context.

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 the tool lists SBA 7(a) lenders ranked by loan count, total amount, or average loan size, using a specific verb and resource. This distinguishes it from the singular sibling tool get_lender and other lending aggregation tools like get_county_lending or get_state_lending.

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 provides clear context for when to use the tool—when needing ranked lender lists with optional filters—but does not explicitly mention alternative tools or exclusions. It conveys the appropriate use case without naming 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that year and quarter are required by the API despite the schema listing them as optional, and it specifies the format for filters (2-digit FIPS, 5-digit FIPS, NAICS). It doesn't mention error handling, pagination, or exact output format, but the output schema likely covers return structure, making this a solid 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 three sentences: first states purpose and contents, second covers required and optional parameters with formats, third provides source attribution. Every sentence is necessary and information-dense, with the most important details 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?

The description is quite complete for a data retrieval tool: it names all key output dimensions, specifies required vs optional parameters, and adds source context. Gaps include not stating valid quarter values or aggregator behavior, and not explicitly distinguishing when to use this over sibling lending tools. An output schema exists, so return fields are covered.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining that year and quarter are required and must be passed together, and by giving formats for state, county, and industry (2-digit FIPS, 5-digit FIPS, NAICS). It doesn't specify valid quarter values (e.g., 1-4) or year range, but overall adds significant semantic meaning beyond the bare 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 opens with a specific verb and resource: 'Get SBA 7(a) loan distributions for a single quarter', followed by an explicit list of distribution types (loan size buckets, term length buckets, interest rate histogram, etc.). This clearly distinguishes it from sibling lending tools that likely provide aggregates or outcomes, not characteristic distributions.

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 on when to use this tool: for a single quarter's distributions, with year and quarter required together, and optional state/county/industry filters. It doesn't explicitly name alternatives or exclusions, but the emphasis on 'distributions' versus other lending tools implies the use case. It lacks an explicit 'use this instead of X' statement.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It reveals API-level requirements (vintage_from required, range limit), default behavior for vintage_to, and the nature of optional filters (2-digit FIPS, 5-digit FIPS, NAICS). This goes beyond a simple 'get data' statement, though it does not describe output layout (covered by output schema) or potential error conditions.

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 two sentences, front-loaded with the core purpose, and every clause adds value: what the tool returns, key API constraints, and filter details. No filler or redundant repetition of schema 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?

Given that an output schema exists, the description need not explain return values. It covers purpose, API constraints, and filter dimensions, making it fairly complete. Minor gaps include lack of explicit data availability range and potential error handling, but overall it is sufficient for an agent 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 0%, so the description must compensate. It explains the semantics of vintage_from/vintage_to, including the default and range constraint, and specifies exact formats for state (2-digit FIPS), county (5-digit FIPS), and industry (NAICS). This is valuable added meaning beyond the bare schema, though it could be slightly more explicit about the data type expectations for filters.

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

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

The description clearly states the tool's function: retrieving SBA 7(a) vintage cohort charge-off outcomes, including charge-off rates, maturity status, and gross charge-off amounts. This specific verb+resource+scope clearly distinguishes it from sibling lending tools like get_county_lending or get_state_lending, which focus on broader lending metrics.

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 key usage constraints: vintage_from is required, vintage_to defaults to vintage_from, and the API enforces a max range of 10 years. It also lists optional filters for state, county, and industry, providing enough context for an agent to decide when to use this tool, though it does not explicitly name alternative tools or exclusion scenarios.

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

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

With no annotations provided, the description discloses key behavioral details: it returns median plus 10th/25th/75th/90th percentiles and notes SOC format requirements. It does not mention side effects or error handling, but for a read-style data retrieval tool, this is sufficient.

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?

Four concise sentences each add unique value: purpose, SOC format, filters, and output details. No redundant or filler content.

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 has an output schema and moderate parameter count, the description covers the essential usage: SOC requirement, optional filters, and return content. It lacks explicit guidance on default behavior or parameter relationships, but is adequate for a data retrieval tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains the SOC format with an example and lists optional filters (industry, geography, year) but does not differentiate between geo, metro, and state parameters, leaving some ambiguity.

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 the tool's function with a specific verb ('Get') and resource ('wage data for a BLS occupation'). It distinguishes from sibling tools like get_county_wages by focusing on occupation-level percentiles, and the SOC format example adds clarity.

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 context that this tool is for occupation wage data with optional industry/geography/year filters. However, it does not explicitly mention alternatives or exclusionary conditions, so it stops short of full 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?

With no annotations, the description must carry the burden of behavioral disclosure. It reveals accepted ticker formats (CIK, stripped CIK, historical ticker resolution) and enumerates valid ratios, which is helpful. However, it omits behavior around invalid inputs, data coverage, or return structure beyond stating 'time series'.

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 focused sentence followed by a list of valid ratios and a brief argument note for ticker. It is efficient and front-loaded, though the ratio list could be more compact as a bulleted list.

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

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

Despite having an output schema, the description leaves significant gaps: it does not explain the 'period' parameter (annual default) or year-range parameters, nor does it clarify how the time series is keyed or what data span is available. Given 5 parameters and only 1 fully explained, the description is incomplete for an agent to invoke the tool with confidence.

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

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

Schema description coverage is 0%, so the description must compensate. It only explains the 'ticker' parameter in detail. The 'ratio' parameter is implicitly constrained by the valid ratio list, but 'period', 'to_year', and 'from_year' are completely unmentioned, leaving their meaning and defaults ambiguous.

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 'Get a single financial ratio over time' with a specific verb, resource, and scope. It distinguishes itself from sibling tools like get_ratios by emphasizing 'single' and 'over time' (time series), and provides an explicit list of valid ratios.

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 for trend analysis ('Returns a time series for trend analysis') but does not explicitly state when to prefer this over alternatives like get_ratios or get_financial_metric. No exclusions or alternative tool names are 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context: the tool computes ratios from SEC filings, and it clarifies that historical tickers like 'FB' resolve to the current entity (META). However, it does not mention data freshness, how missing or invalid data is handled, rate limits, or any authentication requirements. The read-only nature is implied but not explicitly stated.

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 exceptionally concise: one sentence states the purpose, the next identifies the data source, and then a simple args list explains the ticker formats. Every sentence earns its place. The structure front-loads the main action and then provides specific input guidance without fluff.

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 that an output schema exists, return values do not need to be described. The description is clear enough for selecting the tool, and the ticker parameter is well documented for initial invocation. However, the optional parameters (year, period, quarter) lack any semantic guidance, and there is no comparison to sibling tools to prevent mis-selection. The description is adequate for basic use but not fully complete for a robust agent.

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

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

Schema description coverage is 0%, so the description must compensate. It excels for the required 'ticker' parameter, explaining accepted formats (ticker, CIK, stripped CIK, historical ticker) with examples. However, the optional year, quarter, and period parameters are completely unexplained. The schema only provides types and defaults (e.g., period defaults to 'annual'), leaving ambiguity about valid values and their effect on the result. The description covers one key parameter thoroughly but neglects the others.

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

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

The description opens with a specific verb+resource: 'Get computed financial ratios (margins, returns, leverage, growth) for a US public company.' It clearly enumerates the ratio categories, which distinguishes it from the many sibling tools that retrieve raw financials or single metrics. The scope ('US public company') and data source ('Derived from SEC filings') add further specificity.

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 this tool is for retrieving financial ratios, but it does not explicitly state when to use it instead of nearby alternatives like get_ratio_history, get_financials, or get_financial_metric. There is no mention of exclusions, such as non-US companies or point-in-time vs. historical data. This leaves the agent to infer usage from the tool's name and description alone.

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

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

The description indicates a read-only getter and provides a parameter constraint, but offers no additional behavioral context such as data frequency, source, update cadence, or required permissions. Since there are no annotations, the description carries the full burden and falls short of disclosing potential quirks or limitations.

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 two short sentences, front-loaded with the core purpose and immediately followed by the most critical parameter constraint. No wasted words or redundant 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 regional data fetch, the description covers the required parameter but omits details about optional date parameters and the meaning of 'adjustment'. The presence of an output schema mitigates return-format concerns, but the optional parameters remain under-specified, leaving moderate gaps in overall completeness.

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 description adds explicit valid values for the 'region' parameter, which the schema does not provide. However, it leaves 'to_date', 'from_date', and 'adjustment' without any explanation, only partially compensating for the schema's lack of descriptions. The provided enum-like info is valuable but not comprehensive.

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 the action ('Get') and the resource ('regional labor market turnover data'), and specifies the scope ('one of the 4 Census regions'). This distinguishes it from sibling tools like get_state_turnover and get_industry_turnover which target different geographic or industry granularities.

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 tool is for Census-region-level data but does not explicitly contrast it with state-level or industry-level alternatives. There is no 'use when' or 'instead of' guidance, leaving the agent to infer the appropriate context from the region parameter.

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

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

With no annotations, the description carries the full burden. It discloses exactly what the tool returns (display name, category, unit, update cadence, typical lag, etc.), and the 'Get' verb implies a read-only side effect. It also mentions the data source and public domain status. However, it does not explicitly state that no mutation occurs, but that is reasonable for a 'Get' tool.

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

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

The description is two sentences, front-loaded with the purpose and return fields, followed by usage guidance and source attribution. Every sentence adds value with no redundancy.

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

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

The tool is simple (one parameter) and the description covers the input, output fields, usage flow, and data source. An output schema exists, but the description already provides the return details, making it complete for an agent to select and invoke correctly.

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

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

The schema has no description coverage (0%), but the description compensates by explaining that the metric parameter is a 'canonical name' and directs the user to explore_sba_metrics for discovery. It does not provide format examples or a list of valid names, but for a single parameter this is sufficient guidance.

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

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

The description uses a specific verb ('Get') and resource ('full definition for a single SBA 7(a) metric by canonical name'), clearly distinguishing it from sibling explore_sba_metrics which discovers metrics. It also lists concrete return fields (display name, category, unit, etc.) making the purpose 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?

The description explicitly provides usage context: 'Use explore_sba_metrics to discover canonical names.' This tells the agent how to obtain the required parameter and implies this tool is for fetching details after discovery. It clearly differentiates from the discovery 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?

With no annotations, the description carries the full burden and does a good job: it discloses the default behavior (latest quarter when no period filters), the requirement to supply both from_period and to_period for a series, the FIPS format, and the optional NAICS industry filter. It does not mention auth, rate limits, or error cases, but as a read-only public-data query tool it provides substantial meaningful 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 dense but efficient, packed with useful information across three sentences. It front-loads the purpose and metric list, then gives usage guidance and parameter details. The final source attribution is slightly extra but acceptable for context. It is not overly verbose and avoids repetition.

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

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

Given the tool has an output schema and moderate complexity, the description covers most essential context: default behavior, time-series usage, parameter formats, and the public-domain source. The main gap is the unexplained year/quarter parameters and lack of explicit alternative-tool comparisons, but overall it gives enough for an agent to invoke correctly in common scenarios.

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 description adds value by explaining fips (with examples), from_period/to_period format ('YYYY-Qq'), and the NAICS industry filter, which is crucial since schema descriptions are absent for all 6 parameters. However, it completely omits the 'year' and 'quarter' parameters present in the schema, leaving the agent uncertain whether those are alternatives or redundant. This partial coverage lowers the score.

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 a specific verb and resource: 'Get quarterly SBA 7(a) loan aggregates for a single US state' and enumerates the exact metrics returned (loan count, total amount, charge-off rate, average loan size, jobs supported). This distinguishes it from sibling tools like get_county_lending or get_industry_lending by explicitly narrowing scope to state-level SBA loans.

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

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

It provides clear usage context: without period filters it returns the latest available quarterly observation, and it instructs to 'Provide both from_period and to_period (YYYY-Qq, e.g. '2024-Q1') for a time series.' While it doesn't explicitly name sibling alternatives or conditions to avoid, the state-specific and SBA-specific framing makes it clear when to select this tool over related ones.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses key constraints: 'Total nonfarm only', 'no industry breakdown', and data availability 'from October 2021 onward'. This goes beyond the tool name and helps set expectations, though it does not describe output format or edge cases.

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 compact and front-loaded: a clear one-line purpose, followed by key constraints and a helpful parameter hint. Every sentence adds value and there is no redundant filler, making it highly efficient for an agent to parse.

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

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

The description covers the tool's unique scope and one parameter, but with no annotations and no schema descriptions, it leaves critical gaps around date range usage and adjustment options. This makes the description incomplete for a tool with 4 parameters and no structured guidance.

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 description explains only the 'fips' parameter with a concrete example, but the other three parameters (to_date, from_date, adjustment) are left undefined. Since schema description coverage is 0%, the description must compensate, and it fails to do so for 3 of 4 parameters, which is a significant gap for correctly invoking the tool.

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 the tool's function: 'Get state-level labor market turnover data' with a specific verb (get), resource (labor market turnover), and geographic scope (state-level). It distinguishes from siblings by explicitly noting 'Total nonfarm only — no industry breakdown at state level', which separates it from industry-level tools like get_industry_turnover.

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 provides clear context on when to use this tool (for state-level turnover, nonfarm total) and an implicit exclusion ('no industry breakdown at state level'), suggesting industry breakdown is handled elsewhere. However, it does not explicitly name alternative tools or state when-not-to-use, so it misses the top tier.

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

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

With no annotations, the description fully discloses key behavior: default seasonal adjustment, the 'nsa' option, handling of missing dates (latest observation), annual-only mode (M13 rows), and the included metrics (labor force participation rate, employment-population ratio). This is comprehensive for a data retrieval tool.

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

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

The description is well-structured, front-loaded with the core purpose, then details, then source/alternative. Each sentence adds value without redundancy. It is dense but not bloated.

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 moderate complexity (5 params, output schema present), the description covers all necessary context: defaults, date handling, annual averages, param formats, data source, and sibling distinction. No significant gap exists.

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

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

The input schema has 0% description coverage, but the description compensates fully: fips with examples, adjustment values ('sa'/'nsa'), date format (YYYY-MM), and annual_only semantics (M13 rows). Every parameter is explained in the description.

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

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

The description clearly states a specific verb ('Get'), a specific resource ('monthly LAUS unemployment data for a single US state'), and distinguishes from siblings by explicitly noting single-state scope. It also mentions the alternative tool for multi-state comparison.

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

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

Provides explicit when-to-use guidance, including the alternative tool 'compare_state_unemployment' for comparing multiple states. Also explains parameter usage (adjustment, dates, annual_only) with concrete examples, making the intended use cases clear.

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

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

With no annotations provided, the description carries the full burden. It does clearly indicate a read operation ('Get details'), but it provides no information on error behavior, authentication needs, rate limits, or any other side effects. The example id format adds a small amount of context, but overall it's minimal.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately states the action and resource, and the parenthetical example is useful without bloating the text.

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

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

For a simple get-by-id operation with an output schema available, the description is largely complete. It identifies the resource and how to specify it. It could mention error cases or that it returns full subscription details, but given the simplicity, the current level is adequate.

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 has no description for subscription_id and 0% coverage, so the description must compensate. It does so by giving a concrete example id ('sub_abc123'), which clarifies the expected format. This is helpful, though it doesn't explain where to find the id or any constraints.

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 the action ('Get details'), the resource ('webhook subscription'), and the scope ('one ... by id'), with an example id format. This distinguishes it from list_webhooks (which lists all) and other sibling tools.

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

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

The 'by id' phrasing clearly implies this tool is for retrieving a specific subscription when you already have its identifier. While it doesn't explicitly mention alternatives like list_webhooks, the context is clear enough for the intended use case.

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

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

With no annotations provided, the description carries the full burden. It discloses offset-based pagination ('pass page=2 for the next batch'), the server-side cap on limit (50), and what each row contains (event type, status, attempt count, timestamps). This goes beyond a simple listing and gives useful behavioral details.

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 concise sentences, each earning its place: purpose + use case, output row fields, and pagination behavior. No fluff or redundancy.

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

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

The description fully covers the tool's purpose, return contents, and pagination mechanics. With an output schema available for exact return format, the description is sufficient for an agent to select and invoke the tool correctly. It also addresses the key nuance of limit capping.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'page' semantics explicitly ('pass page=2 for the next batch') and clarifies that 'limit' is capped at 50. 'subscription_id' is self-evident from the tool name and the phrase 'for a webhook subscription'. This is adequate compensation for the missing schema descriptions.

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 'Show delivery attempts for a webhook subscription' with a specific verb and resource. It distinguishes itself from sibling tools like list_webhooks (which lists subscriptions) and replay_webhook_delivery (which replays deliveries).

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 says 'Useful for debugging' which provides clear context on when to use this tool. It does not mention explicit alternatives or exclusions, but the use case is well implied by the debugging note and the row content described.

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

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

With no annotations, the description carries the burden. It discloses that the tool returns a catalog with descriptions and links to payload schemas, which is valuable behavioral context beyond the name. It does not discuss auth or side effects, but for a list operation this is minimal and the verb 'List' implies read-only.

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: one states the action and examples, the second states the return value. Front-loaded with the verb and resource, zero wasted words, easy 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?

For a zero-parameter, simple list tool with an output schema, the description fully covers purpose, use case, and return content (catalog with descriptions and schema links). No gaps are apparent.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds context about the output (catalog of event types), which is more than enough given no parameters to document.

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 the tool lists webhook event types, with specific examples (filing.created, etc.), and distinguishes it from sibling tools like list_webhooks or get_webhook which manage actual webhook subscriptions. The verb 'list' plus the resource 'event types' makes the purpose unambiguous.

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

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

The description implies usage when setting up a webhook by showing what event types can be subscribed to. It provides clear context (before subscribing) but doesn't explicitly exclude alternatives or mention when not to use it. However, given the specificity, this is sufficient.

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

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

With no annotations, the description must convey behavioral traits. It discloses the scope ('your' subscriptions) and output columns (including active/inactive status), which adds context. However, it does not mention pagination, authentication requirements, rate limits, or side effects. The 'List' verb implies read-only, but fuller disclosure is lacking.

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 sentence that front-loads the verb and resource, then efficiently enumerates the output fields. Every word contributes value, with no redundancy or fluff.

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 zero parameters, an existing output schema, and the simple read-only nature of the operation, the description is complete. It clearly states what is returned, and no additional context is needed for safe and correct usage.

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 has zero parameters, so schema coverage is trivially 100%. No parameter explanation is needed, and the baseline for 0 parameters is 4. The description adds no parameter information, which 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 uses a specific verb ('List') and clearly identifies the resource ('webhook subscriptions'). It distinguishes from siblings like get_webhook (single) and list_webhook_deliveries by focusing on subscriptions and specifying the row contents (id, url, events, status, timestamp).

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 provides no guidance on when to use this tool versus alternatives like get_webhook or list_webhook_deliveries. It simply states what the tool does without mentioning exclusions, prerequisites, or alternative tools for related tasks.

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?

Since no annotations are provided, the description carries the full burden. It discloses the redelivery behavior and the 410 error for expired deliveries. However, it omits other behavioral aspects like idempotency, side effects, or permission requirements, which are important for a mutation tool.

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

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

The description is two sentences long and immediately front-loads the purpose. Every sentence adds value: the first states the action, the second provides usage context and a critical limitation. No wasted words.

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

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

The tool is low complexity (2 params, output schema present), and the description covers the core purpose, when to use, and a key error condition. It does not elaborate on parameter meaning or additional failure modes, but the output schema covers return values, so this is reasonably 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 0%, and the description does not compensate by explaining the parameters. Although the parameter names (subscription_id, delivery_id) are somewhat self-explanatory, the description does not clarify their relationship or requirements, leaving the agent without additional semantic 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?

The description clearly states the tool's action: 'Re-queue a past webhook delivery for redelivery.' It uses a specific verb ('re-queue') with a specific resource ('past webhook delivery'), and differentiates from sibling tools like list_webhook_deliveries and send_webhook_test by focusing on redelivery.

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 provides explicit context: 'Useful if your endpoint was temporarily down.' It also implies when not to use by mentioning the 7-day retention window and the resulting 410 error. It does not explicitly name alternative tools, but the context is sufficient for basic guidance.

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