Skip to main content
Glama

Mobile Number Check

asterwise_check_mobile_number
Read-onlyIdempotent

Sums the digits of the national number (country code left out), reduces them to a single number, and returns harmonic scoring plus interpretive copy.

WORKFLOW: BEFORE: RECOMMENDED — asterwise_get_numerology_profile — anchor Life Path before judging the line. AFTER: None.

INPUT CONTRACT: Only digits count; the country calling code is never counted. Numbers written with '+' or '00' use the national number. Without a prefix, pass country (ISO 3166 alpha-2, e.g. IN, US, CN) so the number is read as dialled in that country; with no country, only India's 12-digit 91… form is shortened and every other number is summed exactly as written (e.g. 14155552671 without country sums all 11 digits = 42; with country=US it is 41). With country, the number is read as dialled there first, international dialling prefix included (e.g. AU 0011, US 011). A '+'/'00' number drops its country code only when it is a valid number: an invalid '+' number sums every digit after '+', an invalid '00' number is summed as written.

DO NOT CONFUSE WITH: asterwise_check_vehicle_number — plate digit rules, not SIM numbering. asterwise_get_business_name_analysis — letter Expression scan, not phone roots.

Full output and error contract: https://docs.asterwise.com/mcp/tools/check-mobile-number/

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mobile_number": "<mobile_number>"
    },
    "name": "asterwise_check_mobile_number"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoNot used: the analysis depends only on the digits. Omit it; it is accepted only so older calls keep working.
nameNoNot used: the analysis depends only on the digits. Omit it; it is accepted only so older calls keep working.
countryNoCountry of the number as ISO 3166 alpha-2, e.g. 'IN', 'US', 'CN'. Used only when the number has no '+'/'00' prefix: it is then read as dialled in that country and the country code is left out of the sum.
mobile_numberYesMobile number to analyse; digits only, country code optional.
response_formatNoOutput format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.markdown

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / country
      Added value: +{
      +  "anyOf": [
      +    {
      +      "pattern": "^[A-Za-z]{2}$",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Country of the number as ISO 3166 alpha-2, e.g. 'IN', 'US', 'CN'. Used only when the number has no '+'/'00' prefix: it is then read as dialled in that country and the country code is left out of the sum."
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / date / description
      Previous value: -"Date in YYYY-MM-DD format. Defaults to today when omitted."New value: +"Not used: the analysis depends only on the digits. Omit it; it is accepted only so older calls keep working."
    • changedInput schema / properties / name / description
      Previous value: -"Person's full name as commonly written; letters are converted to numerology values."New value: +"Not used: the analysis depends only on the digits. Omit it; it is accepted only so older calls keep working."
  3. Changed8 schema fields changed
    • addedInput schema / properties / date / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / date / default
      Added value: +null
    • changedInput schema / properties / date / description
      Previous value: -"Date in YYYY-MM-DD format."New value: +"Date in YYYY-MM-DD format. Defaults to today when omitted."
    • removedInput schema / properties / date / type
      Removed value: -"string"
    • addedInput schema / properties / name / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / name / default
      Added value: +null
    • removedInput schema / properties / name / type
      Removed value: -"string"
    • changedInput schema / required
      Previous value: -[
      -  "mobile_number",
      -  "name",
      -  "date"
      -]New value: +[
      +  "mobile_number"
      +]
  4. Changed1 schema field changed
    • changedInput schema / properties / date / description
      Previous value: -"Date in YYYY-MM-DD format. Defaults to today when omitted."New value: +"Date in YYYY-MM-DD format."
  5. Changed4 schema fields changed
    • addedInput schema / properties / date / description
      Added value: +"Date in YYYY-MM-DD format. Defaults to today when omitted."
    • addedInput schema / properties / mobile_number / description
      Added value: +"Mobile number to analyse; digits only, country code optional."
    • addedInput schema / properties / name / description
      Added value: +"Person's full name as commonly written; letters are converted to numerology values."
    • addedInput schema / properties / response_format / description
      Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."
  6. Changed2 schema fields changed
    • addedInput schema / properties / response_format / default
      Added value: +"markdown"
    • changedInput schema / required
      Previous value: -[
      -  "mobile_number",
      -  "name",
      -  "date",
      -  "response_format"
      -]New value: +[
      +  "mobile_number",
      +  "name",
      +  "date"
      +]
  7. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only the safety profile (read-only, idempotent, non-destructive, closed-world); the description adds the actual behavioral contract: only digits count, the calling code is never summed, '+'/'00' prefixes drop a country code only for valid numbers, and invalid prefixed numbers are summed as written. It also discloses the output shape and that there is no follow-up tool.

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?

Front-loads the purpose, then organizes the rest under labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH), so the density is navigable. The input contract is lengthy with several worked examples, which is justified by genuinely ambiguous edge cases but is heavier than strictly necessary.

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

Completeness5/5

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

An output schema exists, so return values need not be re-explained; the description instead covers everything else an agent needs — input normalization rules, country handling, workflow ordering, sibling disambiguation, and a link to the full output and error contract. Nothing required for a correct call is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description goes further by showing the country parameter's concrete effect on the computation (14155552671 = 42 without country vs 41 with country=US) and explaining how local dialling prefixes (AU 0011, US 011) are handled. The unused date/name parameters are explained consistently with the schema.

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?

Names a precise operation (sum the digits of the national number, reduce to a single number) and the exact artifact returned (harmonic scoring plus interpretive copy). The DO NOT CONFUSE WITH section distinguishes it from the nearest siblings, asterwise_check_vehicle_number and asterwise_get_business_name_analysis, so an agent can select it without opening a schema.

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

Usage Guidelines5/5

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

Gives an explicit workflow precondition (RECOMMENDED asterwise_get_numerology_profile before judging the line) and names two alternatives with the reason each is different. It also states the conditions under which the country parameter must be supplied versus when the number is read as written.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources