bach-whatsapp_number_validators

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Multiple tools have overlapping purposes with unclear boundaries. For example, check_if_number_is_business_via_get_request, check_if_number_is_business_via_post_request, validate_single_number_via_get_request, and validate_single_number_via_post_request all appear to perform the same WhatsApp Business verification, differing only by HTTP method. This creates significant ambiguity and potential for misselection by an agent.
Naming Consistency2/5
Naming conventions are inconsistent and chaotic. Tools mix descriptive names (bulk_validation, phone_number_validation_via_get_request) with vague ones (ping), and there is no consistent pattern. Some tools use snake_case with HTTP method suffixes, while others do not, leading to a lack of predictability across the set.
Tool Count3/5
With 8 tools, the count is reasonable for a validation server, but it feels borderline due to redundancy. The number of tools is inflated by multiple versions of the same functionality (e.g., GET vs. POST for similar checks), which could have been consolidated, making the set feel slightly heavy for its scope.
Completeness4/5
The tool set covers the core domain of WhatsApp number validation well, including bulk and single validations, business checks, and general phone number validation. However, there are minor gaps, such as no tools for managing validation results or handling errors explicitly, but agents can likely work around these with the provided tools.
Average 2.9/5 across 8 of 8 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description discloses no behavioral traits—it does not state what the tool returns (string, boolean, status object), whether it makes network requests, or its latency characteristics. The description carries the full burden and provides nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While only three words and not verbose, 'Ping Validation Test' is not a proper sentence and fails to front-load actionable information. The brevity reflects under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters or output schema (requiring minimal description), the description is insufficient given the rich sibling context. It fails to indicate this is a health/connectivity check distinct from the validation-focused siblings, leaving agents unable to select it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage. Per the evaluation rules, zero-parameter tools receive a baseline score of 4, as there are no parameter semantics to convey beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Ping Validation Test' is tautological and ambiguous—it is unclear whether this pings a validation service, performs a validation test named 'ping', or serves as a health check. It fails to specify the resource acted upon or distinguish itself from the seven sibling validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus the specific validation endpoints (validate_single_number, bulk_validation, etc.). Given the sibling context, the description should clarify this is for connectivity/health checks rather than phone number validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses no behavioral traits beyond the core function. It fails to explain what 'POST' implies here (e.g., idempotency, body vs query params, potential side effects) or what happens when a number is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and appropriately front-loaded with the purpose statement. However, the second sentence is problematic given the empty schema, making the instruction misleading rather than merely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations, empty input schema, and no output schema, the description fails to compensate for the missing structured metadata. It does not explain the return format, the POST/GET distinction rationale, or resolve the parameter discrepancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references parameters ('the number', 'country code') that do not exist in the input schema (0 properties defined). This creates a critical mismatch where the description instructs providing data but the schema suggests no parameters are accepted, leaving the agent confused about actual invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies WhatsApp registration and determines if a number belongs to WhatsApp Business using specific verbs ('Verify', 'determine'). However, it fails to distinguish this POST variant from the sibling 'check_if_number_is_business_via_get_request'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'provide the number along with the corresponding country code' but offers no guidance on when to choose this POST endpoint versus the GET alternative, nor does it mention prerequisites, rate limits, or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the alternative number suggestion behavior, but omits safety characteristics (idempotency, read-only nature), authentication requirements, rate limits, or error handling specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with moderate efficiency. The first sentence is somewhat wordy ('utilize a phone number validator to verify the validity') and approaches tautology, while the second sentence delivers useful specific value about alternative numbers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without output schema, the description partially covers the return behavior by mentioning alternative number suggestions. However, it lacks details on response structure, validation criteria (format vs carrier vs line type), or error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with an example value. The description mentions 'given number' but does not add semantic context beyond the schema, such as expected format (E.164), country code requirements, or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core function (validating phone numbers) and a specific feature (providing alternative valid numbers for different countries when invalid). However, it fails to distinguish from siblings like 'validate_single_number_via_get_request' or explain the difference between the GET and POST variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not clarify when to choose GET vs POST, single validation vs 'bulk_validation', or this tool vs 'validate_single_number_via_get_request'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It successfully reveals the specific behavior of suggesting alternative country-specific numbers for invalid inputs, but omits other critical operational details like authentication requirements, rate limits, or error handling behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence structure is reasonably efficient, though the opening 'You can utilize' is filler that doesn't add value. The second sentence provides specific behavioral details that earn its place, but the description could be more direct about the input mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema and lack of output schema, the description fails to adequately explain how to invoke the tool (missing parameter documentation) or provide complete return value documentation beyond the alternative-number behavior. The mismatch between described functionality and empty schema is a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 0 parameters (baseline 4), the description confusingly refers to 'a given number' and verifying 'the validity of a given number', implying input parameters exist that are not reflected in the schema. This creates ambiguity about how the phone number is actually provided to the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool validates phone numbers and provides alternative valid numbers for different countries when invalid. However, it fails to distinguish from siblings like 'phone_number_validation_via_get_request' or 'validate_single_number_via_post_request', leaving ambiguity about when to choose this specific variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., POST vs GET variants, single vs bulk validation). The description lacks prerequisites, input requirements, or exclusion criteria despite having multiple similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It omits critical details such as rate limits, authentication requirements, response format, and error handling behaviors. It does not clarify what data is returned beyond the implied status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficiently structured sentences with no redundancy. The first states purpose, the second states input requirements. It is appropriately front-loaded, though the second sentence could be more specific about parameter formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete absence of annotations, output schema, and defined input parameters, the description is insufficient. It fails to describe the response structure, possible error states, or prerequisite authentication steps that would be necessary for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, yet the description references providing 'the number' and 'country code'. While this attempts to compensate for the empty schema by indicating required inputs, it creates ambiguity about whether these are path parameters, body fields, or missing schema definitions. With zero schema parameters, baseline is 4, but the mismatch reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies WhatsApp registration and determines Business account status using specific verbs and resources. However, it fails to differentiate from the sibling tool 'validate_single_number_via_get_request' or explain why to use POST versus GET.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides implied usage guidance ('provide the number along with the corresponding country code'), but lacks explicit when-to-use criteria or alternatives. It does not explain when to use 'bulk_validation' instead, or when to prefer this over the business-specific check tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the verification goal but omits critical operational details: what the tool returns (boolean, object, string?), error handling for invalid numbers, rate limits, or whether this triggers external API calls. The phrase 'obtain the status' is vague about the actual response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero redundancy. The first sentence states the purpose immediately; the second specifies input requirements. Every word earns its place without filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input and 100% schema coverage, the input side is adequately documented. However, the absence of an output schema combined with no description of return values or error states leaves a significant gap. The description meets minimum viability but fails to fully compensate for missing structured data about outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage with an example value, the description adds essential semantic context by explicitly stating the number must include the 'corresponding country code.' This prevents errors from users providing local numbers without prefixes, adding meaningful value beyond the schema's basic example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies WhatsApp registration and determines Business account status using specific verbs ('Verify', 'determine'). However, it does not distinguish when to use this GET endpoint versus the sibling POST endpoint (check_if_number_is_business_via_post_request), which appears to offer identical functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides input requirements ('provide the number along with the corresponding country code') but offers no guidance on when to choose this tool over siblings like bulk_validation (for multiple numbers) or the POST variant. No prerequisites, error conditions, or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'verify' implies a read-only operation, the description omits rate limits, authentication requirements, error handling, or the structure/format of the returned status information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences: the first establishes purpose and scope, the second provides input requirements. There is no redundant or wasted text; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter) and lack of output schema, the description adequately covers inputs. However, with no annotations and no output schema, it should ideally describe what the tool returns (e.g., status object, boolean flags) or error behaviors to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% coverage, the parameter description only provides an example value. The text adds critical semantic context by explicitly stating the number must be provided 'along with the corresponding country code,' clarifying the expected format beyond the schema's example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies WhatsApp registration and determines business status using specific verbs ('Verify', 'determine'). It implicitly distinguishes from bulk_validation by referencing 'a given number' and from phone_number_validation siblings by mentioning WhatsApp Business detection, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name ('single_number') and phrasing ('a given number', 'a particular number'), suggesting this is for individual validation rather than bulk operations. However, there is no explicit guidance on when to choose this over validate_single_number_via_post_request or check_if_number_is_business_via_get_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses the 25-number limit and country code requirement, but omits authentication needs, rate limits, error handling for invalid numbers, and whether partial failures return individual error codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently cover capacity (25 numbers), functionality (WhatsApp + Business verification), and input requirements (country codes). No redundancy; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic operation understanding given the simple input model, but lacks output format description (especially critical given no output schema exists) and error behavior for malformed numbers or exceeding limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite empty schema (0 parameters), description states 'provide all numbers along with the corresponding country code,' implying parameters exist. This creates a dangerous mismatch: agents see no schema parameters but description insists input is required, leaving invocation method ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (verify) + resource (WhatsApp registration and Business status) + scope (up to 25 numbers). The '25 numbers' constraint clearly distinguishes this from single-number validation siblings like 'validate_single_number_via_get_request'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context through the 'up to 25 numbers' constraint, suggesting bulk use cases. However, lacks explicit guidance on when to prefer single-validation alternatives or behavior when exceeding the 25-number limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bachai-whatsapp-number-validators MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-whatsapp-number-validators/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-whatsapp-number-validators)

Score Badge

Copy to your README.md:

[![bachai-whatsapp-number-validators MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-whatsapp-number-validators/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-whatsapp-number-validators)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/bachai-whatsapp-number-validators'

If you have feedback or need assistance with the MCP directory API, please join our Discord server