Search 7,000+ local service businesses across America by category, location, or keyword.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.5/5 across 13 of 13 tools scored. Lowest: 2/5.
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.
check_business_availabilityAInspectCheck 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_businessesAInspectCompare 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_businessAInspectGet 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.
get_provider_detailsBInspectLegacy 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_reviewsAInspectGet 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_service_catalogAInspectGet 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_categoriesAInspectList 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.
request_serviceCInspectSubmit 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_businessesBInspectSearch 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_by_cityBInspectSearch 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.
search_by_serviceAInspectFind 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.
search_providersCInspectLegacy 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.
submit_quote_requestBInspectLegacy 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!