LocalPro

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

With no annotations, the description discloses important behavior: responses differ with an API key (full pricing/certifications vs summary/flag), and contact details are only on the listing page via listing_url. It does not mention error/not-found cases, but the auth-dependent behavior and data exclusions are 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?

Three sentences: purpose, return fields, and auth-dependent behavior. Each sentence earns its place, though the field list in sentence two is slightly dense. It is front-loaded with the main verb and object.

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 explains return values, API key variations, and where to find contact details, which substitutes for the missing output schema. For a read tool with two parameters, this is a complete self-contained description.

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 describes both parameters with examples and 100% coverage. The description adds no extra parameter semantics, so the baseline score 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 ('Get') and resource ('a specific verified service provider'), clearly indicating a single-provider lookup. It distinguishes itself from sibling tools like search_providers by emphasizing specificity and detail.

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 word 'specific' implies this tool is used after identifying a provider (e.g., via search_providers), and the schema reinforces matching niche_id. However, the description does not explicitly name alternatives or state 'use this instead of search_providers', so it is clear but not fully 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 full burden. It discloses key behavioral traits: cities are grouped by metro area (e.g., 'minneapolis-mn' covers suburbs), and the list is limited to areas where verified providers operate. It does not cover output format or pagination, but the grouping and verification details add value beyond the schema.

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

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

The description is three sentences, each with a clear purpose: state the operation, indicate usage, and explain grouping/filtering. It is front-loaded with the main purpose and contains no filler.

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

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

For a simple list tool with 2 parameters and no output schema, the description covers the essential context: what it lists, how to use it (before search_providers), and key output characteristics (city slugs, grouping). It could say more about return format or error handling, but given the low complexity, it is adequately 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 input schema already describes both parameters fully (100% coverage), so baseline is 3. The description adds little beyond noting that niche_id comes from list_niches (already in schema) and that state filtering is optional. It provides an example of a city slug in the description, but that's related to output rather than parameter semantics.

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

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

The description explicitly states the tool's function: 'List available cities and metro areas where verified providers operate for a given niche.' It uses a specific verb ('list') and resource ('cities and metro areas'), and differentiates from sibling search_providers by stating its role in discovering valid city slugs before that call.

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: 'Use this to discover valid city slugs before calling search_providers.' This tells the agent when to use the tool relative to a sibling. It does not explicitly mention when not to use or list alternatives, so it lacks full exclusion guidance, but the direction is 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 full burden. It discloses that the tool lists all available directories, lists example categories, and returns niche IDs. While it does not explicitly state 'read-only,' the verb 'list' implies a safe read operation. It adds value by explaining the output's purpose, though it omits details like pagination or exact response structure.

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

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

The description is appropriately sized, with a clear opening sentence followed by useful context. The list of categories is lengthy but provides concrete examples, making it informative rather than wasteful. It is well-structured and 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 list tool with no parameters and no output schema, the description is complete: it states the purpose, gives examples of content, and mentions the return value (niche IDs). It could be more precise about the return format, but given the simplicity, it adequately covers what the agent needs to know.

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 schema is empty, so there are no parameter semantics to document. Per the baseline for 0 parameters, a score of 4 is appropriate; the description adds context about what the IDs are for, which indirectly aids understanding of the (absent) 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 function with a specific verb and resource: 'List all available service directories in the LocalPro network.' It also explains its role as the starting point and enumerates specific categories, which distinguishes it from sibling tools like list_cities and search_providers.

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 usage guidance is provided: 'This is the starting point for discovering what categories... are available' and 'Returns niche IDs needed for all other tools.' This tells the agent when to use this tool versus others and establishes it as a prerequisite.

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 that each niche has its own taxonomy and provides concrete examples of niches and their service types, which adds behavioral context beyond just the action. However, it doesn't specify behavior for invalid niche IDs or return format, a minor 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?

Exactly three sentences: purpose, usage context, and examples. Front-loaded with the main action, no filler.

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

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

For a simple one-parameter listing tool with no output schema, the description covers purpose, usage guidance, and taxonomy variation. It references sibling tools appropriately. The only missing detail is the exact return format (e.g., array of strings), but that is implied.

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

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

The schema already documents niche_id with examples and references list_niches (100% coverage). The tool description adds context by explaining the parameter's purpose in validating service_type filters and giving taxonomy examples, enhancing the schema semantics.

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

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

The description states a specific verb ('List') and resource ('valid service type categories for a given niche directory'), clearly distinguishing it from siblings like list_niches (niches) and search_providers (providers). It also mentions 'service type categories' which is unique to this 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?

Explicitly instructs to use before search_providers with a service_type filter to ensure valid values. This provides a clear when-to-use and ties to the sibling tool, and implies it is not for general provider search.

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 details the returned fields (name, rating, certifications, etc.), Google Maps URL availability, and geographic coverage, which is good context. It doesn't explicitly state read-only/no-side-effect status, but as a 'search' tool, the semantics imply a safe query; a 3 reflects sufficient but not exhaustive 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 a single paragraph with purposeful front-loading: it starts with the action and scope, lists categories, then return fields, coverage, and prerequisites. Every sentence adds distinct information 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?

Given the tool's moderate complexity (4 params, no output schema, no annotations), the description provides strong coverage: return fields, niche categories, geographic scope, and prerequisite tool usage. Omissions like sorting, pagination, and city-optional behavior are minor for a search tool, making this fairly 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 descriptions already cover all 4 parameters at 100%, so baseline is 3. The description adds context that niche_id and service_type are validated via list_niches/list_service_types, reinforcing the schema's guidance. It doesn't add syntax details beyond that, so a 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 opens with 'Search for verified local service providers' and enumerates 10 specific trade categories, clearly identifying the action and resource. It also differentiates from siblings by framing this as the search tool while list_niches/list_service_types are referenced as prerequisite lookup 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 instructs to use list_niches first and list_service_types for valid values, giving clear prerequisite workflow. It does not explicitly state exclusions or when to prefer get_provider, but the context is clear for a search scenario.

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