companies

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

With no annotations provided, the description carries the transparency burden. It discloses the output (counts per age bucket) and optional state filter. However, it omits important behavioral details such as the underlying data scope (all businesses vs. private entities), the default behavior when no state is supplied, and any restrictions on state values beyond the schema's examples.

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 uses compact hyphenated ranges to list age buckets. Every word contributes essential information, making it highly concise and well-structured.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers the essential output structure (counts per age bucket) and the filter option. It misses a few contextual details, such as the population being measured and behavior without a state filter, preventing a perfect score. Overall, it is nearly 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?

The single parameter 'state' has 100% schema description coverage, stating 'Filter by state: FL, NY'. The tool description only repeats this with 'Optionally filter by state,' adding no new semantics, default behavior, or formatting guidance. Per rubric, a baseline of 3 is appropriate when the schema fully documents 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's purpose with a specific verb 'Get' and resource 'business age distribution', enumerating exact age buckets (0-4, 5-9, ..., 40+). This distinguishes it from sibling tools like private_stats and private_type_breakdown by specifying the aggregation type and granularity.

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 (to retrieve age distribution data) and mentions the optional state filter, implying the main use case. It does not explicitly exclude alternatives, but the focused scope makes its usage apparent. No explicit alternative tool references are given, 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, the description carries the full burden of behavioral disclosure. It fails to explain pagination (despite offset/limit in schema), how multiple criteria combine (AND vs OR), or what the response format looks like. It also introduces a 'naics filter' not present in the schema, which is misleading and undermines transparency.

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, with the first two being concise and front-loaded. The third sentence provides NAICS examples, but it refers to a non-existent parameter, making it not just wasteful but misleading. The overall length is appropriate, but the misinformation reduces effectiveness.

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 9-parameter list tool with no output schema and no annotations, the description is incomplete. It does not mention pagination behavior, how criteria combine, or any return-value details. The NAICS discrepancy is a significant gap that could cause incorrect usage. Sibling context is only addressed by a vague phrase, not with concrete alternatives.

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 100% description coverage, so the baseline is 3; however, the description adds misleading information by instructing users to 'ask for an industry with the naics filter' and providing example codes, yet no such parameter exists. This actively harms parameter understanding. The description does not clarify relationships between min_age/max_age or other constraints, so it adds little value beyond the schema.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Build a list of companies matching criteria.' It also distinguishes from sibling tools by saying 'rather than looking one up,' which differentiates it from lookup-style tools. However, it mentions 'industry (NAICS)' as a criterion and later references a 'naics filter' that does not exist in the schema, causing slight confusion about what the tool actually accepts.

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: 'Use it for prospecting, market sizing, or finding every business of a kind in a place.' It also implicitly contrasts with lookup tools by saying 'rather than looking one up,' offering a hint about when not to use it. However, it does not explicitly name sibling tools or provide exclusionary guidance beyond this contrast.

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 dual search modes, the restriction to executive-level titles, and the conceptual query semantics. It does not mention return format or data caveats, but the core behavior is clearly explained. A 4 is appropriate given the lack of annotations.

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

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

The description is two sentences, front-loaded with the primary purpose and immediately followed by usage guidance and a sibling alternative. Every word earns its place; there is 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?

Given only 2 parameters, no output schema, and no annotations, the description provides enough context for selection and broad invocation, including role restrictions and sibling comparison. It lacks information about the return shape, but that is a minor gap for a search tool with a clear purpose. A 4 is reasonable.

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

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

Schema coverage is 100%, which normally sets a baseline of 3. However, the description introduces an ambiguity: 'find the chief executive behind a company' implies the `name` parameter may accept a company name, but the schema says 'CEO/president name to search.' The description does not explain how a single `name` parameter handles both company and executive lookups, which could lead to incorrect invocation.

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 starts with a clear, specific verb phrase: 'Find the chief executive, president, chairman or manager behind a company, or find every company a named executive runs.' It clearly defines the tool's dual scope and distinguishes it from sibling tools via the executive-level restriction.

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 the tool ('when the question is "who is actually in charge here"') and exactly when not to, naming the alternative: 'use private_officer_search for any role including directors and secretaries.' This is ideal 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 provided, the description carries the full burden of behavioral disclosure. It discloses the authoritative source ('record a state government actually holds') and warns about mirrors providing stale status/wrong agent. However, it does not mention error conditions, rate limits, or response format beyond contents, making it solid 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 a tight two-sentence structure: the first sentence lists the payload and purpose, the second sentence provides the authoritative use case. No filler or repetition exists, and the key information is front-loaded.

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

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

