Bezal — Local Business Intelligence for AI Agents

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

No annotations are provided, so the description carries full burden. It discloses the 'best-effort' nature and calendar dependency, which are useful behavioral traits. However, it lacks details on permissions, rate limits, error handling, or what 'availability' means (e.g., slots, capacity). For a tool with no annotations, this leaves significant gaps in understanding its 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 two concise sentences with zero waste. The first sentence states the purpose, and the second adds crucial behavioral context. It's front-loaded and efficiently structured, making it easy 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?

Given no annotations and no output schema, the description provides basic purpose and limitations but lacks details on return values, error cases, or deeper behavioral context. For a tool checking availability—which could involve complex logic—the description is minimally adequate but leaves gaps in understanding what 'availability' entails or how results are structured.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters (business_id as UUID, date as ISO format). The description doesn't add any parameter-specific semantics beyond what the schema provides, such as explaining how these inputs affect availability checking. With high schema coverage, 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 purpose: 'Check if a business has availability on a specific date using their Bezal calendar.' It specifies the verb ('check'), resource ('business availability'), and mechanism ('Bezal calendar'). However, it doesn't explicitly differentiate from siblings like 'request_service' or 'submit_quote_request' which might also involve availability checking, keeping it from a perfect score.

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

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

The description provides some usage context: 'Best-effort — only works for businesses that use the calendar feature.' This implies when to use (for businesses with calendar feature) and hints at limitations, but doesn't explicitly state when not to use or name alternatives among siblings. The guidance is 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?

No annotations are provided, so the description carries the full burden. It mentions what is compared (ratings, services, BezalRank, profile status) but does not disclose behavioral traits such as whether this is a read-only operation, any rate limits, authentication requirements, or what the output format looks like. The description is functional but lacks operational 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 a single, efficient sentence with zero waste. It front-loads the key action ('Compare up to 5 businesses') and specifies the comparison dimensions clearly, making it easy to scan and understand.

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 annotations and no output schema, the description adequately covers the purpose and parameters but lacks details on behavioral aspects and output. For a tool with 1 parameter and high schema coverage, it is minimally viable but could benefit from more context on usage and results.

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

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

Schema description coverage is 100%, so the schema already documents the 'business_ids' parameter (array of UUIDs, min 1, max 5). The description adds marginal value by implying the parameter is for comparison, but does not provide additional semantics beyond what the schema specifies. Baseline 3 is appropriate when 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 ('Compare') and resource ('businesses'), and specifies the scope ('up to 5 businesses side-by-side on ratings, services, BezalRank, and profile status'). It distinguishes from siblings like 'get_business' (single business) or 'search_businesses' (searching rather than comparing).

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 comparing multiple businesses, but does not explicitly state when to use this tool versus alternatives like 'get_business' for single businesses or 'search_businesses' for broader searches. No exclusions or prerequisites 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 provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') but does not address permissions, rate limits, error handling, or response format. The description adds basic context about what data is retrieved but lacks critical behavioral traits needed for safe and effective use.

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, efficient sentence that front-loads the core purpose and includes specific data elements. There is no wasted language, and it directly conveys essential information without redundancy, 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 (1 parameter, 100% schema coverage, no output schema), the description is adequate but has gaps. It specifies what data is retrieved but does not cover behavioral aspects like permissions or error handling. With no annotations and no output schema, the description should provide more context to fully guide usage, but it meets minimum viability for a basic 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?

The input schema has 100% description coverage, with the 'id' parameter well-documented as a UUID for business lookup. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or constraints. Baseline score of 3 is appropriate as the schema adequately covers 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 clearly states the verb ('Get') and resource ('full profile for a specific business'), specifying the scope with 'including contact info, services, ratings, and hours'. However, it does not explicitly differentiate from sibling tools like 'get_provider_details' or 'search_businesses', which might retrieve similar or overlapping data, leaving some ambiguity in purpose distinction.

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 such as 'search_businesses' or 'get_provider_details'. It implies usage for retrieving a full profile given a specific business ID, but lacks explicit context, prerequisites, or exclusions, offering minimal assistance in tool selection.

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 adds valuable context that 'Fields returned depend on the provider's tier,' explaining variable response schemas. However, it omits safety profile (read-only vs. destructive), error handling (404 behavior), and whether this operation has 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 two-sentence structure is optimally efficient: the first sentence front-loads the core purpose, and the second sentence earns its place by disclosing the tier-dependent field variation. No words are wasted.

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 (single required UUID parameter) and 100% schema coverage, the description adequately covers the functional scope. It appropriately notes the variable output nature despite lacking an output schema, though it could enhance completeness by mentioning error cases or authentication requirements.

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

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

