LocalPro — Verified US Local Service Provider Data

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

Since no annotations are provided, the description fully explains behavior: returns vary with/without API key, and contact details are on the listing page. Discloses that full pricing and certifications require a key, and that some data is not returned directly.

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?

Every sentence provides unique information: purpose, authentication behavior, and availability of contact details. Front-loaded with purpose, then details. 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 no output schema, description covers returned fields at a conceptual level (business description, services, pricing, coverage, link) and distinguishes data tiers. Missing exact field names but sufficient for an agent to understand what to expect.

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

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

Schema coverage is 100%, so parameters are already documented. Description adds value by noting that niche_id must match the niche used in search_providers, providing necessary cross-tool consistency 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?

States 'Get a detailed summary of a specific verified service provider.' Clearly specifies verb (get) and resource (summary of provider), and the examples distinguish it from sibling tools like search_providers and list_* 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?

Explains when to use (to get a detailed summary) and provides context on authentication differences and where to find contact details. Does not explicitly state when not to use, but sibling tools are clearly different.

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 that cities are 'grouped by metro area where applicable' with an example, which adds useful context. However, it doesn't mention behavioral aspects like pagination, rate limits, error handling, or what the output looks like (e.g., list format, fields). For a tool with no annotations, this leaves gaps in understanding how it behaves.

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 in three sentences. The first states the purpose, the second gives usage guidelines with a sibling tool reference, and the third adds contextual details with an example. Every sentence earns its place, and 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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, usage context, and some behavioral details (grouping by metro area). However, without annotations or an output schema, it lacks information on return values, error cases, or performance characteristics, which could be helpful for an 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 100%, so the schema already documents both parameters thoroughly. The description adds marginal value by mentioning optional filtering by state abbreviation, but doesn't provide additional semantics beyond what's in the schema (e.g., how 'niche_id' relates to 'list_niches', or examples of city slugs). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'List available cities and metro areas where verified providers operate for a given niche.' It specifies the verb ('List'), resource ('cities and metro areas'), and scope ('for a given niche'), and distinguishes it from sibling tools like 'search_providers' by explaining its role in discovering valid city slugs before calling that tool.

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

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

The description provides explicit guidance on when to use this tool: 'Use this to discover valid city slugs before calling search_providers.' It names the alternative tool ('search_providers') and clarifies the workflow, making it clear this is a prerequisite step for filtering providers by location.

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 provided, but the description accurately implies a read-only list operation. It does not mention potential limitations, but given zero parameters and simple purpose, it is adequately 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?

The description is concise and front-loaded, with every sentence adding value—main action, examples, and return value importance.

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

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

No output schema, but description compensates by stating it returns niche IDs and listing example categories. Sufficient for a simple list tool with no parameters.

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?

No parameters exist, and schema coverage is 100%. Baseline 4 applies as no additional parameter information is needed.

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 lists all available service directories (niches) and provides a specific verb and resource. It distinguishes from siblings by mentioning it returns niche IDs needed for other 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?

Explicitly says it's the starting point for discovery and that returned niche IDs are needed for all other tools, providing clear when-to-use context.

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

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

No annotations are provided, so the description carries the full burden. It effectively discloses that this is a read-only operation (implied by 'List'), provides context about niche-specific taxonomies with examples, and hints at prerequisite data (niche IDs from list_niches). However, it doesn't mention potential rate limits, error conditions, or response format details, leaving some behavioral aspects uncovered.

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 usage guidance and illustrative examples. Every sentence earns its place by adding critical context without redundancy, making it efficient and well-structured for an AI agent.

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 low complexity (1 parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and behavioral context adequately. However, the lack of output schema means the description doesn't explain return values (e.g., list format, pagination), which is a minor gap in completeness for a tool that outputs data.

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

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

Schema description coverage is 100%, so the schema already fully documents the niche_id parameter. The description adds minimal value beyond the schema by reinforcing the need for valid niche IDs and giving examples ('coated-local', 'radon-local'), but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action ('List the valid service type categories') and resource ('for a given niche directory'), distinguishing it from siblings like list_niches or search_providers. It provides concrete examples (e.g., 'coated-local' has epoxy, polyaspartic) to illustrate the purpose beyond just the tool 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?

Explicitly states when to use this tool ('Use this before calling search_providers with a service_type filter to ensure you pass a valid value') and names a specific alternative (search_providers). It also implies context by noting each niche has its own taxonomy, guiding usage relative to other tools like list_niches.

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 thoroughly lists the return fields (name, rating, review count, business status, services, certifications, years in business, profile link, Google Maps URL). It also mentions coverage of major US metro areas. While it does not discuss authentication or rate limits, for a search tool these are less critical, and the output details are well specified.

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. Every sentence adds new information: first states the action and scope, second details the returned fields and usage advice. 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?

For a search tool with 4 parameters (all documented) and no output schema, the description adequately explains inputs, outputs, and usage prerequisites. It could mention whether results are paginated (limit suggests it, but no offset or next token) and default sorting, but these are minor omissions. Overall, it gives sufficient context for an AI 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 coverage is 100%, providing baseline 3. The description adds value by giving concrete examples (e.g., city slug format 'denver-co') and directing users to list_niches, list_cities, and list_service_types for valid values. It also explains the limit parameter's default and maximum. This guidance exceeds mere restatement of 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 verb 'Search for' and the resource 'verified local service providers across 10 trade categories'. It lists the categories explicitly, making the tool's purpose unmistakable. The sibling tools (get_provider, list_cities, etc.) are differentiated by their focus on retrieval of individual providers or reference data, so the search function is distinct.

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 guidance to 'Use list_niches first to get valid niche IDs, and list_service_types for valid service_type values.' This clarifies prerequisites. It also notes coverage of major US metro areas. However, it does not explicitly advise when not to use this tool (e.g., if you need a specific provider, use get_provider instead), so it misses an exclusionary case.

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