ICPQuery-MCP
This server allows you to query China's MIIT ICP filing records and violation blacklists for websites, apps, mini-programs, and quick apps.
Query ICP Filing Information (
icp_query): Search ICP registration records by keyword (company name, domain, filing number, app name, etc.) for:web– Website filingsapp– App filings (with automatic detail enrichment)mapp– Mini-program (小程序) filings (with automatic detail enrichment)kapp– Quick app (快应用) filings (with automatic detail enrichment)Supports pagination and per-request proxy configuration
Query Illegal/Violation Blacklists (
icp_blacklist): Search the MIIT blacklist of non-compliant or illegal services by keyword for:bweb– Blacklisted websitesbapp– Blacklisted appsbmapp– Blacklisted mini-programsbkapp– Blacklisted quick apps
View Current Configuration (
config_show): Display active service settings (proxy, rate limits, timeout).Check Runtime Environment (
check_environment): Verify the Python runtime, dependencies, and supported query types to confirm the server is set up correctly.
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., "@ICPQuery-MCPquery icp filing for baidu.com"
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.
支持类型
类型 | 能力 |
网站备案 | 域名、主体名称、备案号等关键词查询 |
App 备案 | App 名称、主体名称等关键词查询,并自动补充详情 |
小程序备案 | 小程序名称、主体名称等关键词查询,并自动补充详情 |
快应用备案 | 快应用名称、主体名称等关键词查询,并自动补充详情 |
违法违规黑名单 | 网站、App、小程序、快应用黑名单查询 |
Related MCP server: crawl-mcp
快速开始
1. 安装 uv
uvx(uv 自带)是 Python 生态中 npx 的等价物——在临时隔离环境中下载并运行包,无需全局安装。
# Linux / macOS(官方安装脚本)
curl -LsSf https://astral.sh/uv/install.sh | sh
# macOS(Homebrew)
brew install uv2. 配置 MCP 客户端
将以下配置加入支持 MCP 的客户端(Claude Desktop、Cursor 等),无需预先安装 ICPQuery-MCP:
{
"mcpServers": {
"icp-query": {
"command": "uvx",
"args": ["icpquery-mcp"],
"env": {
"ICP_PROXY_TUNNEL": "http://127.0.0.1:7890"
}
}
}
}目标接口有创宇盾防护,高频访问或特定 IP 可能触发拦截。触发拦截时通过 ICP_PROXY_TUNNEL 走代理访问;不需要代理时移除 env 或将值留空。代理地址须带协议前缀(http://、https:// 或 socks5://)。
版本锁定(生产环境推荐):将
args替换为["--from", "icpquery-mcp==0.3.0", "icpquery-mcp"],避免随发布版本浮动。
频率限制已内置默认值(query 5 次/分钟、blacklist 3 次/分钟),无需额外配置。完整配置示例见 mcp.json.example 和 config.example.yml。
其他安装方式
pip:
python -m pip install -U icpquery-mcp
icpquery-mcp此时将客户端配置中的 command 改为 icpquery-mcp,args 设为 []。
pipx:
pipx install icpquery-mcp
icpquery-mcp从源码:
git clone https://github.com/helGayhub233/ICPQuery-MCP.git
cd ICPQuery-MCP
uv sync
uv run icpquery-mcp从源码运行时,推荐在客户端配置中固定项目目录:
{
"mcpServers": {
"icp-query": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/ICPQuery-MCP", "run", "icpquery-mcp"]
}
}
}配置
环境变量
环境变量统一使用 ICP_ 前缀。config_show 和 check_environment 会将已配置的代理地址显示为 <configured>,避免凭据泄漏到 MCP 对话上下文。
环境变量 | 说明 | 默认值 |
| HTTP 请求超时秒数 |
|
| 详情补全并发数(固定为串行,不可调) |
|
| 是否启用 MCP 工具频率限制 |
|
|
|
|
|
|
|
| 查询工具最大并发数(固定为串行,不可调) |
|
| 固定代理地址,例如 | — |
| 代理池 API 地址(当前保留) | — |
| 代理池大小(当前保留) | — |
| 本地 IPv6 出口轮换开关(当前保留) | — |
工具列表
工具 | 说明 | 参数 |
| 查询 ICP 备案信息 |
|
| 查询违法违规黑名单 |
|
| 查看当前运行配置 | — |
| 检查运行环境、依赖和支持类型 | — |
proxy 参数优先级高于 ICP_PROXY_TUNNEL 环境变量。
本地 CLI
除 MCP 工具外,项目还提供独立的 CLI 入口 icpquery:
icpquery check-env # 检查运行环境
icpquery config-show # 查看当前配置
icpquery query baidu.com # 查询网站备案
icpquery query 微信 -t app # 查询 App 备案
icpquery query baidu.com -t bweb # 查询网站黑名单请求限制
项目在单个 MCP server 实例内做本地保护,避免客户端并发请求直接打到目标接口。
工具 | 控制方式 |
| 同一 server 实例共享队列执行,默认每分钟 |
| 同一 server 实例共享队列执行,默认每分钟 |
App/小程序/快应用详情补全 | 串行执行 |
Qoder 等 MCP 客户端可能默认并发触发 5-10 个 tool call;同一 server(同一 ToolLimiter)实例会强制串行化,前一个查询完整结束后,下一个查询才会访问目标接口。多 server/worker 部署如需跨实例保持同样约束,须提供外部协调机制。
MCP 协议兼容性
服务使用官方 MCPServer API,同时兼容 2026-07-28 新协议和 2025-11-25 旧协议。SDK 会根据客户端自动选择 server/discover 或传统 initialize 流程,无需启动两套服务。
项目结构
src/icpquery_mcp/
server.py # MCP 入口
cli.py # 本地 CLI
core/
client.py # 工信部接口调用、token、验证码和详情补全
captcha.py # 滑块验证码偏移识别
config.py # YAML 和环境变量配置
ratelimit.py # 频率控制和单例队列保护
tools/
local_tools.py # MCP 工具与 CLI 复用封装开发
# 编译检查
python -m compileall src
# 检查运行环境
icpquery check-env
# 单元测试
python -m unittest discover -s tests -v
# 构建
uv build版本记录见 CHANGELOG.md。
注意事项
本项目仅供学习和技术研究使用,严禁用于任何商业或非法用途。
请只在合法授权范围内使用,并自行承担接口变化、验证码策略变化、目标风控或网络环境导致的失败风险。
许可证
MIT License,见 LICENSE。
Available Tools
4 toolscheck_environmentA
检查 ICPQuery-MCP 的 Python 运行环境、依赖和支持的查询类型。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions checking environment, dependencies, and supported query types, which implies a read-only operation. However, it does not detail any potential side effects or access requirements. The output schema covers return values, mitigating some lack of detail.
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 in Chinese that immediately conveys the tool's purpose. No unnecessary words.
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 zero parameters, an output schema, and sibling tools, the description provides sufficient information to understand the tool's function. No gaps are evident.
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?
There are zero parameters, so the baseline is 4. The description does not need to add parameter info, and it appropriately leaves it out.
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 checks the Python runtime environment, dependencies, and supported query types for ICPQuery-MCP. It distinguishes itself from siblings like icp_query (querying) and icp_blacklist (blacklist management).
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 on when to use this tool versus alternatives. The description does not provide context about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
config_showA
查看当前 ICP 查询服务配置。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that the tool is read-only or non-destructive. It only describes the basic operation, leaving the agent to infer behavioral traits.
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 front-loaded with the verb and resource, containing no extraneous words. Every word earns 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?
Given the tool's simplicity (0 parameters) and the presence of an output schema (though not shown here), the description is complete. It effectively states the tool's function without needing to explain return values.
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 has 0 parameters, so the schema coverage is trivially 100%. Per guidelines, baseline is 4. The description adds no parameter info, but none is needed.
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 ('view') and the resource ('ICP query service configuration'), and the sibling tools (check_environment, icp_blacklist, icp_query) are distinct in function, 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?
The description implies usage for viewing configuration but provides no explicit guidance on when to use this tool versus siblings or when not to use it. A minimal viable score is appropriate given simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
icp_blacklistC
查询工信部违法违规黑名单,支持 bweb/bapp/bmapp/bkapp。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | No | bweb | |
| proxy | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions supported types. It does not disclose authentication needs, rate limits, whether it's a search or match, or behavioral traits like pagination or data recency.
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 concise (one line) and front-loaded with purpose, but it sacrifices necessary detail, making it under-specified rather than efficiently concise.
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 queries a sensitive blacklist, the description lacks context about usage, return format (though output schema exists), and how parameters affect results. It fails to compensate for the 0% schema coverage.
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 0%, yet the description adds no meaning to parameters beyond the supported types hint for the 'type' parameter. 'name' and 'proxy' remain unexplained.
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 queries the MIIT illegal blacklist, specifying supported types (bweb/bapp/bmapp/bkapp). However, it does not differentiate from sibling icp_query, which likely serves a similar purpose for ICP records.
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 on when to use this tool versus alternatives like icp_query. The description mentions supported types but provides no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
icp_queryC
查询工信部 ICP 备案信息,支持 web/app/mapp/kapp。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| page | No | ||
| type | No | web | |
| proxy | No | ||
| page_size | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose key behaviors. It only mentions supported types but lacks information on authentication, rate limits, error handling, or result structure. This is insufficient for an agent to understand the tool's side effects or constraints.
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, concise and front-loaded with the verb 'query'. However, it is under-specified for the tool's complexity; while not verbose, it could be more informative without being lengthy.
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 has 5 parameters, no schema descriptions, and an output schema, the description is very incomplete. It does not explain pagination, default values, or output format, leaving significant gaps for an agent to use 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 input schema has 5 parameters with 0% description coverage. The description only adds context for the 'type' parameter (web/app/mapp/kapp). It fails to explain 'name', 'page', 'proxy', or 'page_size', leaving the agent guessing their purpose.
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 queries ICP filing information from the Ministry of Industry and Information Technology, and lists supported types (web/app/mapp/kapp). It is specific about the resource and actions, but does not explicitly differentiate from sibling tools like icp_blacklist.
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 by mentioning supported types, but provides no explicit guidance on when to use this tool versus alternatives (e.g., icp_blacklist). No context about prerequisites or when not to use it.
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. Dates show when Glama detected each change.
4 tool updates
v0.1.0- First observed
check_environment - First observed
config_show - First observed
icp_blacklist - First observed
icp_query
TDQS
Each tool has a clearly distinct purpose: environment check, config display, blacklist query, and ICP query. No overlap or ambiguity.
All tools follow the same verb_noun snake_case pattern (check_environment, config_show, icp_blacklist, icp_query), providing consistent and predictable naming.
With 4 tools, the set is well-scoped for its purpose: two core query tools plus two auxiliary tools for environment and configuration. Not too many or too few.
The core ICP query and blacklist functionalities are covered with support for multiple record types. Minor gaps exist (e.g., no tool to update configuration), but the surface is largely complete for its stated purpose.
Maintenance
Related MCP Connectors
MCP server for IPv4 geolocation with Chinese output: country/region/city, ISP and ASN.
11MCP server offering regulator-sourced legitimacy checks on investment entities by name or URL.
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
MCP server aggregating hot-search boards from 8 Chinese platforms (Weibo, Zhihu, Bilibili, Douyin).
21
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceMCP server for querying the FOFA API, enabling network asset search and account information retrieval.8-
- AlicenseAqualityCmaintenanceMCP server for web crawling, searching, and AI-powered content extraction, supporting single-page, batch, and full-site crawling along with text, news, image, book, and video search.82MIT
- AlicenseAqualityDmaintenanceMCP server for Metaso Search API, providing multi-scope search and webpage reading tools.2382Apache 2.0
- AlicenseNot gradedqualityBmaintenanceMCP server providing domain name checking and other web tools, accessible via MCP, REST API, and CLI for AI assistants.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/helGayhub233/ICPQuery-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server