Given the absence of an output schema, the description serves as the sole guide to return values and does so thoroughly by listing all major data categories. It also provides a situational rationale (settling conflicting web data) that makes the tool's role clear in a workflow with siblings. The description 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 100% — both parameters (state, state_id) have descriptive comments in the schema. The tool description adds nothing specific about parameter usage beyond what the schema already says, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: retrieving the full official state record for an already-identified company, and enumerates specific contents (status, incorporation date, EIN, registered agent, officers, addresses, filing history). It distinguishes itself from sibling search tools by emphasizing that identification has already happened.

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 for when to use the tool: 'You have already identified a company and now need the full official record' and 'use it to settle questions that web sources disagree about'. It implies not for search/discovery, but does not explicitly name alternatives or exclusions, 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?

No annotations are provided, so the description carries the full burden, but it only states the high-level function. It does not disclose whether the tool is read-only, how results are sorted, default limit behavior, or what the return structure looks like. This is a significant transparency gap.

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

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

Two sentences with no unnecessary words. The key information is front-loaded, and the structure is 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 simple 3-parameter tool with no annotations and no output schema, the description covers the basic purpose but omits expected output details and behavioral nuances. It is minimally viable but has clear gaps.

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

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

Schema description coverage is 100%, so all parameters are already documented. The description adds no new meaning beyond restating the group_by options, which the schema already lists. Baseline of 3 is appropriate.

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

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

Clearly states the tool provides geographic distribution of private businesses and lists grouping dimensions (city, zip, county, state). This distinguishes it from sibling tools like private_age_distribution and private_type_breakdown.

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

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

Implies the tool is used for geographic analysis ('Shows where businesses are concentrated') but does not explicitly contrast with alternatives or specify when to choose this over other distribution tools. Clear context is present, so it earns a 4.

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 the data coverage ('Covers 21.2M officer records') and the search scope (officer/director/registered agent), but does not mention result shape, pagination, or any limitations beyond the coverage count. This is serviceable but not rich.

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 plus a coverage count, front-loaded with the primary purpose. Every sentence adds value: purpose, use cases, and data scale. No unnecessary filler.

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

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

With 4 parameters and no output schema, the description provides enough context for a search tool: purpose, supported roles, use cases, and data breadth. It doesn't explain return format, but that's not expected when no output schema exists. Lacks only explicit alternative 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?

Schema description coverage is 100%, so parameters are already well-documented. The description adds no additional parameter-level detail beyond what the schema provides, which is acceptable and warrants the baseline 3.

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

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

The description opens with a specific verb and resource: 'Find which companies a named person is an officer, director or registered agent of.' This clearly differentiates from the sibling private_ceo_search by covering officer/director/agent roles, not just CEO.

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 concrete usage contexts: 'check whether a counterparty is who they claim', 'map the other entities behind one operator', 'find every company a person controls before signing with any of them.' While it doesn't explicitly state when not to use it or name alternatives, the scenarios are strong enough to guide an agent on when to invoke this 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 transparency burden. It discloses that results reflect filing statements rather than legal ownership/control and qualifies the interpretation with 'usually.' This is strong, though it doesn't comment on data freshness 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 three sentences: first defines the match criterion, second explains its meaning, and third gives use cases plus a caveat. Every sentence earns its place, and the key behavior 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?

The description provides purpose, interpretation, usage, and an important caveat. With no output schema, it doesn't describe the return structure, but for a search tool this is sufficient to select and 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?

All 6 parameters have descriptions in the schema (100% coverage). The description adds no extra parameter-level meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('find') plus a precise resource and filter condition ('businesses where an officer is also the registered agent'). This clearly distinguishes it from sibling tools like private_officer_search or private_search by focusing on the owner-operated signal.

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 lists two use cases: building acquisition target lists and judging supplier dependence on one person. However, it doesn't mention when not to use the tool or offer alternatives, 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?

No annotations are present, so the description carries the full burden. It discloses key behavioral outputs (confidence score, ambiguity flag, ranked alternatives) and the decision rule for low confidence. However, it does not explicitly state the tool is read-only or mention any side effects, but the outputs and confidence-based behavior are well covered.

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: the first states the core action and output, the second gives the use case, the third provides alternative handling and a rule. Each sentence earns its place, front-loading the main action and keeping the description compact.

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

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