Schema description coverage is 100%, with the 'business_id' parameter already well-documented as 'The UUID of the business to look up.' The description's phrase 'by its ID' merely echoes this without adding syntax, format constraints, or examples beyond what the schema's regex pattern already provides.

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

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

The description clearly states the verb ('Get details'), resource ('business provider'), and key constraint ('by its ID'), which effectively distinguishes it from the sibling 'search_providers' that likely queries rather than lookups by specific identifier.

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 siblings like 'search_providers' (presumably for finding providers without an ID) or prerequisites like needing to obtain the ID first. Agents must infer usage from the parameter name 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?

No annotations are provided, so the description carries the full burden. It mentions the types of reviews included (Bezal Verified and Google rating), which adds some context beyond basic retrieval. However, it lacks details on permissions, rate limits, pagination, or what happens if no reviews exist. For a read operation with no annotation coverage, this is insufficient.

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, efficient sentence that front-loads the core purpose and includes key details (review types). There's no wasted verbiage or redundancy, 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 no annotations, no output schema, and a simple input schema, the description is minimally adequate. It covers the purpose and review types but lacks behavioral details like response format or error handling. For a tool with 2 parameters and no structured safety hints, it should do more to be complete.

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

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

Schema description coverage is 100%, with clear documentation for both parameters (business_id as a UUID and limit with default and bounds). The description adds no parameter-specific information beyond what the schema provides, such as examples or additional constraints. 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 verb 'Get' and the resource 'reviews for a specific business', including the specific types 'Bezal Verified reviews and Google rating'. It distinguishes from siblings like 'get_business' or 'search_businesses' by focusing on reviews rather than business details or listings. However, it doesn't explicitly contrast with other review-related tools if any existed, keeping it at a 4.

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. It doesn't mention prerequisites, exclusions, or compare with sibling tools like 'search_businesses' that might also return reviews. There's only an implied context of needing reviews for a known business, but no explicit usage instructions.

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

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

No annotations are provided, so the description carries full burden. It discloses the fallback behavior (returns services list if no priced catalog), which is useful. However, it doesn't mention other behavioral traits like whether it's read-only, requires authentication, has rate limits, or what the output format looks like. For a tool with no annotations, this leaves significant 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 two concise sentences with zero waste. The first sentence states the core purpose, and the second adds important behavioral context (fallback). It's front-loaded and appropriately sized for a simple tool.

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 minimally adequate. It covers the purpose and a key behavioral trait (fallback), but lacks details on output format, error handling, or prerequisites. Without annotations or output schema, more context would be helpful for an agent to use it effectively.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter (business_id as a UUID). The description adds no parameter-specific semantics beyond implying business_id is used to fetch services/pricing. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra details like format examples or 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 tool's purpose: 'Get services and pricing for a specific business' specifies the verb (get), resource (services and pricing), and scope (for a specific business). It distinguishes from siblings like 'get_business' or 'search_businesses' by focusing on services/pricing. However, it doesn't explicitly contrast with 'list_categories' or 'search_by_service', so it's not a perfect 5.

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

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

The description provides implied usage guidance: it suggests using this tool when you need services/pricing for a specific business (via business_id). The fallback behavior ('Falls back to the services list if no priced catalog exists') gives some context on when it might return different data. However, it lacks explicit when-not-to-use advice or named alternatives among siblings, so it's not fully directive.

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, description carries full behavioral burden. Effectively discloses return format ('category names and slugs') and sort order ('alphabetically'), which compensates for missing output_schema. Does not mention pagination, auth requirements, or rate limits, but covers the essential behavior for a zero-parameter 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?

Two sentences with zero waste. First sentence defines operation and scope; second sentence discloses return values and sorting. Front-loaded with the essential action (List) and appropriately sized for tool complexity.

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?

