Bezal — Local Business Intelligence for AI Agents

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

With no annotations, the description carries the full burden. It honestly discloses two key behavioral limitations: hours are only available for paid-plan providers, and the tool is unaware of bookings. This is valuable context beyond the schema, though it does not describe the exact response structure beyond the 'open' field.

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 core action is front-loaded, followed by the critical plan limitation and the booking caveat. Every sentence provides necessary information for correct use.

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

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

For a simple two-parameter lookup with no output schema, the description covers the essential context: what the check is based on, when the result is unreliable, and how to interpret the outcome. It could additionally state the full expected output shape, but this is a minor gap.

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 the two parameters are already fully documented with formats and patterns. The description references 'a date' and 'the business' generically but adds no parameter-specific semantics beyond what the schema provides, matching the baseline of 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 uses a specific verb and resource ('Check whether a business is open on a date') and adds the important scoping detail 'based on its posted opening hours'. It is clearly distinct from sibling tools like get_business, but it does not explicitly name or contrast an alternative, so it stops short of full sibling differentiation.

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 results are reliable (paid Bezal plan) and when they are not (other listings return 'unknown'), plus a warning that it does not account for bookings. It implies usage boundaries but does not explicitly name a fallback or alternative tool, so it earns a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains conditional fields (phone, website, etc. only for paid plans; description only for Business/Premium) and the inclusion of quote_request_url. This gives the agent a clear picture of what data to expect based on plan type, which is valuable 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 two sentences, front-loaded with the primary purpose. The second sentence is dense but necessary to disclose conditional fields. It is concise without being under-specified, though the long second sentence could be slightly reorganized for readability.

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 comparison tool with a single parameter and no output schema, the description adequately explains the parameter constraints, the fields returned, and conditional availability. It does not explicitly describe the output format, but that is not critical for invocation. The description is sufficient for an agent to understand what the tool returns and how to use it.

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 has a description for business_ids ('Array of business UUIDs to compare') and enforces maxItems=5. The tool description adds context about what the comparison involves but does not add new parameter-specific semantics beyond what the schema provides. Baseline 3 is appropriate given 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 verb 'Compare' and the resource 'businesses', and specifies the scope (up to 5) and the fields included. It distinguishes itself from siblings like get_business (single) and search_businesses (listing) by its explicit comparative purpose and the mention of specific data points like BezalRank and claim status.

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

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

The description implies usage for comparing multiple businesses but does not explicitly state when to use this tool over alternatives like get_business or search_businesses. It mentions the limit of 5, which is a constraint, but no explicit exclusions or routing guidance is provided.

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 transparency burden. It discloses that the profile is public, enumerates always-present fields, and explains which fields depend on paid plans/provider status. It does not discuss errors or rate limits, but for a read-only lookup by UUID, the most important behavioral constraints are 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?

The description is front-loaded with the core purpose and uses compact, scannable lists for return fields. Every sentence contributes: purpose, standard fields, paid-plan conditionals, and sibling routing. No filler 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?

There is no output schema, so the description must explain return values, and it does: always-present fields, paid-plan-only fields, and plan-dependent description. It also names the sibling for services. For a one-parameter UUID lookup, this is complete enough for an agent to call and interpret the result.

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% and the single 'id' parameter already has a description ('The UUID of the business to look up'). The tool description only repeats 'by UUID' and adds no extra meaning, format details, or example values, so it neither helps nor hurts 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 opens with a specific verb and resource: 'Get the public Bezal profile for one business by UUID.' It lists exactly what is returned and explicitly routes service-related lookups to get_service_catalog, making the tool's purpose and boundary clear.

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

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

The description gives an explicit alternative ('For services, use get_service_catalog') and implies this tool is for business profile lookup by UUID. It does not mention when to prefer search_businesses or get_provider_details, so the routing guidance is helpful but not exhaustive.

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 only mentions that the tool is a legacy alias, which suggests deprecation but does not describe side effects, read-only nature, return format, or any limitations. The word 'get' implies a read operation, but that is not explicit. The description is insufficient for understanding the tool's behavior beyond its deprecation status.

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

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

