What can you do with this server?

This server provides North American (NANP) area code and phone number intelligence for US and Canada, powered by official NANPA data. * Look up an area code: Get country, state/province, cities served, time zone, current local time, overlay codes, and nearby codes for any 3-digit NANP area code. * Look up a phone number: Parse and validate any US/Canada phone number, returning E.164 format, area code, region, time zone, and current local time. * Look up a number's carrier: Find the assigned carrier, line type (wireless/landline), and rate center based on a number's NPA-NXX block allocation (not live/ported data). * Find area codes for a city: List all area codes serving a given US or Canadian city, with optional state/province disambiguation. * Find area codes for a state/province: List every area code in a given US state or Canadian province. * Check if an area code is associated with scams: Get scam/spoofing context for an area code, including FTC Do Not Call complaint aggregates. * Check a number's community reputation: Retrieve unverified crowd-sourced reputation signals (low/mid/high) plus public FTC Do Not Call complaint data for a specific number. * Explain phone/area-code topics: Get source-backed explanations on topics like neighbor spoofing, overlays vs splits, toll-free numbers, area codes vs country codes, and temporary phone numbers.

How do I use areacode-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@areacode-mcp I got a call from area code 469. Is it suspicious?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

areacode-mcp

by riv-lc

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

areacode-mcp

North American (NANP) area-code & phone-number intelligence for AI agents.

npm

An MCP server that gives Claude, Cursor, and other agents a small, trusted reference for US & Canada phone numbering — area codes, NANP validation, local time, city/state coverage, overlays, and scam/spoofing context. Backed by areacode.fyi, which publishes directly from the official NANPA numbering database. Every result includes a canonical areacode.fyi URL and the source date.

Scope. This is area-code-level reference and education — not a carrier/identity API. It does not return a caller's identity, exact location, or live/ported carrier, and caller ID can be spoofed, so a number's area code never proves who is calling. For caller identity you need a carrier-grade (LRN/HLR) provider.

Install

Run it with npx (no install needed) — add it to your client's MCP config.

Claude Desktop (claude_desktop_config.json) / Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "areacode": {
      "command": "npx",
      "args": ["-y", "@riv-lc/areacode-mcp"]
    }
  }
}

That's it — restart your client and the tools below are available.

Published on the official MCP Registry as io.github.riv-lc/areacode-mcp, and on npm.

Remote (hosted) — for ChatGPT, Claude.ai, and web clients

No install. Add the hosted server as a connector URL — same 8 tools, no key:

https://mcp.areacode.fyi/mcp