Appropriately complete for a low-complexity tool. Compensates for missing output_schema by describing return structure. Mentions domain context ('Bezalph directory'). Could explicitly state 'no parameters required' for absolute clarity, but sufficient for agent 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?

Input schema has 0 parameters with 100% coverage. As per guidelines, 0 params warrants baseline score of 4. Description correctly omits parameter discussion since none exist, and the empty schema is self-documenting.

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 uses specific verb 'List' with specific resource 'business categories' and scope 'Bezalph directory'. Clearly distinguishes from siblings: get_provider_details (specific entity), search_providers (provider search), and submit_quote_request (write operation).

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 implied usage context ('available business categories') but lacks explicit when-to-use guidance (e.g., 'use before search_providers to obtain valid category slugs') or exclusions. Agent must infer this is a catalog/discovery tool vs. the action-oriented 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 states the tool submits a request but does not explain what happens after submission (e.g., confirmation, notifications, or error handling), whether it requires authentication, rate limits, or if it's idempotent. This leaves significant gaps in understanding the tool's behavior beyond the basic action.

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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the core action and target, making it easy to understand at a glance, and every part of the sentence contributes directly to the tool's definition.

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 complexity of submitting a service request (a mutation with no output schema and no annotations), the description is insufficient. It does not cover behavioral aspects like what the tool returns, error conditions, or side effects, and with no output schema, the agent lacks guidance on response handling. This leaves critical gaps for effective tool use.

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 100% description coverage, so parameters are well-documented in the schema itself. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. However, since schema coverage is high, the baseline score of 3 is appropriate as the schema handles 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 action ('Submit a service request') and the target ('to a business on behalf of a consumer'), providing a specific verb and resource. However, it does not differentiate this tool from its sibling 'submit_quote_request', which might have overlapping functionality, leaving some ambiguity about when to use one versus the other.

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 offers no guidance on when to use this tool versus alternatives like 'submit_quote_request' or other sibling tools. It lacks context about prerequisites, such as needing to identify a business first using tools like 'get_business' or 'search_businesses', and does not specify any exclusions or conditions for usage.

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 full burden for behavioral disclosure. It states the search scope and dataset size, but lacks critical details: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, or what the output format looks like (no output schema exists). For a search tool with 5 parameters, this is a significant gap in 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, efficient sentence with zero waste. It front-loads the core purpose ('Search 47,000+ local business profiles') and immediately specifies the search dimensions. Every word earns its place, making it easy for an agent to parse quickly.

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 complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error conditions, or behavioral constraints. While the schema covers parameters well, the lack of output schema means the description should ideally hint at result structure, but it doesn't. For a search tool, this leaves the agent uncertain about 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 description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema—it mentions search by 'name, category, or location' which aligns with 'query', 'category', 'city/state' parameters, but doesn't provide additional syntax, format, or interaction details. Baseline 3 is appropriate when 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 action ('Search') and resource ('47,000+ local business profiles') with specific search criteria ('by name, category, or location'). It distinguishes from siblings like 'get_business' (singular retrieval) and 'search_by_service' (different search dimension), though not explicitly. However, it doesn't fully differentiate from 'search_providers' which might overlap in functionality.

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 'search_by_service' or 'search_providers'. It mentions search criteria but doesn't specify prerequisites, exclusions, or comparative contexts with sibling tools, leaving the agent to infer usage based on parameter names 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for searching, implying a read-only operation, but lacks details on permissions, rate limits, pagination, or error handling. The phrase 'city-level matching' hints at geographic scope but doesn't clarify behavioral traits like result format 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 extremely concise with two short sentences: 'Search for businesses in a specific city, optionally filtered by category. City-level matching.' Every word earns its place, and it's front-loaded with the core purpose. There's no wasted verbiage 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?

Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and scope but lacks behavioral details, usage guidelines relative to siblings, and output information. It's minimally viable but leaves clear gaps for an AI agent to infer 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?