The description is two short sentences. Both sentences earn their place: one defines the tool as a legacy alias, and the other gives a usage directive. There is no redundancy or unnecessary detail.

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

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

The description is minimal and relies entirely on the agent knowing what get_business does. It does not explain what the tool returns, any prerequisites, or the exact behavior. Since there is no output schema and no annotations, the description leaves substantial gaps for a new agent trying to select and invoke this tool correctly.

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

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

The description provides no information about the business_id parameter, and schema description coverage is 0%. The schema itself gives a UUID format and the name is self-explanatory, but the description does not compensate for the lack of parameter guidance. The tool is simple, but the description offers zero value in explaining the parameter's meaning or usage.

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 the tool is a legacy alias for get_business, which gives a clear reference point but does not explain what get_business does. It implies the purpose is to retrieve business details, but the agent must infer this from the sibling tool name. This is more specific than a tautology but lacks explicit functional description.

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 states 'Prefer get_business for new clients,' which tells the agent when not to use this tool and names the alternative. It also implies the tool is intended for legacy clients only. This is a clear and actionable usage guideline that distinguishes it from a sibling tool.

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

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

With no annotations, the description carries the burden of explaining behavior. It clearly discloses the result composition: per-review fields (rating, text, verified flag, date, reviewer name) and the Google rating/count. It does not mention pagination, ordering, or empty-result behavior, but the read-only nature is apparent from 'Get'.

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 sentence, no filler, front-loaded with the action and then the payload details. It earns its place by specifying exactly what fields are included.

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 two-parameter read tool with no output schema, the description covers the main return shape and distinguishes Bezal reviews from Google rating. It is missing details on limit semantics and ordering, but the schema covers defaults and constraints, making this adequate.

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

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

The input schema fully documents both parameters (business_id and limit) with descriptions and constraints, so the description adds little beyond indicating the business context. Per the baseline, 3 is appropriate since schema coverage is 100%.

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 clear verb and resource: 'Get reviews for a specific business', and enumerates the exact data returned (Bezal reviews plus Google rating and count). This distinguishes it from sibling tools like get_business, which focus on business details rather than review content.

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

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

The description implies the tool is for retrieving reviews for a given business, but it does not explicitly compare with alternatives or state when not to use it. Sibling tools like get_business or compare_businesses could overlap, so an explicit usage note would help.

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 a meaningful behavioral trait: the fallback to a list of service names when no priced catalog exists. This goes beyond a generic 'get' and helps the agent anticipate variable output, though it does not cover other edge cases like missing business.

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 wasted words. The main purpose is front-loaded, and the fallback behavior is stated efficiently in the second sentence. Every clause 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?

For a single-parameter read tool with no output schema and no annotations, the description is complete. It states what is returned (services and pricing) and the edge-case behavior (fallback to service names), giving an agent enough context to select and invoke the tool correctly.

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

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

The only parameter, business_id, is already fully described in the schema as 'Business UUID'. The description confirms it identifies the business but adds no new semantic detail. With 100% schema coverage, 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?

States a specific verb ('Get'), resource ('services and pricing'), and scope ('for a specific business'), which clearly distinguishes it from siblings like get_business or get_reviews. The fallback behavior further clarifies what the tool returns.

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

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

The description implies when to use the tool—when you need a business's service catalog—but it does not explicitly mention alternatives or state when not to use it. No sibling comparison or exclusions are provided, so usage guidance remains implicit rather than explicit.

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

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

With no annotations, the description carries the full burden. It indicates a read-only listing with no side effects, but does not disclose details like ordering, pagination, or whether the list is static or dynamically generated. For a simple list tool, this is adequate 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 a single sentence that is direct and free of filler. Every word adds meaning, making it highly concise and appropriately 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?