(legacy SSE clients: https://mcp.areacode.fyi/sse)

Related MCP server: mcp-phone

Tools

Tool	What it does
`lookup_area_code`	Country, state/province, cities, time zone, current local time, overlays, nearby codes
`lookup_phone_number`	Parse/validate a NANP number → area code, region, local time, E.164
`lookup_carrier`	Assigned carrier, line type (wireless/landline), and rate center for a number's NPA-NXX block (block-allocation data, not live/ported; covers nearly every US/Canada code)
`area_codes_for_city`	Area codes serving a city (optionally disambiguated by state)
`area_codes_for_state`	Every area code in a US state or Canadian province
`is_scam_area_code`	Scam/spoofing context for an area code + an aggregate of FTC Do Not Call complaints filed about numbers using that code
`check_number_reputation`	Unverified community signal (low / mid / high) plus public FTC Do Not Call complaint data (count, % robocalls, top subject) for a number
`explain_area_code_topic`	Source-backed explainers: neighbor spoofing, overlays vs splits, toll-free, area-code-vs-country-code, temporary numbers

Example prompts

"A lead entered phone number +1 702-555-0199. Where are they likely located and what time is it there?"
"I got a call from 469 — is that area code suspicious?"
"Which area codes cover Las Vegas?"
"Normalize this list of US/Canada numbers and flag any that are invalid or toll-free."
"Explain neighbor spoofing for a help-center article."

Configuration

Env var	Default	Purpose
`AREACODE_API_BASE`	`https://areacode.fyi`	Point at a different host (e.g. a self-hosted or staging API)

Data & sourcing

Tools call the public https://areacode.fyi/api/v1 JSON API, which reads the same dataset the site renders — sourced from the official North American Numbering Plan Administrator (NANPA) database and refreshed monthly. Each response carries source, canonical_url, and data_date so answers can cite where the data came from.

The check_number_reputation signal is unverified and crowd-sourced (low = people looked the number up; mid/high = it has user reports). It is never proof that a specific number is fraudulent.

License

MIT © Reindex Ventures. Built for areacode.fyi.

Available Tools

8 tools

area_codes_for_cityArea codes for a cityA

List the area codes that serve a US or Canadian city. Optionally pass a state/province to disambiguate cities that share a name.

ParametersJSON Schema

Name	Required	Description	Default
`city`	Yes	City name, e.g. "Las Vegas".
`state`	No	Optional state/province name or 2-letter code to disambiguate, e.g. "NV".

TDQS

A4.1/5.0

Behavior3/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. It only says 'list' without disclosing behavioral details such as whether results are limited, if area codes are current, or any constraints like rate limits.

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?

Two concise sentences front-load the core purpose and optional usage. No extraneous information.

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?

While the description covers purpose and parameter guidance, it lacks details about return format or behavior (e.g., no output schema). For a simple query tool, this is adequate but could be more 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?

Schema coverage is 100% with clear parameter descriptions. The tool's description adds value by explaining the role of the optional state parameter for disambiguation, which goes beyond the schema's basic text.

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?

The description clearly states the tool lists area codes for a US or Canadian city, which is a specific verb+resource pairing. It distinguishes from sibling tools like area_codes_for_state by focusing on city rather than state.

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?

The description mentions optionally passing a state/province to disambiguate shared city names, providing context for when to use the parameter. However, it does not explicitly state when not to use this tool or alternatives.

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

area_codes_for_stateArea codes for a state/provinceA

List every area code in a US state or Canadian province.

ParametersJSON Schema

Name	Required	Description	Default
`state`	Yes	State/province name or 2-letter code, e.g. "Nevada" or "ON".

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided. Description indicates a read operation ('list'), which is transparent. However, no behavioral details like output format, pagination, or error handling are included.

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?

Single sentence, front-loaded with verb and scope, no extraneous words. Efficient and clear.

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

Completeness4/5

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

For a simple tool with one parameter and no output schema, the description is adequate. Slightly lacking in details about return format but sufficient for basic understanding.

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?

Schema coverage is 100% and includes a description and example. The tool description adds no additional meaning beyond what the schema provides.

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?

Description clearly states the verb 'List', resource 'area code', and scope 'US state or Canadian province'. It distinguishes from sibling tool 'area_codes_for_city' by specifying geographic level.

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?

No explicit guidance on when to use this tool vs alternatives. The purpose is implied by the name and scope, but lacks explicit when-not or context for sibling tools.

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

check_number_reputationCheck a number's community reputationA

Return the UNVERIFIED, crowd-sourced community signal for a US/Canada number from areacode.fyi: 'low' (people have looked it up), 'mid'/'high' (it has user reports). Caller ID can be spoofed — this is never proof a specific number is fraudulent.

ParametersJSON Schema

Name	Required	Description	Default
`number`	Yes	A US/Canada phone number, e.g. "702-555-0199".

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the unverified, crowd-sourced nature and the spoofing warning, but does not mention whether the tool is read-only, has rate limits, or data freshness. The behavioral traits beyond the core output are under-specified.

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 is three concise sentences with no wasted words. The most important information (the return values and meaning) is front-loaded, and the caveat is provided immediately after.

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

Completeness4/5

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 and no annotations, the description covers the return value meaning and critical caveats. It lacks potential details like cost or async behavior, but given the simplicity, it is fairly complete.

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?

Schema coverage is 100% with a clear example and format. The description adds no new parameter-level details beyond the schema, so it meets the baseline of 3 but does not exceed it.

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?

The description clearly states the tool returns an UNVERIFIED crowd-sourced signal for US/Canada numbers, defines the possible values ('low', 'mid', 'high'), and explains their meaning. The verb 'Return' and scope are explicit, distinguishing it from sibling tools like area code or carrier lookups.

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?

The description provides good usage context by noting that the signal is unverified and that caller ID can be spoofed, implying the tool should not be used as proof of fraud. However, it does not explicitly state when to use it versus when to avoid it, nor name alternative tools for definitive checks.

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

explain_area_code_topicExplain a phone / area-code topicA

Source-backed explanation of a phone-numbering topic, suitable for answering end users.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	The topic to explain.

TDQS

A3.7/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It mentions 'source-backed' but fails to specify whether the tool performs a read operation, fetches data, or has side effects. No details about prerequisites or limitations.

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 is a single, front-loaded sentence that conveys the core purpose without unnecessary words. Every element 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 simple input (enum parameter) and lack of output schema, the description is minimally adequate. However, it lacks details about the explanation format, length, or any behavioral constraints, leaving some gaps for an agent.

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?

Schema coverage is 100%, with the single parameter 'topic' fully enumerated and described. The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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?

The description clearly states it provides a 'source-backed explanation of a phone-numbering topic, suitable for answering end users.' This distinguishes it from sibling tools like 'lookup_area_code' (which likely returns metadata) or 'check_number_reputation' (about scams).

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?

The description indicates suitability for 'answering end users,' providing clear context. However, it does not explicitly state when not to use it or offer direct alternatives, though sibling tools are listed externally.

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

is_scam_area_codeIs an area code a scam?A

Explain whether an area code is associated with scams. An area code is never a scam by itself; this returns that context plus spoofing notes — caller ID can be faked, so judge calls by what they ask for, not the area code.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	A 3-digit area code, e.g. "702".

TDQS

A4.3/5.0

Behavior4/5

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

Without any annotations, the description fully discloses the tool's behavior: it returns context about scam association and spoofing notes, emphasizing that the area code itself is not indicative of a scam. No side effects or permissions are mentioned, but for a simple informational tool, this is adequate.

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 is concise: two sentences that front-load the purpose and add crucial nuance without any fluff. Every sentence adds value.

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?

Given the simplicity of the tool (one parameter, no output schema), the description is complete. It explains the core functionality, the caveat about spoofing, and how to use the result, leaving no obvious gaps.

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 already provides a clear description of the 'code' parameter (3-digit area code). The description does not add new parameter details but reinforces the context of what the tool returns, which indirectly aids understanding. With 100% schema coverage, 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.

Purpose5/5

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

The description clearly states the tool's purpose: to explain whether an area code is associated with scams. It also provides nuanced context that an area code is never a scam by itself and returns spoofing notes, distinguishing it from sibling tools like lookup_area_code or check_number_reputation.

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?

The description implicitly advises when to use the tool (to check if an area code is scam-related) and provides guidance on how to interpret results: 'judge calls by what they ask for, not the area code.' It does not explicitly state when not to use but does offer clear context.

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

lookup_area_codeLook up an area codeA

Look up a North American (NANP) area code: country, state/province, principal city and served cities, time zone, current local time, 10-digit-dialing flag, overlay codes, and nearby codes. Returns a canonical areacode.fyi URL and the NANPA source date.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	A 3-digit area code, e.g. "702".

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are present, so the description carries full burden. It lists return data and source, but does not disclose whether the operation is read-only, requires authentication, or has rate limits. The information provided is adequate for a simple lookup.

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 is a single sentence with a list of return fields, concise and front-loaded. It could be slightly more structured but is efficient.

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

Completeness4/5

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

Given no output schema, the description adequately enumerates return values. No obvious gaps for a tool with one parameter and no complex behavior.

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% with a clear description for the 'code' parameter. The description adds value by specifying the North American NANP scope, enhancing understanding beyond 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?

The description specifically states 'Look up a North American (NANP) area code' and enumerates the returned data (country, state, cities, time zone, etc.), clearly differentiating it from sibling tools like area_codes_for_city which do the reverse.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies usage for NANP area codes but does not mention when to avoid it or provide comparisons to sibling tools.

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

lookup_carrierLook up a number's carrier (assigned block)A

Look up the carrier, line type (wireless/landline), and rate center that a US/Canada number's NPA-NXX block was assigned to. Based on public block-allocation data — NOT a live lookup: if the number was ported the current carrier differs, and coverage currently spans major metros (uncovered area codes return covered:false). Not for caller identity, fraud, or FCRA decisions.

ParametersJSON Schema

Name	Required	Description	Default
`number`	Yes	A US/Canada phone number, e.g. "212-555-0143".

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description takes full responsibility for behavioral disclosure. It reveals that data is from public block allocation, not live, and coverage is limited to major metros with uncovered areas returning covered:false. It also notes that ported numbers may yield incorrect current carriers.

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 is concise and front-loaded, with only four sentences that efficiently convey the action, data source, limitations, and disclaimers. No filler or redundant information.

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

Completeness4/5

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

The description adequately covers input, output fields (carrier, line type, rate center, covered), and limitations in the absence of an output schema. It could mention the output format explicitly, but the provided details are sufficient for an agent to understand what to expect.

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 schema describes the single parameter 'number' with an example format, achieving 100% coverage. The tool description adds context about the number being US/Canada and the rate center lookup, but does not add significant meaning beyond the schema. Baseline 3 is appropriate.

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?

The description clearly states the tool's purpose: looking up carrier, line type, and rate center for US/Canada phone numbers based on assigned NPA-NXX blocks. It distinguishes itself from sibling tools like lookup_phone_number, check_number_reputation, etc., by specifying its unique functionality.

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?

The description provides clear usage guidance: it's based on block-allocation data, not a live lookup, and warns about ported numbers and coverage limitations. It explicitly states what it is not for (caller identity, fraud, FCRA decisions), helping agents avoid misuse.

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

lookup_phone_numberLook up a phone numberA

Parse and validate a US/Canada (NANP) phone number. Returns whether the format is valid, the E.164 form, the area code, the likely region and time zone, and the current local time there. Area-code level only — NOT the caller's identity, exact location, or live carrier; caller ID can be spoofed.

ParametersJSON Schema

Name	Required	Description	Default
`number`	Yes	A phone number in any format, e.g. "+1 702-555-0199".

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It clearly discloses limitations: area-code level only, no identity or carrier, and spoofing warning. This gives the agent important behavioral context. It does not describe side effects, but as a read-only lookup, that is acceptable.

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 is two sentences: first sentence states the action and return values, second sentence clarifies limitations. It is front-loaded, every sentence adds value, and there is no fluff. Perfectly sized for quick understanding.

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?

Given no output schema, the description enumerates all return fields (validity, E.164, area code, region, time zone, local time) and emphasizes the area-code-only limitation. With a simple single-parameter tool, this fully covers the agent's needs for correct invocation and understanding of results.

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 schema describes the parameter with an example, achieving 100% coverage. The description adds value by specifying the geographic scope ('US/Canada (NANP)') and connecting it to the overall validation purpose, which goes beyond the schema description.

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?

The description clearly states the verb 'Parse and validate' and the resource 'US/Canada (NANP) phone number', and lists specific return values. It distinguishes this tool from siblings by explicitly noting it provides area-code level info only — not caller identity, exact location, or carrier — which sets it apart from sibling tools like lookup_carrier or check_number_reputation.

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?

The description provides implicit usage guidance by stating what the tool does NOT do (identity, exact location, carrier) and mentions that caller ID can be spoofed, helping the agent decide when not to use it. However, it does not explicitly reference sibling tools or give direct comparisons like 'use this for validation, use lookup_carrier for carrier info'.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.2.0Jun 21, 2026
- First observedarea_codes_for_city
- First observedarea_codes_for_state
- First observedcheck_number_reputation
- First observedexplain_area_code_topic
- First observedis_scam_area_code
- First observedlookup_area_code
- First observedlookup_carrier
- First observedlookup_phone_number

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-06-21 16:31 across 8 tools

Disambiguation4/5

Tools have distinct purposes, but there is some overlap between lookup_area_code and lookup_phone_number (both return area code info) and between check_number_reputation and is_scam_area_code (scam-related). However, each tool serves a specific function and descriptions clarify differences.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., area_codes_for_city, lookup_area_code). No mixing of styles or vague verbs.

