Search 7,000+ local service businesses across America by category, location, or keyword.
Check if a business has availability on a specific date using their Bezal calendar. Best-effort — only works for businesses that use the calendar feature.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ISO date (YYYY-MM-DD) | |
| business_id | Yes | Business UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It honestly discloses 'best-effort' behavior and the dependency on the calendar feature, which is useful context. However, it does not describe the return value or what happens when a business does not use the calendar, leaving ambiguity.
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 concise sentences, no filler. The first sentence states the core action, and the second adds an important caveat, both earning their 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 low-complexity tool with two parameters and no output schema, the description covers the core behavior and major limitation. It lacks return-format details, but 'availability' is a reasonably clear concept. Slightly under-specified for the no-output-schema case, hence 4.
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%, with both parameters already described ('ISO date (YYYY-MM-DD)' and 'Business UUID'). The description adds little beyond 'specific date', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('business availability on a specific date using their Bezal calendar'), making the tool's function clear. It distinguishes this from sibling tools like search_businesses or get_business by focusing on a date-specific availability query.
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 when to use the tool (availability check for a business on a particular date) and provides a key limitation ('only works for businesses that use the calendar feature'). It does not explicitly name alternatives, but the use case is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare up to 5 businesses side-by-side on ratings, services, BezalRank, and profile status.
| Name | Required | Description | Default |
|---|---|---|---|
| business_ids | Yes | Array of business UUIDs to compare |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It specifies what is compared (ratings, services, BezalRank, profile status), which is useful, but it does not disclose return format, error handling, or explicitly confirm that it's a read-only operation. It is adequate but lacks depth.
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?
A single, front-loaded sentence that states the action, limit, and comparison fields with no filler. Every word contributes value.
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 tool with no output schema, the description covers the core functionality adequately. It could mention what the response looks like or edge cases, but given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (business_ids), and the schema already provides a clear description and constraints (UUID array, 1-5 items). The tool description adds context about comparison dimensions but no additional parameter-specific meaning, so it matches the baseline.
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 'Compare' with a clear resource 'businesses' and scope 'up to 5', and lists the comparison dimensions (ratings, services, BezalRank, profile status). This distinguishes it from sibling tools like get_business (single business) and search_businesses (search).
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 side-by-side comparison of multiple businesses. It does not explicitly state when not to use it or name alternatives, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full profile for a specific business including contact info, services, ratings, and hours.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The UUID of the business to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. 'Get' implies a read-only operation, and listing profile contents gives expected output, but it does not mention error handling, authorization, or any side effects. This is adequate for a simple get-by-id tool but leaves room for more 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, focused sentence that starts with the action and clearly lists what the profile includes. No unnecessary words or repetition, making it immediately scannable.
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 single-parameter tool with no output schema, the description covers the parameter and key return contents. It could mention what happens if the ID does not exist, but the basic information is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'id' parameter with a clear description and format, so the description adds little beyond 'specific business'. Schema coverage is 100%, so the baseline of 3 applies and the description provides marginal reinforcement.
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 (Get), the resource (full profile for a specific business), and the contents (contact info, services, ratings, hours). It is specific and distinguishes from siblings like search_businesses and get_provider_details.
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 retrieving a specific business's details by ID, but it does not explicitly state when to use it over alternatives or exclude cases like searching. There is no mention of when not to use it, though the 'specific business' wording offers some contextual cue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy alias for get_business. Prefer get_business for new clients.
| Name | Required | Description | Default |
|---|---|---|---|
| business_id | Yes |
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.
Get reviews for a specific business including Bezal Verified reviews and Google rating.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max reviews to return | |
| business_id | Yes | Business UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. The verb 'Get' implies a read-only operation, and the mention of review sources adds some context. However, it lacks explicit confirmation of no side effects, pagination behavior, or error handling.
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 concise sentence that directly states the purpose without any 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?
For a simple two-parameter read tool, the description is mostly adequate, but the absence of annotations and output schema leaves gaps around expected return structure and edge cases. It is not severely incomplete, but it could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter descriptions for business_id and limit. The description adds minimal additional meaning beyond confirming the business context, so a 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 identifies the tool as retrieving reviews for a specific business, including specific review types (Bezal Verified, Google rating). This specific verb+resource+scope distinguishes it from sibling tools like get_business.
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 use case (fetching reviews for a business) but does not explicitly contrast it with other tools or state when to avoid using it. Since there is no overlapping sibling tool, the ambiguity is low, but guidance is still minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get services and pricing for a specific business. Falls back to the services list if no priced catalog exists.
| Name | Required | Description | Default |
|---|---|---|---|
| business_id | Yes | Business UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden for behavioral disclosure. It reveals a key behavior: falling back to the services list if no priced catalog exists. This is valuable behavioral context beyond the schema, though it doesn't mention permissions or side effects, which are less critical for a get 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?
The description is two sentences, with the primary purpose in the first sentence and the fallback behavior in the second. It is concise, front-loaded, and contains no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and clear scope, the description effectively covers the main functionality and an important edge case. It doesn't explicitly describe the response format, but 'services and pricing' and the fallback note give sufficient context for a straightforward retrieval 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% coverage for the only parameter business_id, described as 'Business UUID.' The description adds no extra detail beyond the schema, so it gains no additional value. Baseline 3 is appropriate since the schema already documents the parameter.
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' with a clear resource 'services and pricing' and a target 'specific business.' It distinguishes from siblings like get_business or get_provider_details by focusing on services and pricing, making its purpose specific and 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 implies usage for retrieving services and pricing for a given business. It doesn't explicitly name alternatives or exclusions, but the fallback note clarifies behavior when a priced catalog is absent, providing clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available business categories in the directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Submit a service request to a business on behalf of a consumer.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Detailed message about what the requester needs | |
| business_id | Yes | The UUID of the business to send the request to | |
| seeker_name | Yes | Name of the person requesting the service | |
| seeker_email | Yes | Email address of the requester | |
| service_needed | No | Short description of the service category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only says 'submit.' It does not mention side effects (e.g., whether a record is created), prerequisites, authentication needs, or notification 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 a single concise sentence that gets straight to the point with no filler or redundant content. 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?
This is a mutation tool with no annotations and no output schema, yet the description provides no expected outcomes, return behavior, side effects, or usage prerequisites. Sibling tools like 'submit_quote_request' add potential confusion that is not addressed.
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 is 3. The description adds no extra parameter detail beyond the schema, though the phrase 'on behalf of a consumer' subtly ties to seeker fields.
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 'Submit a service request to a business on behalf of a consumer,' providing a specific verb and target resource. It is clear on the action, though it does not explicitly distinguish itself from the sibling 'submit_quote_request' beyond the resource type.
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 'submit_quote_request' or 'search_businesses'. It lacks context for selection, exclusions, or any comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 47,000+ local business profiles by name, category, or location.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name | |
| limit | No | Number of results to return (1-20) | |
| query | No | Free-text search across business name and description | |
| state | No | Two-letter state code or full state name | |
| category | No | Category keyword (e.g. "plumbing", "hr consulting") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency, but it only mentions the number of profiles ('47,000+'), omitting details about result limits, parameter combinations, or search behavior. It also overstates by saying 'by name, category, or location' without mentioning that 'query' searches name and description, which is a notable 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?
The description achieves maximum conciseness with a single sentence, front-loading the action and key search dimensions. There is no fluff 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?
Despite having five optional parameters and no output schema, the description provides no information about return values, result behavior, or parameter combinations. It also fails to position this tool relative to its siblings, making it incomplete for an agent to fully understand the tool's capabilities.
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 cover 100% of parameters, so the tool description adds little semantic value beyond grouping parameters into 'name, category, or location.' It does not explain parameter interactions or defaults, but the schema already handles individual parameter meanings. 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 tool's function with a specific verb ('Search') and resource ('local business profiles'), also mentioning search dimensions ('by name, category, or location'). However, it does not explicitly differentiate from sibling tools like search_by_city or search_providers, which could lead to confusion about when to use 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?
The description provides no explicit guidance on when to use this tool versus alternatives such as search_by_city or search_providers. The usage is implied by the description of the search function, but without exclusions or alternative tool references, the agent lacks clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for businesses in a specific city, optionally filtered by category. City-level matching.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name | |
| limit | No | Max results | |
| state | No | Two-letter state code or full name | |
| category | No | Category keyword filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for disclosing behavior. It adds 'City-level matching' as a behavioral hint, but does not explain ordering, pagination, or whether the match is exact or fuzzy. It is not misleading but lacks depth.
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, concise sentence that front-loads the core purpose and optional filter. Every word earns its place, with no redundancy or irrelevant details.
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 read-only search tool with a detailed schema, the description is adequate but not complete. It lacks guidance on when to choose this tool over the multiple sibling search tools, and does not clarify any limitations or special cases beyond 'city-level matching'.
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 parameters. The description adds minimal extra context by emphasizing city as the key filter and category as optional, but does not explain parameter relationships or the role of 'state'.
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), the resource (businesses), and the scope (specific city), which distinguishes it from search_by_service. However, it does not explicitly name alternative tools or contrast its scope with search_businesses, so it falls short of a 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 no guidance on when to use this tool versus siblings like search_businesses or search_by_service. It only mentions an optional category filter, which is functional rather than contextual. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find businesses that offer a specific service type. Useful when you know the exact service rather than the category — e.g. "Drain cleaning" rather than "plumbing".
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | Optional city or state to filter by | |
| service_type | Yes | Exact service offered (matched against the services array) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only restates the basic behavior. It does not disclose whether matching is exact, case-sensitive, or partial, nor what happens with no results or multiple results. The schema notes matching against the services array, but the description adds no additional behavioral 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 only two sentences and includes a clarifying example. Every word earns its place, and the structure is front-loaded with the core action before the usage hint.
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 (2 simple parameters, no output schema, no annotations), the description is largely complete for tool selection and invocation. It could mention that 'location' is optional, but the schema already covers that, so no major gap exists.
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 description adds meaningful nuance by explaining the difference between an exact service and a category, with a clear example. This helps agents understand how to populate 'service_type' beyond the schema's generic phrasing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds businesses offering a specific service type, using a specific verb ('Find') and resource ('businesses'). It also distinguishes itself from siblings via the 'exact service rather than the category' contrast and a concrete example.
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 specifies when to use the tool ('when you know the exact service') and contrasts with category-based search. It does not name alternative sibling tools or state when not to use it, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy alias for search_businesses. Prefer search_businesses for new clients.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| category | No | ||
| location | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral details such as side effects, permissions, return format, or operational impact. Saying 'legacy alias' indicates compatibility but not actual behavior, leaving the agent without necessary safety or execution 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 text is very short, but it is under-specified rather than effectively concise. It omits essential details about the tool's purpose and parameters, making it insufficient 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?
Given four undocumented parameters, no annotations, no output schema, and no behavioral details, the description is far from complete. It only provides a compatibility pointer, which is inadequate for an agent 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?
All four parameters (limit, query, category, location) have zero schema descriptions, and the description does not mention or explain any of them. The agent receives no guidance on parameter meaning or usage, making correct invocation difficult.
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 only identifies the tool as a legacy alias for search_businesses but does not state what the tool actually does. The function is entirely dependent on the sibling tool's description, so the purpose is not clearly communicated.
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 advises preferring search_businesses for new clients, which clearly indicates when not to use this tool and implies legacy use cases. This provides actionable guidance beyond just naming an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy alias for request_service. Prefer request_service for new clients.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| business_id | Yes | ||
| seeker_name | Yes | ||
| seeker_email | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden. It discloses only that the tool is a legacy alias, but does not describe any side effects, permissions, or operational behavior. The word 'alias' hints at identical behavior to request_service, but the actual consequences of invoking it are not 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 one compact sentence with no filler words. It efficiently communicates the tool's legacy status and the preferred alternative, making every word earn 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?
As a legacy alias, the description adequately serves as a redirect to request_service, which is a sibling and presumably documents full behavior. The parameter details are available in the schema, and the deprecation guidance is complete. However, it lacks a direct functional description, which would make it self-contained.
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%, and the description adds no information about any of the four required parameters. The description mentions no parameter meanings, types, or usage context, leaving the schema to do all the work.
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 request_service,' which implies it performs the same function as request_service but never explicitly says 'submits a quote request.' It distinguishes itself from siblings by naming request_service as the preferred alternative, but the lack of a direct verb and resource makes the purpose somewhat vague.
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 'Prefer request_service for new clients,' which gives clear guidance on when to use this tool only for legacy clients and which alternative to use. This is direct, actionable usage guidance with an explicit alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
check_business_availabilitycompare_businessesget_reviewsget_service_catalogsearch_by_cityget_businessget_provider_details1 field changedInput schema / properties / business_id / descriptionRemoved value: -"The UUID of the business to look up"request_servicesearch_businessessearch_by_servicesearch_providers4 fields changedInput schema / properties / category / descriptionRemoved value: -"Business category to filter by (e.g. \"plumbing\", \"accounting\")"Input schema / properties / limit / descriptionRemoved value: -"Number of results to return (1-20, default 5)"Input schema / properties / location / descriptionRemoved value: -"City name or state (e.g. \"Hartford\", \"Connecticut\", \"CT\")"Input schema / properties / query / descriptionRemoved value: -"Free-text search across business name and description"submit_quote_request4 fields changedInput schema / properties / business_id / descriptionRemoved value: -"The UUID of the business to request a quote from"Input schema / properties / message / descriptionRemoved value: -"Description of what the seeker needs"Input schema / properties / seeker_email / descriptionRemoved value: -"Email address of the person requesting the quote"Input schema / properties / seeker_name / descriptionRemoved value: -"Name of the person requesting the quote"get_provider_detailslist_categoriessearch_providerssubmit_quote_requestClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Search thousands of verified US local service providers across 10 home-services trades, including crawl space repair, floor coating, radon mitigation, commercial electrical, and laundry services. Returns ratings, services, pricing, descriptions, and profile links. Every result passes a completeness gate, so listings are never half-empty.
Search and discover local businesses. 30+ categories with verified contact info, hours, and reviews.
Directory and marketplace of local businesses and independent professionals near you.
Verified US local service providers across 10 home-services trades. Ratings, hours, no API key.
Add one secure layer between your agents and this server.
The three legacy aliases (get_provider_details, search_providers, submit_quote_request) are exact duplicates of existing tools, creating direct ambiguity. The three search tools (search_businesses, search_by_city, search_by_service) overlap somewhat, though descriptions help clarify their focus.
Most tools follow a clear verb_noun snake_case pattern (e.g., get_business, list_categories, compare_businesses). Minor deviations include the 'search_by_*' variants and legacy aliases with different noun choices (provider vs. business), but these are still readable and consistent in style.
13 tools is within a reasonable range for a business intelligence server, but 3 are redundant legacy aliases, reducing the effective unique tool count to 10. The count is appropriate but slightly inflated by the aliases.
The server covers core workflows: searching, retrieving profiles, reviews, services, availability, comparisons, and service requests. Minor gaps exist, such as no booking capability and limited filtering options, but the primary use case is well served.