For a zero-parameter, no-output-schema tool, the description sufficiently defines the tool's function. There are no complex inputs or outputs to explain, and the description leaves no major 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?

The tool takes zero parameters, so the input schema is empty (100% coverage). The baseline for zero parameters is 4, and the description need not add parameter details. No information is missing.

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 'List' and the resource 'business categories', and specifies scope as 'in the directory'. This distinguishes it from sibling tools like search_businesses or get_business, making the purpose unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. While it is logically distinct from search tools, the description gives no context such as 'use this to populate a category filter' or excludes any use cases.

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 and reveals meaningful behavior: delivered is true only when the business owner was notified, and unclaimed profiles get the request saved without notification. It does not cover auth or failure modes, but the disclosed return and edge-case semantics are substantive.

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: the first states the action, the second packs the return condition and the key exception. There is no filler, redundancy, or restatement of schema fields.

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

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

For a simple write action with fully described parameters and no output schema, the description covers the core behavior and the most important conditional outcome. It lacks an explicit sibling distinction, but an agent has enough information to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description adds no independent semantic detail about the parameters, but it also introduces no ambiguity or contradiction.

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 a specific action ('Send a service request') and target ('a business'), and clarifies the requester is acting on behalf of a person. It is clear, though it does not explicitly differentiate from the closest sibling, submit_quote_request.

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

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

No guidance is given on when to use this tool instead of alternatives such as submit_quote_request, nor are exclusions or prerequisites stated. The unclaimed-business notification edge case is behavioral context, not a usage rule.

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

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

With no annotations provided, the description carries the full burden and largely succeeds: it reveals that core fields are always present while phone, website, address, hours, photos, coordinates, and descriptions are gated by paid plans. It clearly conveys read-only search semantics and output availability, though it doesn't mention authentication, rate limits, or result ordering.

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

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

Two sentences, front-loaded with the action and followed by a compact but valuable enumeration of result fields and plan-based restrictions. Dense with useful information and no filler, though the field list makes it slightly heavier than a minimal description.

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?

Since there is no output schema, the description usefully explains what fields will appear and how plan tiers affect completeness. However, it is missing guidance on sibling-tool routing and on behavior when no optional filters are supplied, which leaves some ambiguity for an agent making a first call.

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 baseline of 3 applies. The description loosely maps 'name, category, or location' to query, category, city, and state, but it doesn't add parameter-level syntax or behavior beyond what the schema 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 uses a specific verb ('Search') and resource ('local business profiles on Bezal'), and names the search dimensions: name, category, or location. It is clear on its own, though it does not explicitly distinguish itself from sibling tools like search_by_city, search_by_service, or 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?

No guidance is given on when to use this tool versus alternatives such as search_by_city or search_by_service, and no exclusion criteria are mentioned. The description only states what the tool does, leaving tool selection among similar search siblings to inference.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds meaningful transparency by explaining that some fields are only available for paid Bezal plans, and that quote_request_url is the public profile link. This goes beyond a simple 'searches businesses' statement and helps set expectations about result completeness.

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 in the first sentence, and the second sentence packs useful return-field information without fluff. Every sentence earns its place, and the structure is easy for an agent to parse.

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

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

Despite no output schema, the description explains the return fields and conditional availability, which covers most of what an agent needs. It does not describe ordering, pagination behavior, or empty-result handling, but these are less critical for a simple search tool and the parameter schema is well-covered.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds the notion of category filtering and maps to the category parameter, but it does not add new meaning for city, state, or limit beyond what the schema provides. Baseline 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 action, resource, and scope: 'Search for businesses in a specific city, optionally filtered by category.' It also documents the fields returned. However, it does not explicitly differentiate this tool from siblings like search_businesses or search_by_service, so the differentiation is implicit rather than explicit.

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

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

