This server provides comprehensive industrial chain analysis capabilities powered by HandaaS data, enabling enterprise research, supply chain exploration, IP analysis, bidding intelligence, and policy research.
Enterprise Information & Discovery
Fuzzy keyword search for enterprises by name, brand, product, or person
Query registration details, operating status, industry, capital, and business scope
Retrieve enterprise profiles, business info, and tags (financing stage, scale, high-tech, "Specialized & New")
Access shareholder info, external investments, branches, and key personnel
Supply Chain Analysis
Discover downstream products and industries from an upstream product keyword
Find downstream enterprises filtered by region, trade type, scale, listing status, capital, and more
Advanced Enterprise Filtering
Count or retrieve lists of enterprises using complex filter conditions (operating status, region, industry, type, founding date, registered/paid-in capital)
Supports structured filter groups with must/should logic
Patent & IP Analysis
Search patents by keyword, application number, applicant, or agency; filter by patent type
Analyze an enterprise's patent portfolio: status distribution, application/authorization trends, and type breakdown
Bidding & Procurement Intelligence
Search and filter bidding announcements by keyword, type, region, time range, and amount
Query enterprise bid-winning stats, full bidding history, tender statistics, and procurement distribution
Query planned construction project announcements
Policy Research
Search policies by keyword, type, issuing agency, region, and date range
Retrieve full policy details including text, attachments, grants, and deadlines
Analyze an enterprise's approved government projects, subsidy amounts, and annual trends
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., "@industry-chain-mcp-server search for companies specializing in AI chips"
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.
🔍 企业关键词模糊搜索
🏢 企业基础信息与业务标签查询
🔗 供应链下游产品与企业查询
📄 专利信息搜索与企业专利统计
📊 招投标信息与采购统计分析
📜 政策搜索、政策详情与企业获批政策项目统计
🧭 高级企业筛选
🧩 高筛字段目录、单字段用法与枚举路径 Resources
Related MCP server: cisp-mcp
Python 3.10+
依赖包：python-dotenv, requests, mcp
git clone https://github.com/handaas/industry-chain-mcp-server
cd industry-chain-mcp-serverpython3 -m venv mcp_env
source mcp_env/bin/activate
python -m pip install -r requirements.txt
python -m pip install -e .py -3 -m venv mcp_env
Set-ExecutionPolicy -Scope Process Bypass
.\mcp_env\Scripts\Activate.ps1
python -m pip install -r requirements.txt
python -m pip install -e .复制环境变量模板并配置：
cp .env.example .env
nano .envCopy-Item .env.example .env
notepad .env编辑 .env 文件，配置以下环境变量：
INTEGRATOR_ID=your_integrator_id
SECRET_ID=your_secret_id
SECRET_KEY=your_secret_keypython server/mcp_server.py streamable-httppython .\server\mcp_server.py streamable-http服务将在 http://localhost:8000 启动。
如果 8000 端口已被占用，可以指定本地端口：
macOS / Linux：
MCP_PORT=8011 python server/mcp_server.py streamable-httpWindows PowerShell：
$env:MCP_PORT = "8011"
python .\server\mcp_server.py streamable-http对应 MCP 地址为 http://127.0.0.1:8011/mcp。
健康检查：
macOS / Linux：
curl http://127.0.0.1:8011/health
# 或 /api/healthWindows PowerShell：
Invoke-RestMethod http://127.0.0.1:8011/health健康检查中的 ok 表示服务进程可访问，ready / credentials_configured 表示本地 HandaaS 凭证已经配置；响应不会返回任何凭证内容。
安装为命令后也可以运行：
handaas-industry-chain-mcp streamable-http{
"mcpServers": {
"industry-chain-mcp-server": {
"type": "streamableHttp",
"url": "http://127.0.0.1:8000/mcp"
}
}
}先查询安装后的命令位置：
macOS / Linux：
command -v handaas-industry-chain-mcpWindows PowerShell：
(Get-Command handaas-industry-chain-mcp).Source把输出的完整命令路径填入 command，不需要手工拼接虚拟环境路径：
{
"mcpServers": {
"industry-chain-mcp-server": {
"command": "<上一步输出的 handaas-industry-chain-mcp 完整路径>",
"args": ["stdio"],
"env": {
"INTEGRATOR_ID": "your_integrator_id",
"SECRET_ID": "your_secret_id",
"SECRET_KEY": "your_secret_key"
}
}
}
}{
"mcpServers": {
"industry-chain-mcp-server":{
"type": "streamableHttp",
"url": "https://mcp.handaas.com/industry-chain/industry_chain?token={token}"
}
}
}本仓库只负责把 HandaaS 已有数据产品封装为 MCP 工具。产业链层级拆解、ES 条件生成、企业证据评分、节点挂链和报告渲染由 industry-chain-processing-skill 完成，不会在 MCP 中重复注册工作流工具。
使用官方 Remote MCP 时，Skill 只需要平台 token：
macOS / Linux：
git clone https://github.com/handaas/industry-chain-processing-skill.git
cd industry-chain-processing-skill
python -m pip install -r requirements.txt
export INDUSTRY_CHAIN_MCP_TOKEN="<platform-token>"
python industry-chain-processing/scripts/mcp_client.py list-toolsWindows PowerShell：
git clone https://github.com/handaas/industry-chain-processing-skill.git
Set-Location industry-chain-processing-skill
python -m pip install -r requirements.txt
$env:INDUSTRY_CHAIN_MCP_TOKEN = "<platform-token>"
python .\industry-chain-processing\scripts\mcp_client.py list-tools使用本地 MCP 时，先启动本服务，再给 Skill 设置本地地址：
macOS / Linux：
终端 1（MCP 仓库）：
./start_mcp_server.sh终端 2（Skill 仓库）：
export INDUSTRY_CHAIN_MCP_URL="http://127.0.0.1:8000/mcp"
cd ../industry-chain-processing-skill
python industry-chain-processing/scripts/mcp_client.py list-toolsWindows PowerShell：
PowerShell 窗口 1（MCP 仓库）：
python .\server\mcp_server.py streamable-httpPowerShell 窗口 2（Skill 仓库）：
$env:INDUSTRY_CHAIN_MCP_URL = "http://127.0.0.1:8000/mcp"
Set-Location ..\industry-chain-processing-skill
python .\industry-chain-processing\scripts\mcp_client.py list-toolsRemote token 模式不需要在 Skill 中再次配置 integrator_id、secret_id、secret_key 或各个商品 ID。本地 MCP 模式的凭证只保存在本仓库未提交的 .env 中。
功能: 企业关键词模糊查询
根据提供的企业名称、人名、品牌、产品、岗位等关键词模糊查询相关企业列表。
参数:
matchKeyword (必需): 匹配关键词 - 查询各类信息包含匹配关键词的企业
pageIndex (可选): 页码 - 从1开始
pageSize (可选): 分页大小 - 一页最多获取50条数据
返回值:
total: 总数
resultList: 企业列表
其他企业基础信息、命中原因等
功能: 企业基础工商信息查询
根据企业名称、注册号、统一社会信用代码或企业ID查询企业工商基础信息。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
name: 企业名称
operStatus: 经营状态
business: 经营范围
industry: 行业信息
regCapital: 注册资本
其他工商基础字段
功能: 企业简介查询
根据企业标识查询企业简介信息。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
desc: 企业简介描述
功能: 企业标签查询
查询企业主营业务、融资、规模、高新、专精特新等标签。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
businessTags: 主营业务标签
financingSeries: 融资轮次
enterpriseScaleAlgValue: 企业规模
isHighTechEnterprise: 是否高新企业
isSpecializedAndNew: 是否专精特新
其他企业标签字段
功能: 企业控股股东信息查询
根据企业标识查询企业控股股东信息。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
holderList: 股东列表
stockHolderList: 最新公示股东列表
功能: 企业对外投资信息查询
根据企业标识查询企业对外投资信息。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
pageIndex (可选): 页码 - 从1开始
pageSize (可选): 分页大小
返回值:
total: 总数
resultList: 对外投资企业列表
功能: 企业分支机构信息查询
根据企业标识查询企业分支机构信息。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
pageIndex (可选): 页码 - 从1开始
pageSize (可选): 分页大小
返回值:
total: 总数
resultList: 分支机构列表
功能: 企业主要人员信息查询
根据企业标识查询企业主要人员信息。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
pageIndex (可选): 页码 - 从1开始
pageSize (可选): 分页大小
返回值:
total: 总数
resultList: 主要人员列表
功能: 下游产品目录查询
根据供应链产品关键词查询下游产品目录。
参数:
keywords (必需): 供应链产品关键词，多个词中间用英文逗号分隔
返回值:
total: 总数
resultList: 下游产品目录
industry: 下游行业名称
products: 下游产品列表
功能: 下游企业清单查询
根据具体产品名称查询下游企业列表。
参数:
keywords (必需): 供应链产品关键词，多个词中间用英文逗号分隔
mainProducts (可选): 下游产品，多个词中间用英文逗号分隔
isForeignTrade (可选): 是否外贸企业 - 是、否
factoryInspectionType (可选): 是否验厂 - 是、否
foundTimeStart (可选): 成立时间开始，格式 yyyy-mm-dd
foundTimeEnd (可选): 成立时间截至，格式 yyyy-mm-dd
address (可选): 地区，例如“广东省,深圳市”或“广东省”
isTopEnterprise (可选): 是否500强企业 - 是、否
isHighTechEnterprise (可选): 是否高新企业 - 是、否
isGazelleEnterprise (可选): 是否瞪羚企业 - 是、否
isUnicornEnterprise (可选): 是否独角兽企业 - 是、否
hasStock (可选): 是否上市企业 - 是、否
hasDevice (可选): 是否机械设备企业 - 是、否
hasPack (可选): 是否包装包材企业 - 是、否
regCapitalMin (可选): 注册资本最小值，单位万元
regCapitalMax (可选): 注册资本最大值，单位万元
pageIndex (可选): 页码 - 从1开始
pageSize (可选): 分页大小
返回值:
total: 总数
resultList: 下游企业列表
enterpriseId: 企业ID
name: 企业名称
city: 城市
province: 省份
mainProducts: 主营产品
factoryRecommendReason: 推荐理由
regCapital: 注册资本信息
功能: 高级筛选获取企业数量
通过旷湖高筛条件组查询符合要求的企业数量。filter 可直接传 JSON object，也可传 JSON 字符串；MCP 会校验并转换为高筛产品要求的紧凑 JSON 字符串。旧版扁平字段继续兼容。
参数:
filter (推荐): 顶层直接包含 must / should 的高筛条件组
operStatus (可选): 营业状态，接受逗号分隔字符串、JSON 字符串数组或字符串数组，例如 "营业,吊销"、["营业","吊销"] 或 "!吊销"
address (可选，仅旧版扁平模式): 上游要求二维地区路径 JSON 字符串，例如 [["广东省"]]、[["北京市"],["广东省","广州市"]]。也可传 "广东省"、"广东省,深圳市" 或对应数组，MCP 会自动校验并转换
industries (可选): 行业筛选条件，输入形式同 operStatus
enterpriseType (可选): 企业类型筛选条件，输入形式同 operStatus
name (可选): 企业名称包含/排除条件，输入形式同 operStatus
foundTimeGte (可选): 成立时间起始，必须是有效的 yyyy-mm-dd
foundTimeLte (可选): 成立时间截至，必须是有效的 yyyy-mm-dd
regCapitalRmbGte (可选): 注册资本最小值，单位万元，接受 JSON number 或数值字符串
regCapitalRmbLte (可选): 注册资本最大值，单位万元，接受 JSON number 或数值字符串
totalPayAmountGte (可选): 实缴资本最小值，单位万元，接受 JSON number 或数值字符串
totalPayAmountLte (可选): 实缴资本最大值，单位万元，接受 JSON number 或数值字符串
两个旧版高级筛选商品共用同一套适配逻辑：多值数组转换为上游逗号分隔字符串，address 转换为紧凑二维路径 JSON，日期和非负数值在调用前校验，且下限不能大于上限。非法参数返回带商品身份的结构化 参数错误，不会调用上游。
使用 filter 时不要同时传扁平字段。完整条件组查询产品 ID 为 690dcb1b9c9dc8d0ff3c40eb，上游只接收 filter、pageIndex、pageSize；页码从 1 开始，每页最多 50 条。
返回值:
total: 符合条件的企业数量
功能: 高级筛选获取企业清单
通过高级筛选条件查询全国符合要求的企业清单。推荐直接传入 filter 条件组；完整条件组产品支持 pageIndex / pageSize 分页。旧版扁平模式可分页获取最多500条。
参数:
filter (推荐): JSON object 或 JSON 字符串
operStatus / industries / enterpriseType / name 支持逗号分隔字符串、JSON 字符串数组或字符串数组；日期、金额参数的校验和适配同 advanced_filter_get_enterprise_count
address (旧版扁平模式): 接受以下输入，传给上游时统一转换为紧凑二维路径 JSON 字符串：
省份："广东省"、["广东省"] 或 [["广东省"]] -> [["广东省"]]
省市："广东省,深圳市" 或 [["广东省","深圳市"]]
多地区："北京市;广东省,广州市" 或 [["北京市"],["广东省","广州市"]]
直辖市可单独传 "北京市"、"上海市"、"天津市"、"重庆市"；非直辖市不能脱离省份单独传入，例如不要只传 "深圳市"
pageIndex / pageSize: 页码从1开始；旧版扁平模式一页最大10条，filter 模式一页最大50条。filter 模式会把两个分页字段传给上游，且上游参数严格限制为 filter、pageIndex、pageSize
查询“广东省营业状态且名称包含无人机”的最简扁平调用为：
{"operStatus":"营业","address":"广东省","name":"无人机"}MCP 会把其中的 address 转换为上游所需的 [["广东省"]]。若使用推荐的 filter 模式，则省级树形值不带“省”，且不能再同时传扁平参数：
{"filter":{"must":[{"operStatus_v2":[{"eq":[["营业"]]}]},{"address":[{"eq":[["广东"]]}]},{"name":[{"in":["无人机"]}]}]}}返回值:
total: 总数
resultList: 企业清单列表
顶层只允许 must / should，不要添加 filter、condition、query 包装层。
字段条件格式为 {"字段名":[{"操作符":值}]}。
推荐每个 must / should 数组项只放一个字段；若传入 {"字段A":[...],"字段B":[...]}，MCP 会按原顺序自动拆分为两个单字段条件再校验。
支持 in、nin、eq、neq、gte、lte、gt、lt、exist。
高筛不会执行顶层 must_not。排除条件必须使用字段级 nin / neq 并放入 must。
address、industriesV2、operStatus_v2、enterpriseType 的 eq / neq 使用路径数组的数组。
addressValue 是详细地址关键词字段，使用 in / nin 字符串数组，不要与注册地址树形字段混用。
MCP 当前提供 23 个 HandaaS 数据工具，另提供只读 Resources 帮助模型在组装 filter 前查询支持的维度。Resources 只公开随包发布的平台字段配置，不执行查询、不消耗产品调用次数，也不替代伴随 Skill 的条件规划。
Resource | 用途 |
| 常用维度分组、操作符、输入示例和常见组合 |
| 369 个高筛字段的完整目录、分类、操作符和 |
| 单字段的操作符、输入约束、示例条件、枚举样例及枚举资源地址 |
| 指定枚举源或树形选项源的全部合法路径 |
推荐流程：
读取 handaas://high-screen/guide 选择常用筛选维度。
对不熟悉的字段读取 handaas://high-screen/fields/{field}。
若字段详情包含 options_resource，继续读取该资源确认合法枚举路径。
由 产业链处理 Skill 组装 must / should 条件。
调用 advanced_filter_get_enterprise_list(filter=...) 执行现有高筛产品。
常用维度包括：
企业基础：name、operStatus_v2、address、addressValue、enterpriseType、foundTime、industriesV2
主营业务与产品：businessKeywords（业务关键词）、businessTags（主营业务）、business（经营范围）、desc（企业简介）、ecShopProducts（电商主营产品）、brandProductList（品牌主营产品）
规模资本：regCapitalRmb、totalPayAmount、enterpriseScaleAlgV2、annualTurnoverAlgV2、arInsuranceNumber
成长资质：isHighTechEnt、isSpecializedAndNewV2、isSpecializedAndNewGiantV2、isUnicornEnt、hasStock、isTopEnterprise、financingSeries
知识产权与市场：hasPatent、patentNumber、patentNameList、hasBidding、biddingAnncTitleList
高筛字段契约随 Python 包发布，不依赖部署机器上的额外文件：
server/config/high_screen_fields.json：369 个字段的中文名称、分类、action.type、input.type、单位、关键词数量、数值范围、枚举来源和允许操作符。
server/config/high_screen_options.json：97 组枚举和树形选项，包括注册地址、行业、企业类型、营业状态、专利类型和招投标角色等。
当前平台配置版本：0.14.3。
组装 filter 时 MCP 会依据配置执行：
拒绝未知字段，并返回相近字段名建议。
按字段控件限制操作符，例如存在型字段只允许 exist，范围字段允许 gte/lte/gt/lt/eq/neq。
对语义明确的错误安全修正，例如树形枚举 in → eq、关键词字段 eq → in、字符串关键词 → 字符串数组。
校验树形路径是否存在于平台枚举中，避免省市层级、行业层级或枚举值传错。
校验字段配置中的关键词数量、总长度、数字上下限、日期格式和预设条件。
将修正后的条件序列化为上游要求的紧凑 params.filter JSON 字符串。
不能确定语义的错误不会猜测修正，例如未知字段、错误省市组合、无效行业路径和超出字段限制的关键词会直接返回 参数错误 与具体 JSON 路径。
注册地址示例：
{"must":[{"address":[{"eq":[["广东"]]}]}]}深圳市示例：
{"must":[{"address":[{"eq":[["广东","深圳市"]]}]}]}在 filter.address 内，MCP 也会把 "广东省"、"广东省,深圳市" 或 ["广东省","深圳市"] 归一化为上述无“省”后缀的平台树形路径；多个地区字符串用分号分隔，例如 "广东省,深圳市;江苏省,苏州市"。城市不能脱离省级路径单独传入。注意这与扁平 address 最终传给旧版产品的 [["广东省"]] 格式不同。
工商、业务关键词与地址组合示例：
{
"must": [
{"operStatus_v2": [{"eq": [["营业"]]}]},
{"enterpriseType": [{"neq": [["个体户"]]}]},
{"address": [{"eq": [["广东"]]}]},
{"name": [{"nin": ["贸易", "培训"]}]},
{"should": [
{"businessKeywords": [{"in": ["工业机器人", "机器人控制器"]}]},
{"businessTags": [{"in": ["工业机器人", "机器人控制器"]}]},
{"business": [{"in": ["工业机器人", "机器人控制器"]}]},
{"desc": [{"in": ["工业机器人", "机器人控制器"]}]},
{"ecShopProducts": [{"in": ["工业机器人", "机器人控制器"]}]}
]}
]
}功能: 专利信息搜索
通过输入专利名称、申请号、申请人或代理机构等信息进行精准或模糊搜索，并按指定专利类型进行筛选。
参数:
matchKeyword (必需): 专利名称/专利申请号/公布公告号/申请人/代理机构
pageSize (可选): 分页大小 - 一页最多获取50条数据
patentType (可选): 专利类型 - 发明申请、实用新型、发明授权、外观设计
keywordType (可选): 搜索方式 - 专利名称、申请号/公开号、申请人、代理机构
pageIndex (可选): 页码 - 从1开始
返回值:
total: 专利总数
resultList: 专利列表
功能: 企业专利统计分析
根据企业信息查询企业专利情况，包括专利状态分布、专利申请与授权趋势、按专利类型分布等。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
patentDivAppLegalStat: 专利状态分布
patentTypeAppTimeStat: 专利申请趋势
patentTypePubTimeStat: 专利授权趋势
patentTypeStat: 专利类型分布
功能: 企业中标统计分析
根据企业名称、统一社会信用代码等获取企业标讯信息中中标统计项。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
winbidAmountStatList: 中标金额分布
winbidAreaStat: 区域分布
winbidStatList: 中标标的分布
winbidTrend: 中标趋势
功能: 企业招投标信息查询
查询企业参与的招投标信息，包括公告类型、项目地区、公告详情及相关企业信息。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
pageSize (可选): 分页大小 - 一页最多获取50条数据
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
pageIndex (可选): 页码 - 从1开始
返回值:
total: 总数
resultList: 招投标信息列表
功能: 企业招标统计分析
根据企业名称、统一社会信用代码等获取企业标讯信息中招标统计项。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
tenderAmountStatList: 招标金额分布
tenderAreaStat: 区域分布
tenderStatList: 招标标的分布
tenderTrend: 招标趋势
功能: 企业采购统计分析
根据企业名称或ID获取企业采购统计信息，包括采购产品分布、采购区域分布等。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
purchasingProductStatList: 采购产品分布
purchasingAreaStatList: 采购区域分布
功能: 招投标公告搜索
查询和筛选招投标公告信息，支持按公告类型、地区、发布时间、搜索模式、项目金额等过滤。
参数:
matchKeyword (可选): 搜索关键词
biddingType (可选): 招标类型JSON数组字符串，例如 ["招标公告","中标公告"]
biddingRegion (可选): 项目地区JSON数组字符串，例如 [["福建省","厦门市"]]
biddingAnncPubStartTime (可选): 公告发布开始时间，格式 yyyy-mm-dd
biddingAnncPubEndTime (可选): 公告发布结束时间，格式 yyyy-mm-dd
searchMode (可选): 搜索模式 - 标题匹配、标的物匹配、全文匹配
biddingProjectMaxAmount (可选): 项目金额最大值，单位万元
biddingPurchasingType (可选): 招标单位类型，例如“政府,学校”
biddingProjectMinAmount (可选): 项目金额最小值，单位万元
pageIndex (可选): 页码
pageSize (可选): 分页大小 - 一页最多获取50条
返回值:
total: 总数
resultList: 招投标公告列表
功能: 企业拟建公告查询
查询企业拟建公告信息，包括项目内容、建设地点、待采设备、发布时间等。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
pageIndex (可选): 页码 - 从1开始
pageSize (可选): 分页大小 - 一页最多获取50条数据
keywordType (可选): 主体类型 - name、nameId、regNumber、socialCreditCode
返回值:
total: 总数
resultList: 拟建项目列表
功能: 政策搜索
根据关键词、政策类型、发布机构、地区和发布时间，搜索政策法规、申报指南或公示公告。
参数:
matchKeyword (必需): 政策关键词，例如“智能网联汽车”“自动驾驶”“低空经济”“机器人”
pnType (可选): 全部 / 申报指南 / 公示公开 / 其他政策
agency (可选): 发布机构
address (可选): 地区，支持 [["福建省"],["贵州省","安顺市","平坝县"]]、"广东省"、"广东省,深圳市"、"国家部委"、"北京/上海/天津/重庆"
policyPubStartTime / policyPubEndTime (可选): 发布时间范围，格式 yyyy-mm-dd
pageSize / pageIndex (可选): 分页参数
返回值:
total: 总数
resultList: 政策列表，通常包含 pnId、pnTitle、pnAgency、pnType、pnPublishDate、pnRegion、pnText
功能: 政策详情查询
根据政策 ID 查询政策详情，包括发布机构、正文、原文链接、附件、关联项目、资助金额和申报时间等。
参数:
matchKeyword (必需): 政策 ID
功能: 企业获批政策项目统计
根据企业名称、注册号、统一社会信用代码或企业 ID，查询企业获批国家/省/市/区各级政策项目、主管机构、补贴金额和年度趋势。
参数:
matchKeyword (必需): 企业名称/注册号/统一社会信用代码/企业id
keywordType (可选): name、nameId、regNumber、socialCreditCode
产业研究: 使用企业搜索、企业业务信息和企业标签识别产业链相关企业
供应链拓展: 根据上游产品查询下游产品和下游企业清单
招商线索挖掘: 结合高级筛选、企业标签、供应链企业清单发现潜在招商对象
技术与创新分析: 查询企业专利信息和专利统计，评估企业技术储备
项目与采购分析: 查询招投标、拟建项目和采购统计，判断企业项目活跃度
区域政策分析: 查询某产业在国家部委和各省市的政策法规、申报指南、公示公告，对比支持方向和政策强度
企业画像补全: 查询工商、简介、标签、股东、投资、分支机构、主要人员和获批政策项目统计
企业全称要求: 在调用需要企业全称的接口时，如果没有企业全称则先调用企业关键词模糊查询接口获取企业全称或企业ID
分页限制: 列表类接口通常一页最多获取50条数据；旧版扁平高级筛选一页最大10条且最多获取500条。完整 filter 条件组支持分页，pageIndex 从1开始，pageSize 最大50
复杂参数格式: 高筛 filter 可传 JSON object 或字符串；注册地址使用省/市/区路径，详细地址关键词使用 addressValue in/nin；格式错误会返回产品、字段和 JSON 路径
Remote优先: 推荐使用官方Remote服务，客户端只需要配置平台token
凭证安全: 本地启动时不要提交 .env、secret_id、secret_key 或签名
接口权限: 可用数据取决于账号已开通的数据产品权限
费用提醒: 真实查询可能产生接口调用费用，请按平台开通规则使用
帮我查找包含“eVTOL”的企业信息
搜索与“人形机器人”相关的企业列表
查询名称或产品中包含“减速器”的公司
查询“动力电池”的下游产品目录
帮我看“碳纤维材料”可以关联哪些下游产品
根据“激光雷达”查询下游行业和产品
查询“动力电池”的下游企业清单
帮我找广东省内“电机控制器”相关下游企业
查询“工业机器人”相关的高新技术下游企业
使用 address eq [["广东"]] 查询广东省营业中的无人机相关企业
组合 industriesV2、businessKeywords、business 与 desc 筛选高端装备制造企业
使用 address eq [["广东","深圳市"]] 和 addressValue in ["南山区"] 查询深圳南山区机器人企业
搜索关键词为“飞控系统”的专利信息
查询某公司申请的所有发明专利
查找申请号为某编号的专利详情
分析某公司的专利申请趋势
查询某企业的专利类型分布统计
查看某企业专利状态分布
查询某企业最近参与的招投标信息
查看某公司中标项目和招标项目记录
查询某企业在低空经济相关项目中的招投标情况
搜索标题包含“无人机”的中标公告
查询广东省最近发布的低空经济招标公告
查找项目金额大于1000万元的数据中心招标项目
查询国家部委和广东省最近发布的“智能网联汽车”相关政策
对比北京、上海、江苏、广东在“自动驾驶”方向的政策重点
搜索“低空经济”相关申报指南和公示公告
查询某企业近年获批政策项目数量和补贴金额趋势
分析某企业政策项目主要来自哪些主管机构
不需要真实凭证即可运行单元测试：
python -m pip install -e '.[dev]'
python -m unittest discover -s tests -v
python -m py_compile server/*.py
python -m build真实接口联调前，请确认 .env 只保存在本地，并从最小 pageSize 开始测试。项目 CI 会在 Python 3.10 和 3.12 上执行测试。
贡献说明见 CONTRIBUTING.md，安全问题处理方式见 SECURITY.md。
通过高级筛选条件查询全国符合要求的企业数量。该接口只返回数量。
请求参数:
operStatus: 营业状态，例如“营业,吊销”或“!吊销”
address: 地址筛选条件
industries: 行业筛选条件
enterpriseType: 企业类型筛选条件
name: 企业名称筛选条件
foundTimeGte/foundTimeLte: 成立时间范围
regCapitalRmbGte/regCapitalRmbLte: 注册资本范围，单位万元
totalPayAmountGte/totalPayAmountLte: 实缴资本范围，单位万元
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| address | No | ||
| pageSize | No | ||
| pageIndex | No | ||
| industries | No | ||
| operStatus | No | ||
| foundTimeGte | No | ||
| foundTimeLte | No | ||
| enterpriseType | No | ||
| regCapitalRmbGte | No | ||
| regCapitalRmbLte | No | ||
| totalPayAmountGte | No | ||
| totalPayAmountLte | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively communicates the key behavioral trait: it only returns a count. However, it lacks details on error handling, rate limits, or what happens with no matching results.
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, using a single paragraph with a bullet-like parameter list. It is front-loaded with purpose, but the parameter list could be more structured (e.g., grouping related parameters like time ranges).
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 13 parameters and no output schema, the description covers all parameters with examples and units, and states the return behavior. It is mostly complete, though missing information on optional vs required usage and result format.
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 provides zero description coverage, so the description carries full burden. It fully compensates by listing each parameter with examples and units (e.g., 单位万元), adding significant meaning beyond the bare schema.
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: querying the number of enterprises nationwide based on advanced filter criteria, and explicitly notes it only returns the count. This distinguishes it from the sibling tool 'advanced_filter_get_enterprise_list', which likely returns a list.
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 when only a count is needed, but does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or exclusions. With 23 siblings, more explicit guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过高级筛选条件查询全国符合要求的企业清单列表，最多返回500条。
请求参数同 advanced_filter_get_enterprise_count。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| address | No | ||
| pageSize | No | ||
| pageIndex | No | ||
| industries | No | ||
| operStatus | No | ||
| foundTimeGte | No | ||
| foundTimeLte | No | ||
| enterpriseType | No | ||
| regCapitalRmbGte | No | ||
| regCapitalRmbLte | No | ||
| totalPayAmountGte | No | ||
| totalPayAmountLte | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must shoulder the burden of behavioral disclosure. It only reveals a maximum return of 500 entries, but omits any information about authentication, rate limits, data freshness, pagination details, side effects, or permissions. This is minimal disclosure for a tool that likely mutates nothing but still requires 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 concise (two sentences) and front-loads the core purpose and limit. However, it references another tool for parameters, which could be considered a slight overhead. It is efficient but could include a brief summary of key parameters without becoming verbose.
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 complexity (13 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, pagination (beyond limit), error handling, default behavior, and parameter meanings. The reliance on a sibling tool for parameter info creates a dependency that reduces completeness.
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 has 13 parameters with 0% description coverage, and the description adds no parameter explanations. The statement 'request parameters are the same as advanced_filter_get_enterprise_count' defers completely to another tool, leaving agents without immediate access to parameter semantics. This scores a 1 as the description fails to add any value for parameter understanding.
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: query a list of enterprises via advanced filters, returning up to 500 entries. It explicitly distinguishes itself from the sibling tool advanced_filter_get_enterprise_count by mentioning 'list' vs 'count', making the differentiation clear.
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 when a list of enterprises is needed (as opposed to just the count), but it does not provide explicit guidance on when to use this tool versus the many other enterprise-related sibling tools, nor does it include any when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业参与的招投标信息。
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | ||
| pageIndex | No | ||
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as pagination behavior, authentication needs, result limits, or data freshness. The agent is left guessing about 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?
Description is extremely concise (one short sentence). While not verbose, it lacks necessary detail for a tool with multiple parameters. Conciseness is positive but here it under-specifies.
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 no annotations, no output schema, and 0% parameter documentation, the description is wholly incomplete. Missing details on return format, error handling, and usage constraints.
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 description coverage is 0%. Description does not explain the meaning or usage of any parameter, not even the required 'matchKeyword' or optional 'keywordType'. The agent must infer parameter semantics solely from names.
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?
Description states clearly that the tool queries bidding information enterprises participate in. It uses specific verb '查询' (query) and resource '招投标信息' (bidding info). While siblings exist, the description distinguishes it sufficiently from stats-oriented tools.
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 vs siblings like 'bid_bigdata_bid_search' or 'bid_bigdata_planned_projects'. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询和筛选招投标公告信息。
请求参数:
matchKeyword: 搜索关键词
biddingType: 招标类型JSON数组字符串，例如 ["招标公告","中标公告"]
biddingRegion: 项目地区JSON数组字符串，例如 [["福建省","厦门市"]]
biddingAnncPubStartTime/biddingAnncPubEndTime: 公告发布时间范围
searchMode: 标题匹配、标的物匹配、全文匹配
pageIndex: 页码
pageSize: 分页大小，一页最多获取50条
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | ||
| pageIndex | No | ||
| searchMode | No | ||
| biddingType | No | ||
| matchKeyword | No | ||
| biddingRegion | No | ||
| biddingAnncPubEndTime | No | ||
| biddingPurchasingType | No | ||
| biddingAnncPubStartTime | No | ||
| biddingProjectMaxAmount | No | ||
| biddingProjectMinAmount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral information (e.g., read-only nature, rate limits, side effects). It only describes parameters, leaving the agent uninformed about tool behavior.
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 with a clear front-loaded purpose sentence followed by a parameter list. It could be improved with structured formatting (e.g., markdown) but is efficient.
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?
With 11 parameters, no schema descriptions, no output schema, and no annotations, the description should provide more context (e.g., output format, examples, pagination details). It covers parameters partially but lacks completeness.
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 description lists several parameters with brief explanations (e.g., matchKeyword, biddingType, pageSize max), adding value beyond the schema which lacks descriptions. However, it omits three parameters (biddingPurchasingType, biddingProjectMinAmount, biddingProjectMaxAmount) and provides no examples.
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 it is for querying and filtering bidding announcement information ('查询和筛选招投标公告信息'), and the tool name 'bid_search' aligns. It implicitly distinguishes from siblings like statistics and detail tools, but does not explicitly differentiate.
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, such as other bid_bigdata tools or unrelated search tools. Missing context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据企业名称、统一社会信用代码等获取企业标讯信息中中标信息统计项。
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavior such as side effects, authentication needs, or rate limits, leaving agents uninformed.
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 that immediately states the verb and resource, but lacks structure for complex details.
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?
Without output schema or annotations, the description does not explain return format, pagination, or error conditions, making it insufficient for reliable tool invocation.
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 description hints at matchKeyword content ('enterprise name, credit code') but entirely omits keywordType, leaving the parameter's purpose unclear given 0% schema coverage.
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 retrieves bid-winning statistics for enterprises based on name or credit code, distinguishing it from sibling tools like tender or procurement stats.
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 is provided on when to use this tool versus alternatives, nor any context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业拟建公告信息。
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | ||
| pageIndex | No | ||
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'query info' without disclosing pagination behavior, keyword matching rules, or any side effects. Essential behavioral traits are missing.
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 very concise (one short sentence) but sacrifices essential detail. It is not inappropriately long, but it under-specifies the tool's usage.
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?
With 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not mention result format, pagination limits, or how keywords are matched, leaving the agent with insufficient information.
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 description coverage is 0%, and the description adds no meaning to the parameters. Parameters like keywordType and matchKeyword are not explained, and their expected values remain unclear.
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 it queries enterprise planned project announcements, which is a specific verb and resource. However, it does not differentiate from sibling tools like bid_bigdata_bidding_info or enterprise_get_enterprise_base_info.
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 is provided on when to use this tool versus alternatives such as bid_bigdata_bid_search or enterprise_get_keyword_search. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据企业名称或ID，获取企业采购统计信息，包括采购产品分布、采购区域分布等。
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what data is returned but does not disclose whether the operation is read-only, auth requirements, rate limits, or behavior beyond the basic purpose.
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 short sentence that conveys the core purpose upfront. It is concise but could be more structured with explicit parameter breakdown.
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?
For a tool with 2 parameters and no output schema or annotations, the description covers the main output (procurement stats with distributions) but omits parameter details and behavioral context, leaving gaps for an agent to use 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?
Schema coverage is 0%; the description mentions 'name or ID' which maps to matchKeyword and keywordType, but does not clarify the exact meaning, format, or allowed values for these parameters.
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 that the tool retrieves enterprise procurement statistics including product and area distribution, using name or ID. This distinguishes it from sibling tools like bid_bigdata_bidding_info or bid_bigdata_bid_search.
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 explicit guidance on when to use this tool versus alternatives. The sibling names imply differentiation, but the description does not state use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据企业名称、统一社会信用代码等获取企业标讯信息中招标信息统计项。
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the tool's function but does not mention read-only nature, data freshness, rate limits, authentication requirements, or whether it returns aggregated counts or detailed records. This is insufficient for a tool with no annotation support.
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 conveys the core purpose without extraneous words. It is front-loaded and efficient, though it could benefit from slight structure (e.g., listing parameters).
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 absence of annotations and output schema, the description should provide more context about the return format (e.g., count, summary fields), pagination, and scope. The tool has 2 parameters and sibling tools with varying functionality, so the minimal description leaves gaps for an agent to correctly invoke the tool.
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 description adds partial meaning by indicating that matchKeyword can be an enterprise name or unified social credit code. However, it does not explain the keywordType parameter, and the schema has 0% description coverage. The description adds some value but leaves ambiguity about the optional parameter.
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 states that the tool obtains statistical items of bidding information based on enterprise name or social credit code. This is clear and uses a specific verb+resource. However, it does not differentiate from siblings like bid_bigdata_bidding_info or bid_bigdata_bid_win_stats, which may cause confusion.
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 is provided on when to use this tool versus its siblings. There is no mention of prerequisites, when-not-to-use, or alternatives. The agent lacks context for selecting this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业基础工商信息。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. As a query tool, it likely is read-only, but this is not stated.
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 short and efficiently conveys purpose and parameter options. However, the parameter list is somewhat raw and could be better integrated into the overall narrative.
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 simple schema (2 params, no output schema) and lack of annotations, the description adequately explains parameter usage but lacks broader context such as return values, error handling, or example usage.
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?
With 0% schema description coverage, the description adds meaning by listing concrete values for matchKeyword (企业名称/注册号/统一社会信用代码/企业id) and keywordType (name/nameId/regNumber/socialCreditCode). However, it omits the relationship between the parameters and default behavior, reducing completeness.
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 states it queries basic enterprise business information ("查询企业基础工商信息"), which is a clear verb+resource. However, it does not differentiate from sibling tools like enterprise_get_enterprise_profile or enterprise_get_enterprise_business_info, leaving ambiguity about what 'basic' entails.
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 is provided on when to use this tool versus alternatives. It simply lists parameters without contextual usage advice or conditional logic, forcing the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业分支机构信息。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
pageIndex: 页码，从1开始
pageSize: 分页大小
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | ||
| pageIndex | No | ||
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or effects. For a query tool, basic safety is implied but not explicitly stated.
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 brief (one line plus parameter list) and to the point. It front-loads the purpose and lists parameters clearly, but could be more structured with formatting for clarity.
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?
The tool has no output schema and limited description. While parameter info is provided, the return format, pagination behavior, and error handling are not explained. For a moderately complex tool, this is adequate but not complete.
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 description coverage is 0%, but the description adds meaning by explaining matchKeyword (企业名称/注册号/统一社会信用代码/企业id) and keywordType (name, nameId, etc.). However, pageIndex and pageSize are only listed without additional context like defaults or range.
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 explicitly states '查询企业分支机构信息' (query enterprise branch information), which clearly indicates the verb and resource. It distinguishes from sibling tools like enterprise_get_enterprise_base_info and enterprise_get_enterprise_business_info.
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 such as enterprise_get_enterprise_base_info or enterprise_get_enterprise_profile. The description only explains parameters, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业业务相关信息，用于识别企业主营业务和产业链相关能力。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
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 only states the purpose and parameter types, lacking details on mutability, auth needs, rate limits, or output characteristics. For a query tool, basic read-only behavior could be implied but not explicit.
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 brief, starting with a clear purpose sentence followed by parameter descriptions. No wasted words; each sentence adds value.
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 no output schema, the description should explain return values or behavior. It adequately covers parameters but omits output format, pagination, or error scenarios, which an agent needs to invoke correctly among 22 sibling tools.
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 description coverage is 0%, but the description adds meaning by listing accepted values for matchKeyword (enterprise name/registration number/credit code/ID) and keywordType options ('name', 'nameId', 'regNumber', 'socialCreditCode'). This compensates well for the bare schema.
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 enterprise business-related information to identify main business and industry chain capabilities. The verb '查询' (query) and resource '企业业务相关信息' are specific, and the tool is well-differentiated from siblings like enterprise_get_enterprise_base_info which focus on base info.
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 identifying main business and chain capabilities but does not explicitly state when to use or not use this tool, nor does it reference alternatives among the many sibling tools. Some implied context exists but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业控股股东信息。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authorization requirements, rate limits, or side effects. The description carries the full burden but fails to provide needed context.
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?
Extremely concise with two short paragraphs. The purpose is front-loaded, and parameter list is structured. No wasted 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 no output schema and no description of return values, the description is incomplete. It does not explain what data the tool returns, which is critical for an information retrieval tool.
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%, but the description includes parameter explanations (e.g., 'matchKeyword' accepts name/registration number/credit code, 'keywordType' lists options). This adds meaning beyond the raw schema but lacks completeness (e.g., no format or validation details).
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?
Description clearly states the action ('查询') and resource ('企业控股股东信息'), indicating it queries controlling shareholder info. It is distinguishable from sibling tools like enterprise_get_enterprise_base_info, though no explicit differentiation is provided.
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 specify prerequisites, limitations, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业对外投资信息。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
pageIndex: 页码，从1开始
pageSize: 分页大小
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | ||
| pageIndex | No | ||
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the full burden of behavioral disclosure. However, it only describes the query parameters and does not mention any side effects, authorization needs, rate limits, or whether the tool is read-only. The agent cannot assess safety or impact.
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 appropriately sized for a simple query tool: a one-line purpose followed by parameter list. It front-loads the purpose. However, the parameter list could be more structured (e.g., using a table) to improve scannability, but it is not overly verbose.
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 4 parameters, no output schema, and no annotations, the description adequately covers the input semantics. All parameters are explained. Since there is no output schema, the agent can infer that the return value is a list of investment info entries. The description is sufficient for a basic query tool.
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 has 4 parameters with 0% description coverage, so the description must compensate. It explains 'matchKeyword' as accepting multiple identifier types and lists allowed values for 'keywordType' (e.g., 'name', 'regNumber'). This adds meaning beyond the schema, though the explanations are informal and not structured as a spec.
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: '查询企业对外投资信息' (query enterprise external investment information). It specifies a verb and a resource, but does not differentiate from sibling enterprise tools like 'enterprise_get_enterprise_base_info' or 'enterprise_get_enterprise_branch_info', leaving ambiguity about what specific investment details are returned.
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 lists parameters but provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or any context for invocation. The agent receives no help in deciding between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业主要人员信息。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
pageIndex: 页码，从1开始
pageSize: 分页大小
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | ||
| pageIndex | No | ||
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes input parameters but does not disclose behavior such as whether modifications occur, authentication needs, rate limits, or error responses. The tool appears to be a query, but this is not explicitly stated.
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, listing parameters with brief Chinese explanations. It is front-loaded with the purpose sentence. While efficient, the formatting could be improved for readability, but each line serves a purpose.
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 4 parameters, no output schema, and no annotations, the description should explain what the tool returns. It only covers input parameters, leaving output format, error handling, and behavior for missing results unspecified. This incompleteness limits an agent's ability to use the tool 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?
Schema description coverage is 0%, but the description adds significant meaning: it explains matchKeyword as '企业名称/注册号/统一社会信用代码/企业id', enumerates keywordType values, and clarifies pageIndex and pageSize. This goes well beyond the bare schema.
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 explicitly states '查询企业主要人员信息' (query enterprise main person info), providing a clear verb and resource. Among sibling tools like enterprise_get_enterprise_base_info and enterprise_get_enterprise_branch_info, this one specifically targets main person info, distinguishing its purpose.
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 lists parameters but provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or when not to use it. The sibling tools suggest different enterprise information endpoints, but no explicit criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业简介信息。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authorization requirements, or any side effects. It merely says 'query', implying read-only but not explicitly.
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 and front-loaded with the purpose. It uses a structured list for parameters, making it easy to scan. No unnecessary text.
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?
The description lacks context on the output format or return data. Without an output schema, the agent does not know what fields the profile contains, which is important for interpreting results.
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 description adds significant value beyond the input schema by explaining the accepted values for 'matchKeyword' (enterprise name/reg number/credit code/ID) and 'keywordType' (name, nameId, etc.). With 0% schema coverage, this is crucial for correct parameter usage.
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 it queries enterprise profile information, using a specific verb ('query') and resource ('enterprise profile'). However, it does not differentiate from the sibling tool 'enterprise_get_enterprise_base_info', which likely has a similar purpose.
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 alternatives, such as 'enterprise_get_enterprise_base_info' or other enterprise tools. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业标签信息，包括主营业务、融资、规模、高新、专精特新等标签。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only implies a read operation (query) but does not disclose authentication needs, error handling, rate limits, or side effects. The description is minimal.
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 very concise: two sentences plus parameter list. The first sentence states the purpose immediately, and the parameter list is clear and front-loaded. No extraneous information.
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?
No output schema is provided, and the description does not explain the structure or fields of the returned data. It only gives examples of tags without detailing the full response. For a query tool, this is a notable gap.
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 description coverage is 0%, but the description adds meaning: matchKeyword is an enterprise identifier (name/reg number/social credit code/ID) and keywordType lists specific allowed values (name, nameId, etc.). This clarifies the parameters beyond the schema types.
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 that the tool queries enterprise tag information, listing examples like main business, financing, scale. It distinguishes from siblings by focusing specifically on tags, while other enterprise tools handle base info, profile, etc.
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 over alternatives (e.g., enterprise_get_enterprise_base_info). No context on prerequisites or scenarios. Only parameter descriptions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
关键词模糊查询企业。
请求参数:
matchKeyword: 匹配关键词，查询各类信息包含匹配关键词的企业
pageIndex: 页码，从1开始
pageSize: 分页大小，一页最多获取50条数据
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | ||
| pageIndex | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states it performs a fuzzy search. It does not mention read-only behavior, rate limits, or whether results are paginated (though implied by parameters).
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 extremely concise with a single sentence for purpose and three lines for parameters, front-loaded and no unnecessary information.
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?
While parameters are well described, the description lacks overall context such as output format, error behavior, or performance considerations. It is adequate for a simple search but not fully complete.
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 description provides explicit detail for each parameter beyond the schema titles: matchKeyword's purpose, pageIndex start value, pageSize max of 50. This compensates for the 0% schema description coverage.
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 performs a fuzzy keyword search for enterprises. However, it does not differentiate from sibling tools that also query enterprise data, and the phrase '各类信息' is vague about which fields are searched.
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 is provided on when to use this tool versus alternatives like enterprise_get_enterprise_base_info. It simply describes the operation without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
专利信息搜索。
请求参数:
matchKeyword: 专利名称/专利申请号/公布公告号/申请人/代理机构
pageSize: 分页大小，一页最多获取50条数据
patentType: 发明申请、实用新型、发明授权、外观设计
keywordType: 专利名称、申请号/公开号、申请人、代理机构
pageIndex: 页码，从1开始
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | ||
| pageIndex | No | ||
| patentType | No | ||
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose whether the tool is read-only, requires authentication, or has rate limits. It fails to mention any behavioral traits beyond the basic search function.
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 but not highly structured. The first line is a summary, followed by a parameter list. It is not verbose, but could benefit from clearer formatting (e.g., bullet points).
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?
The description lacks information about return format, error handling, sorting, or fields returned. With no output schema, the agent is left guessing about the tool's output, making it incomplete.
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?
Despite 0% schema description coverage, the description explains each parameter's meaning in Chinese (e.g., matchKeyword lists acceptable types). It also notes the page size limit of 50, adding value beyond the schema.
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 '专利信息搜索' (patent information search) is vague and essentially restates the tool name. It does not distinguish from sibling tools like patent_bigdata_patent_stats, which also deals with patents.
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 such as patent_bigdata_patent_stats. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
企业专利统计分析。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id
keywordType: name、nameId、regNumber、socialCreditCode
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. The brief description only mentions 'statistics' without further details.
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 and includes parameter definitions in a structured list. However, the main purpose statement is minimal and could be front-loaded with more detail to improve clarity.
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 output schema and annotations, the description is incomplete. It does not explain what the statistical analysis returns (e.g., counts, trends), nor does it mention any constraints or prerequisites. The tool's purpose is implied but not fully conveyed.
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?
Despite 0% schema description coverage, the description explicitly lists the two parameters and provides examples for keywordType (name, nameId, regNumber, socialCreditCode) and explains matchKeyword as enterprise name/ID. This adds meaningful context beyond the schema's bare titles.
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 states '企业专利统计分析' (enterprise patent statistical analysis), giving a general verb and resource. However, it lacks specificity about what kind of statistics (e.g., counts, trends) and does not differentiate from the sibling tool 'patent_bigdata_patent_search' which likely lists patents.
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 is provided on when to use this tool versus alternatives like 'patent_bigdata_patent_search' or other enterprise tools. The description does not mention any prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询企业获批政策项目统计，用于了解企业获得国家/省/市/区各级政策项目、主管机构、补贴金额和年度趋势。
请求参数:
matchKeyword: 企业名称/注册号/统一社会信用代码/企业id；如果没有企业全称，可先用 enterprise_get_keyword_search 查询。
keywordType: name、nameId、regNumber、socialCreditCode。
| Name | Required | Description | Default |
|---|---|---|---|
| keywordType | No | ||
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It does not disclose whether the tool is read-only, any side effects, required permissions, rate limits, or error behavior. It only hints at output content but lacks explicit 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 concise, front-loading the purpose, then listing parameters with brief explanations. Every sentence contributes; no fluff. It could be slightly more structured, but it's efficient.
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 no output schema, the description partially compensates by listing the types of information returned (levels, authorities, subsidies, trends). However, it does not provide a detailed output structure or example, leaving some ambiguity about the exact format.
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 description coverage is 0%, but the description adds value by explaining the possible values for matchKeyword (name, registration number, etc.) and keywordType, and suggests using enterprise_get_keyword_search if full name is not available. This goes beyond the schema definitions.
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: query enterprise approved policy project statistics, covering levels, authorities, subsidies, and trends. It uses a specific verb ('查询') and resource ('获批政策项目统计'), and is distinguishable from sibling tools like policy_bigdata_policy_info and policy_bigdata_policy_search.
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 understanding enterprise-approved policy projects but does not explicitly state when to use this tool vs alternatives. No when-not or alternative recommendations are provided; usage is implied from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据政策ID查询政策详情，包括发布机构、正文、原文链接、附件、关联项目、资助金额和申报时间等。
请求参数:
matchKeyword: 政策ID。
| Name | Required | Description | Default |
|---|---|---|---|
| matchKeyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose whether the tool is read-only or has any side effects. For a query tool, it's likely safe, but the lack of explicit behavioral context is a gap.
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?
Two sentences, front-loaded with purpose, no wasted words. Structure is efficient and clear.
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?
Lists fields returned, covering key information. No output schema, but description compensates. Lacks details on error handling or pagination, but sufficient for a simple query.
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?
Parameter schema has 0% coverage, but description explains matchKeyword is the policy ID. This adds basic meaning but no format or constraints beyond the name.
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?
Description clearly states it queries policy details by ID, listing specific fields included. It distinguishes from sibling tools like policy_bigdata_policy_search and policy_bigdata_approved_project_stats.
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?
Explicitly says to use when querying policy details by ID. While it doesn't list exclusions, the context implies this is for retrieving details rather than searching, and siblings cover search and stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索政策法规、申报指南或公示公告，可按关键词、政策类型、发布机构、地区和发布时间筛选。
请求参数:
matchKeyword: 政策关键词，例如“智能网联汽车”“自动驾驶”“低空经济”“机器人”。
pnType: 政策类型，枚举：全部、申报指南、公示公开、其他政策。
agency: 发布机构。
address: 地区，支持 list/list JSON/地区字符串。示例：[["福建省"],["贵州省","安顺市","平坝县"]]；国家政策输入“国家部委”；直辖市输入“北京/上海/天津/重庆”。
policyPubStartTime/policyPubEndTime: 发布时间范围，格式 yyyy-mm-dd。
pageSize: 分页大小，一页最多50条。
pageIndex: 页码，从1开始。
| Name | Required | Description | Default |
|---|---|---|---|
| agency | No | ||
| pnType | No | 全部 | |
| address | No | ||
| pageSize | No | ||
| pageIndex | No | ||
| matchKeyword | Yes | ||
| policyPubEndTime | No | ||
| policyPubStartTime | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions pagination limits (pageSize max 50) and default values, which is helpful. However, it does not discuss permissions, rate limits, error handling, or the nature of the operation (read-only). For a search tool, this is minimally adequate but not comprehensive.
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 and well-structured. It begins with a clear one-sentence summary of the tool's purpose, followed by a structured list of parameters with explanations. Every sentence adds value, and there is no redundant or irrelevant information.
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 complexity of 8 parameters and no output schema, the description covers all parameters with examples and constraints (e.g., date format, address structure). It could be improved by explaining the order of results or how to handle empty results, but it is largely complete for effective tool usage.
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 description coverage is 0%, so the description carries full responsibility for parameter semantics. It provides detailed explanations for all parameters, including examples for 'matchKeyword', enumeration values for 'pnType', and complex format guidance for 'address' (including nested lists). This adds significant meaning beyond the bare schema.
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 it searches for policies, application guides, and public announcements with filtering options. The verb '搜索' and resource '政策法规、申报指南或公示公告' are specific, and the tool name 'policy_search' distinguishes it from sibling tools like 'policy_info' or 'approved_project_stats'.
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 explains what the tool does but does not explicitly state when to use it versus alternatives (e.g., 'policy_bigdata_policy_info' for details, 'policy_bigdata_approved_project_stats' for statistics). The context from sibling tools provides implicit guidance, but the description itself lacks explicit usage or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据具体产品名称查询下游企业列表。
请求参数:
keywords: 供应链产品关键词，多个词中间用英文逗号分隔
mainProducts: 下游产品，多个词中间用英文逗号分隔
isForeignTrade: 是否外贸企业，可选值：是、否
factoryInspectionType: 是否验厂，可选值：是、否
foundTimeStart/foundTimeEnd: 成立时间范围，格式yyyy-mm-dd
address: 地区，例如“广东省,深圳市”或“广东省”
pageIndex: 页码，从1开始
pageSize: 分页大小
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | ||
| hasPack | No | ||
| hasStock | No | ||
| keywords | Yes | ||
| pageSize | No | ||
| hasDevice | No | ||
| pageIndex | No | ||
| foundTimeEnd | No | ||
| mainProducts | No | ||
| regCapitalMax | No | ||
| regCapitalMin | No | ||
| foundTimeStart | No | ||
| isForeignTrade | No | ||
| isTopEnterprise | No | ||
| isGazelleEnterprise | No | ||
| isUnicornEnterprise | No | ||
| isHighTechEnterprise | No | ||
| factoryInspectionType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only explains parameters. It does not disclose whether the operation is read-only, destructive, rate limits, data freshness, or pagination behavior beyond parameter names.
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?
Description is moderately concise with a clear one-liner purpose and a list of parameters. It is front-loaded but could be better structured (e.g., bullet points) for readability.
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?
The description covers only about half of the 18 parameters (missing hasPack, hasStock, etc.) and provides no information about output format or pagination behavior, leaving gaps for a complex query tool.
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?
Though schema coverage is 0%, the description adds significant semantics by explaining parameter details: comma separation for multiple values, allowed values (是/否), address format, date format, and page index starting at 1.
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?
Description clearly states the tool queries a list of downstream enterprises based on product names, distinguishing it from sibling tools like supply_get_down_stream_products which likely query products.
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 lists parameters but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or usage context. Usage is implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据产品名称查询下游产品列表。产品名称是指参与供应链环节中的产品。
请求参数:
keywords: 供应链产品关键词，多个词中间用英文逗号分隔
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. The tool is a query, but that is implied rather than stated. The description only says 'query' without clarifying safety or impact.
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 very concise: two sentences for purpose, one parameter description with clear title and explanation. No fluff. Front-loaded with the main action. Every sentence serves a purpose.
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?
The tool returns downstream products, but there is no output schema and the description does not describe the return format, structure, or example. For a simple query tool, missing this information reduces completeness. Also lacks context on typical use cases or relationship to other tools.
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 description coverage is 0%, so the description must add meaning. It does: 'keywords: supply chain product keywords, multiple words separated by commas.' This explains the format and intended content. It adds value beyond the schema's type-only information. However, it lacks examples or constraints like max length.
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: 'Query downstream product list based on product name.' It specifies the resource (downstream products) and the action (query). The phrase 'product name refers to products involved in the supply chain' adds context. This distinguishes it from sibling 'supply_get_down_stream_enterprises' which focuses on enterprises.
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 sibling 'supply_get_down_stream_enterprises' is a similar tool, but no comparison or usage context is provided. There is no mention of prerequisites, limitations, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0advanced_filter_get_enterprise_countadvanced_filter_get_enterprise_listbid_bigdata_bid_searchbid_bigdata_bid_win_statsbid_bigdata_bidding_infobid_bigdata_planned_projectsbid_bigdata_procurement_statsbid_bigdata_tender_statsenterprise_get_enterprise_base_infoenterprise_get_enterprise_branch_infoenterprise_get_enterprise_business_infoenterprise_get_enterprise_holder_infoenterprise_get_enterprise_invest_infoenterprise_get_enterprise_main_person_infoenterprise_get_enterprise_profileenterprise_get_enterprise_tagsenterprise_get_keyword_searchpatent_bigdata_patent_searchpatent_bigdata_patent_statspolicy_bigdata_approved_project_statspolicy_bigdata_policy_infopolicy_bigdata_policy_searchsupply_get_down_stream_enterprisessupply_get_down_stream_productsEach tool targets a distinct function within its domain (e.g., enterprise base info vs. branches vs. holders; bidding info vs. search vs. stats). Even similar tools like advanced_filter_get_enterprise_count and advanced_filter_get_enterprise_list are clearly differentiated by purpose (count vs. list).
All tool names follow the consistent pattern 'category_verb_noun' (e.g., advanced_filter_get_enterprise_count, enterprise_get_enterprise_base_info, bid_bigdata_bid_search). They are all in snake_case, using English verbs and nouns uniformly.
With 24 tools, the server is slightly above the typical well-scoped range but still justified by the comprehensive domains covered (enterprise info, bidding, patents, policies, supply chain). Each domain has a reasonable number of tools.
The server covers a broad set of queries across enterprise data, bidding, patents, and policies. However, it lacks upstream supply chain tools and certain lifecycle operations (e.g., create/update), which may be out of scope for a read-only data API. Minor gaps exist but overall coverage is strong.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
All HasData scraping tools in one MCP server: Google, TikTok, Instagram, maps, e-commerce and more.
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/handaas/industry-chain-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