Tool Count5/5

8 tools is well within the ideal range of 3-15. Each tool contributes to the domain of area codes and phone number information without being excessive or insufficient.

Completeness4/5

The tool set covers listing area codes by city/state, detailed area code info, phone number parsing, carrier lookup, reputation checks, and scam context. Minor missing features like ZIP-based lookup are not essential for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Numbers Online — phone intelligence A
online.numbers
Read-only phone intelligence for AI voice agents — line type, risk, DNC, signed receipts.
Customer Data Platforms Security
42
data247 AOAuth
io.github.LogicTreeInc
Phone carrier lookup, append, verification, DNC, and fraud data services.
Customer Data Platforms Security Communication
2
dialfetch
com.dialfetch
Give your AI agent a phone: place calls, navigate IVRs, wait on hold, get structured answers.
Communication Speech Processing
2
AgentLine AOAuth
io.github.AgentLineHQ
Give AI agents a phone number. Voice calls, SMS, and phone number management for MCP clients.
Communication Autonomous Agents
2

Related MCP Servers

Telique MCP
Networking & Infrastructure Search
Ringer
A
license
A
quality
B
maintenance
Enables querying telecom routing data (LRN, CNAM, DNO, LERG, toll-free routing) directly from AI assistants like Claude, ChatGPT.
Updated 2 months ago (2026-07-14 12:39 UTC)
14
104 npm
MIT
mcp-phone
Search Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Validates phone numbers and provides country calling codes, enabling AI agents to look up international dialing codes and filter by country name, ISO code, or calling code.
Updated 4 days ago (2026-09-13 07:31 UTC)
4 npm
MIT
china-phone-mcp
Government Data Open Data
bg7iuy
F
license
Not graded
quality
B
maintenance
Enables AI agents to look up Chinese phone number carrier and location information using MIIT official data.
Updated 2 months ago (2026-07-14 07:58 UTC)
-
Veriroute Intel Lookup
Communication
verirouteintel
A
license
A
quality
A
maintenance
Tells your agent whether a number is safe to call or text right now. Live US/Canada phone data: carrier, line type, LRN, CNAM, spam/scam reputation, SMS deliverability, and TCPA 8am–9pm calling-window verdicts, plus bulk jobs. Every query is a fresh network dip, never stale cache. Free sandbox key, no card required. Pay per lookup, no minimums.
Updated 11 days ago (2026-09-06 19:14 UTC)
6
299 npm
MIT