Schema description coverage is 100%, so the schema already documents all parameters (city, limit, state, category). The description adds marginal value by mentioning optional filtering by category and emphasizing city-level matching, but doesn't provide additional syntax, format, or usage details beyond what the schema specifies. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Search for businesses in a specific city, optionally filtered by category.' It specifies the verb ('search'), resource ('businesses'), and scope ('city-level matching'). However, it doesn't explicitly differentiate from sibling tools like 'search_businesses' or 'search_by_service', which prevents a perfect score.

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

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

The description provides minimal guidance: it mentions optional filtering by category and emphasizes 'city-level matching,' but offers no explicit advice on when to use this tool versus alternatives like 'search_businesses' or 'search_by_service.' There's no mention of prerequisites, exclusions, or comparative contexts with sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It mentions the tool 'finds businesses' and specifies it matches against 'services array', which adds some behavioral context. However, it lacks details on permissions, rate limits, or response format, leaving gaps in transparency for a search 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 front-loaded with the core purpose, followed by a usage guideline and example, all in two concise sentences with no wasted words. Each sentence adds clear value, making it efficient 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 no annotations and no output schema, the description adequately covers the tool's purpose and usage but lacks details on behavioral traits like response format or error handling. It compensates somewhat with context on parameter usage, but for a search tool with two parameters, more completeness would be beneficial.

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. The description adds marginal value by implying 'service_type' is an exact match and 'location' is optional, but does not provide additional syntax or format details beyond what the schema specifies, meeting the baseline for high coverage.

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

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

The description clearly states the tool's purpose with a specific verb ('Find') and resource ('businesses'), and distinguishes it from sibling tools by specifying it's for searching by 'exact service' rather than category, which differentiates it from tools like 'list_categories' or 'search_businesses' that might use broader terms.

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 ('when you know the exact service rather than the category') and includes an example ('Drain cleaning' vs. 'plumbing'), which helps differentiate it from alternatives. However, it does not explicitly name sibling tools as alternatives or state when not to use it, keeping it from a perfect score.

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, so description carries full burden. Excellently discloses tier-gating behavior ('basic listing for free providers, full contact details for paid tiers'), explaining variable response content. However, missing rate limits, authentication requirements, or error handling behavior.

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

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

Two sentences with zero waste. Front-loaded with core action. Second sentence earns its place by describing return behavior (critical given no output schema exists). No redundancy with structured fields.

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

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

With no output schema, the description compensates by explaining the tier-gated response structure. All 4 parameters are optional filters; description implies filtering by 'by category...' construction. Could improve by noting all parameters are optional.

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 100% description coverage (limit, query, category, location all well-documented with types/ranges/examples), establishing baseline 3. Description mentions 'category, location, or keyword' which maps to parameters but adds minimal semantic value beyond schema definitions.

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?

Clear verb (Search) and specific resource (Bezal's verified business directory). Lists search dimensions (category, location, keyword). However, it does not explicitly differentiate from sibling 'get_provider_details' (which likely retrieves specific records by ID rather than searching/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?

No explicit guidance on when to use this tool versus 'get_provider_details' or other siblings. Lacks prerequisites (e.g., 'use list_categories to see valid categories first') or exclusion criteria. The phrase 'Search... by' implies capability but not strategic usage.

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 notes the agent acts 'on behalf of a user' but fails to disclose side effects (e.g., does this send an email to the business?), success indicators, rate limits, or whether the request creates a persistent record/ticket.

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

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

Two compact sentences with zero filler. The first establishes purpose; the second lists required data. Every word earns its place and the most critical information (the action) 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?

Input specification is complete via schema+description combination, but for a mutation tool lacking output schema and annotations, the description inadequately covers behavioral outcomes (what happens after submission, error scenarios, confirmation methods).

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%, establishing baseline 3. The description groups seeker_name, seeker_email, and message under 'seeker' semantics, adding conceptual clarity. It omits business_id, but the schema fully documents all four parameters, so the description's role is appropriately supplemental.

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 specific verb 'Submit' with clear resource 'quote request' and target 'business provider'. While it clearly distinguishes from read-only siblings (get/list/search) by virtue of being the only mutation operation, it does not explicitly name or contrast with them.

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 states data requirements ('Requires...') but provides no guidance on when to invoke this tool versus the discovery siblings (search_providers/get_provider_details), nor does it mention prerequisites like needing to identify a valid business_id first.

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