Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Phone Carrier Detector MCP Server detect the carrier and location for 13812345678"
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.
一个用于检测中国手机号码运营商和归属地的 MCP (Model Context Protocol) 服务器。
🔍 运营商检测: 支持中国三大运营商（中国移动、中国联通、中国电信）的号码识别
📍 归属地检测: 提供省份和城市级别的归属地信息
📱 虚拟运营商: 支持虚拟运营商号码识别
🚀 批量处理: 支持批量检测多个手机号码（最多100个）
📊 详细信息: 提供运营商、归属地、前缀等详细信息
🎯 高精度: 基于真实的中国运营商号码段数据库（492,088条记录）
⚡ 高性能: 内存数据库，查询速度极快
Related MCP server: Enterprise MCP Server
运营商 | 主要号段 |
中国移动 | 134-139, 147, 150-152, 157-159, 172, 178, 182-184, 187-188, 198 |
中国联通 | 130-132, 145, 155-156, 166, 175-176, 185-186 |
中国电信 | 133, 149, 153, 173, 177, 180-181, 189, 199 |
中国广电 | 192 |
中国铁通 | 174 |
git clone https://github.com/dahuangbaojian/sms-mcp-server.git
cd sms-mcp-server项目使用 Python 标准库实现，无需额外依赖。如需运行测试：
pip install pytest配置 MCP 客户端（如 Claude Desktop）:
{
"mcpServers": {
"phone-carrier-detector": {
"command": "python",
"args": ["mcp_server.py"],
"env": {}
}
}
}重启客户端，然后就可以使用以下工具：
请帮我检测手机号码 13812345678 的运营商和归属地信息请帮我批量检测这些号码的运营商和归属地：13812345678, 18687654321, 13312345678检测单个手机号码的运营商和归属地信息。
参数:
phone_number (string): 要检测的手机号码（11位数字）
示例输出:
{
"success": true,
"phone_number": "13812345678",
"carrier": "China Mobile",
"carrier_cn": "移动",
"province": "江苏",
"city": "连云港",
"prefix": "1381234"
}批量检测多个手机号码的运营商和归属地信息。
参数:
phone_numbers (array): 要检测的手机号码列表（最多100个）
示例输出:
{
"success": true,
"total": 3,
"results": [
{
"success": true,
"phone_number": "13812345678",
"carrier": "China Mobile",
"province": "江苏",
"city": "连云港"
}
]
}项目使用真实的中国手机号归属地数据库，包含：
492,088 条记录
覆盖所有主要运营商
精确到城市级别
实时更新
# 运行所有测试
python tests/run_tests.py --all
# 运行单元测试
python tests/run_tests.py --unit
# 运行集成测试
python tests/run_tests.py --integration
# 运行数据解析器测试
python tests/run_tests.py --data# 从原始数据文件生成数据库
python parse_phone_data.pypython mcp_server.py.
├── mcp_server.py # MCP协议主服务
├── parse_phone_data.py # 数据解析脚本
├── data/ # 数据目录
│ ├── 手机号归属地1219.txt # 原始数据文件
│ └── phone_database.json # 解析后的数据库
├── tests/ # 测试目录
│ ├── test_mcp_server.py # 单元测试
│ ├── test_mcp_integration.py # 集成测试
│ ├── test_data_parser.py # 数据解析测试
│ └── run_tests.py # 测试运行器
├── package.json # MCP配置
├── mcp-metadata.json # MCP元数据
└── README.md # 项目说明Python 3.8+
MCP Protocol 2024-11-05
JSON-RPC 2.0
正则表达式 - 号码格式验证
内存数据库 - 高性能查询
内存占用: ~100MB（包含49万条记录）
查询速度: O(1) 哈希表查找
并发支持: 异步处理，支持高并发
错误处理: 完善的错误处理和参数验证
欢迎提交 Issue 和 Pull Request！
Fork 项目
创建功能分支 (git checkout -b feature/AmazingFeature)
提交更改 (git commit -m 'Add some AmazingFeature')
推送到分支 (git push origin feature/AmazingFeature)
打开 Pull Request
本项目采用 MIT 许可证 - 查看 LICENSE 文件了解详情。
初始版本发布
支持中国三大运营商检测
支持归属地检测（省份+城市）
支持虚拟运营商检测
支持批量号码检测
基于真实数据库（49万+记录）
完整的 MCP 协议实现
全面的测试覆盖
如果你遇到任何问题或有建议，请：
查看 Issues
创建新的 Issue
发送邮件到 huangjian@ztinfo.cn
⭐ 如果这个项目对你有帮助，请给它一个星标！
Detect carriers and locations for multiple phone numbers
| Name | Required | Description | Default |
|---|---|---|---|
| phone_numbers | Yes | List of phone numbers to detect (max 100) |
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 tool's function but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what the detection entails (e.g., carrier lookup, location mapping). This leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that directly states the tool's purpose without any redundant or unnecessary information. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detect' entails (e.g., output format, accuracy), behavioral traits like performance or constraints, or how it differs from the sibling tool. For a tool with no structured support, more context is needed.
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 description coverage is 100%, with the parameter 'phone_numbers' fully documented in the schema (including the max 100 limit). The description adds no additional semantic meaning beyond implying multiple numbers, so it meets the baseline of 3 where the schema handles parameter documentation effectively.
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 ('detect') and target ('carriers and locations for multiple phone numbers'), distinguishing it from the sibling 'detect_carrier' by specifying 'multiple phone numbers' for batch processing. However, it doesn't explicitly mention the batch nature beyond 'multiple', which could be more specific.
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 the sibling 'detect_carrier' (e.g., for single vs. multiple numbers), nor does it mention any prerequisites, limitations, or alternative scenarios. It lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect carrier and location for a single phone number
| Name | Required | Description | Default |
|---|---|---|---|
| phone_number | Yes | Phone number to detect (11 digits) |
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. It states the tool detects carrier and location, but doesn't cover aspects like rate limits, authentication needs, error handling, or what the output looks like (e.g., format, possible values). For a tool with no annotation coverage, this is a significant gap in 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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the core functionality and appropriately sized for a simple tool, earning a top score for conciseness.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., carrier name, location details, error responses) or behavioral traits like performance or limitations. For a detection tool with no structured output, the description should provide more context to be fully helpful.
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% description coverage, with the parameter 'phone_number' documented as 'Phone number to detect (11 digits).' The description doesn't add any additional meaning beyond this, such as format examples or validation rules. Given the high schema coverage, the 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 states the tool's purpose: 'Detect carrier and location for a single phone number.' It specifies the verb ('detect'), resource ('carrier and location'), and scope ('single phone number'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from its sibling 'batch_detect_carriers' beyond implying single vs. batch processing.
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 its sibling 'batch_detect_carriers.' It mentions 'single phone number,' which hints at usage for individual queries, but lacks explicit alternatives, prerequisites, or exclusions. This leaves the agent without clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one handles single phone numbers and the other handles batches of phone numbers. There is no overlap or ambiguity between them, as the descriptions explicitly differentiate between single and multiple inputs.
Both tools follow a consistent verb_noun pattern with 'detect_carrier' as the base, extended to 'batch_detect_carriers' for the plural/multiple version. The naming is predictable and adheres to snake_case throughout.
With only 2 tools, the server feels thin for a carrier detection domain, as it lacks additional operations like validation, formatting, or carrier metadata lookup. However, the core functionality is covered, making it borderline but not severely lacking.
The server provides basic detection for single and batch inputs, but there are notable gaps such as phone number validation, carrier information retrieval (e.g., network types), or error handling tools. The surface is functional but incomplete for broader carrier-related tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Look up Chinese phone number carrier, province, and city from official MIIT allocation data.
Phone carrier lookup, append, verification, DNC, and fraud data services.
Live phone intelligence for AI agents: carrier, line type, LRN, CNAM, spam reputation, bulk jobs.
China facts a server outside China cannot get: real mainland reachability, 调休 holidays, ID/phone val
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dahuangbaojian/sms-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