The description explains the tool's basic use case but offers no guidance on when to choose it over alternatives. It does not mention sibling tools such as search_businesses, search_by_service, or search_providers, nor does it state exclusions like 'use search_by_service for service-based queries.' The agent is left to infer routing from the name.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It does this well by describing the standard return fields, the quote_request_url, and the paid-plan conditions under which phone, website, address, hours, photos, coordinates, and the description are included. It does not explicitly discuss side-effect status or auth, but 'Find businesses' implies a read-only lookup and the response shape is thoroughly disclosed.

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

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

The description is front-loaded with the purpose, and every subsequent sentence earns its place: one explains standard return fields, another explains paid-plan conditional fields, and neither repeats schema content or adds filler. It is detailed but appropriately sized.

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

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

Despite the lack of an output schema, the description fully specifies what a result contains and the conditions that alter that result shape, which is the main contextual information an agent needs beyond the two documented parameters. For a read-oriented search tool, nothing essential is missing.

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 service_type as 'Exact service offered (matched against the services list)' and location as 'Optional city or state to filter by'. The description reinforces these meanings with the drain-cleaning example and the word 'exact', but it does not add substantive new parameter semantics 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 states a specific verb and resource ('Find businesses that list a specific service') and distinguishes this tool from category-based search with a concrete example ('Drain cleaning' rather than 'plumbing'). This makes the tool's purpose unambiguous and clearly differentiates it from siblings such as search_by_city and search_businesses.

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 first sentence gives a clear usage condition: use this tool when you know the exact service rather than the category. It does not explicitly list alternative tools or state when-not-to-use conditions, but the context is concrete and actionable, so it earns a 4 rather than a 5.

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

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

With no annotations, the description carries the full burden. It only says it is a legacy alias, implying it behaves like search_businesses, but does not disclose read-only nature, side effects, or other behaviors. The agent cannot infer safety or impact from the description alone.

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 communicates the key fact (legacy alias) and the preference for the sibling. It is concise and front-loaded, though minimal.

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?

As an alias, the agent would need to understand what search_businesses does to use this tool effectively, but the description does not point to it for details. It lacks information on parameters, behavior, or return values, making it incomplete for a tool with 4 parameters and no schema coverage.

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

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

The schema description coverage is 0%, and the description does not mention any parameters. It provides no meaning for limit, query, category, or location, leaving the agent entirely dependent on the schema with no additional 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 states it is a legacy alias for search_businesses, which clearly identifies it as a search tool for businesses, but it does not describe the resource or behavior directly. It relies on the referenced tool to convey purpose, which is adequate but not fully self-contained.

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 advises preferring search_businesses for new clients, which gives a clear direction for tool selection. However, it does not explicitly state when to use this alias (e.g., for legacy clients), though it is implied.

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 only says this is a legacy alias and to prefer request_service, but it doesn't disclose what the tool does, what side effects it has, whether it creates a record, sends an email, or returns anything. The behavioral traits are almost entirely undisclosed.

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 short and front-loaded with the most important fact: it's a legacy alias. Every word earns its place, though it could have added a brief statement of what the tool does without bloating the text.

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

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

For a tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It tells the agent to prefer request_service but doesn't explain what this tool does, what the parameters mean, or what happens when it's invoked. An agent would have to open request_service to understand this tool, which is a significant gap.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It does not explain any of the four parameters (business_id, seeker_name, seeker_email, message) or how they relate to a quote request. The parameter names are somewhat self-explanatory, but the description adds no semantic value.

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

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

The description identifies this as a legacy alias for request_service, which implies it submits a quote request, but it never states the verb+resource directly. An agent can infer the purpose from the alias relationship and the sibling name, but the description itself is vague about what the tool actually does.

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

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

The description explicitly says to prefer request_service for new clients, which is clear usage guidance. It doesn't spell out when to use this tool instead, but for a legacy alias the guidance is sufficient: use it only for legacy compatibility.

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