With no output schema, the description explains the return elements (confidence score, ambiguity flag, ranked alternatives) and how to act on them. It also mentions optional corroborating parameters via the schema, making the tool understandable and actionable for an agent without requiring additional context.

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 already provides 100% coverage with descriptive text for all three parameters ('Business name as you have it, however messy', 'City, used as a corroborating signal', 'Two-letter state code to narrow the search'). The description reinforces 'messy or partial' acceptance but does not add new parameter details beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool's purpose: resolving messy business names to a single canonical government record. It uses a specific verb ('resolve') and distinct resource ('business name to canonical government record'), and distinguishes from sibling private_search by stating a preference for identification over browsing.

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

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

Explicit when-to-use guidance is provided: 'when you have a company name from a document, email or user message and need to identify the actual registered entity.' It also names the alternative (private_search) and specifies when to use this tool instead. The confidence threshold behavior (show alternatives below 0.6) adds operational 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 present, so the description carries the full burden. It clearly discloses a key behavioral quirk: the search matches names only, not industry classifications, with the 'roofing' example. It also notes full-text ranked search and data coverage. This is substantial behavioral context, though it doesn't detail response shape 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?

Three sentences with no filler. The first sentence gives purpose, the second gives usage boundaries, and the third explains the name-matching caveat. It's appropriately sized for the tool's complexity, though slightly more verbose than strictly necessary.

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

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

The description covers what the tool does, when to use it, and a major limitation. It lacks an explicit mention of result fields or pagination, but given the tool's simplicity, it is adequate. The reference to a potentially unavailable private_list tool is a minor gap that prevents a perfect score.

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

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

The schema already provides full descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds high-level context about ranking and name-matching but doesn't add specific syntax or format details for the parameters. It does clarify that 'state' covers 56 jurisdictions via the overall description, which is a minor enhancement.

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's opening phrase 'Find US businesses by name when you do not yet know which one you want' clearly identifies a name-search tool with a specific use case. It also distinguishes from private_resolve by contrasting browsing candidates vs. identifying a specific company. The scale (30.6M entities, 56 registries) adds 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?

Explicitly states when to use (when unsure which business, to browse candidates or check existence) and when not to use (to identify one specific company → private_resolve; for industry-based search → private_list). However, private_list is not listed as a sibling tool, which could mislead an agent if that tool doesn't exist.

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 key behavioral traits: returns per-state counts and source, and highlights the important caveat that some states (California, Illinois) only hold SAM.gov registrants with no officer data. This goes beyond a simple 'returns stats' statement.

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 main purpose, and each sentence adds value: purpose, output details, and usage warning. 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?

For a no-param tool with no output schema, the description explains the purpose, the returned data (per-state counts and source), and the practical implication for data reliability. It could optionally mention whether all states are included or only used ones, but overall it is complete for the tool's simplicity.

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 0 parameters, and the schema is empty with 100% coverage. Baseline for 0 params is 4. The description doesn't need to explain parameter semantics, and it doesn't, focusing instead on the output 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 checks dataset coverage by returning per-state record counts and government source. It distinguishes itself from sibling tools like private_search and private_officer_search by focusing on dataset-level statistics rather than individual records.

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 instructs when to use the tool: 'Read this before asking who runs a company in a state you have not used before.' It also warns about states with no officer data. It doesn't mention exclusions or alternatives but gives strong contextual 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 provided, the description must carry the burden of disclosing behavioral traits. It explains what the tool counts (entity types) and notes the optional state filter, but does not mention return format, whether counts are current, or if the data spans all states by default. It is not misleading, just minimally transparent.

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

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

One well-structured sentence that front-loads the core purpose with an em dash, then provides examples and the optional filter. No wasted words, every part 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?

Given the low complexity (one optional parameter, no output schema), the description is complete enough to allow correct invocation. It names representative entity types and the filter option, which is sufficient for an agent to choose and use the tool.

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

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

Schema description coverage is 100% for the single 'state' parameter, and the description repeats the optional filter but adds no syntax or format details beyond the schema. Baseline 3 is appropriate because the schema already documents the parameter adequately.

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 provides an entity type breakdown with counts (e.g., domestic profit corps, LLCs, LPs), which distinguishes it from sibling tools like private_geography (geographic breakdown) and private_age_distribution (age distribution). The verb 'breakdown' plus resource 'entity type' is specific and 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 gives clear context for when to use the tool (when a breakdown by entity type is needed) and notes the optional state filter. It does not explicitly exclude alternatives or name sibling tools, but for such a simple query tool the usage is evident.

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