company-dd
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TYC_TOKEN | No | 天眼查官方 CLI 授权环境标识；实际登录态由 tyc login / tyc init 写入 ~/.tyc/config.json | |
| COMPANY_DD_UA | No | 自定义 UA（SEC 要求声明联系人） | |
| COMPANY_DD_HOME | No | 数据目录：报告、原始载荷 | /opt/company-dd/data |
| DEVNORS_API_KEY | No | 启用 Devnors 中国工商聚合（字段标 partial） | |
| COMPANY_DD_RETRIES | No | 请求重试次数 | |
| COMPANY_DD_TIMEOUT | No | 请求超时设置 | |
| OPENCORPORATES_API_KEY | No | 启用境外注册库 | |
| COMPANY_DD_HOST_INTERVAL | No | 按主机限速的间隔 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| probe_sourcesA | 探测全部数据源的实时可用性（真发请求）。 返回每个源的状态：ok / blocked / needs_key / error，含真实 HTTP 状态码。 先跑这个，才知道这一次能查什么、什么必须转人工。 |
| resolve_companyA | 把公司名消歧成确定的调查主体（上市公司代码 / CIK / QID）。 返回候选列表和各自的锚点。同名主体必须先用统一社会信用代码核对， 再开始采集，否则红线判定会张冠李戴。 |
| build_reportB | 对一家公司做完整背调：探测→消歧→采集→红线判定→出结论。 announcement_pages × page_size 决定公告扫描范围；window_days 是判定 「近 N 天无某类公告」所要求的覆盖窗口，窗口没覆盖到就会被标成未验证。 |
| risk_sweepB | 只做风险信号扫描：拉最近公告标题，按红线关键词命中列出。 适合快速初筛。返回每条的日期、标题、原文链接和命中的规则编号。 |
| manual_checklistB | 生成人工必查清单：官方渠道入口 + 检索词 + 留痕要求。 被 WAF/验证码拦住的维度必须由人过一遍，工具不代替人在官方系统里核对。 |
| manual_recordA | 将人工核查结果留痕并回写报告。 outcome 只能是 clear 或 hit；必须同时提供核查人、方法，以及官方 URL 或截图/PDF 路径。 这是唯一允许人工结果改变规则状态的入口，不能直接编辑报告 JSON。 |
| manual_findingsC | 读取某份报告已回填的人工核查证据。 |
| list_reportsC | 列出本机已生成的背调报告。 |
| get_reportB | 按报告编号读取完整报告 JSON（含证据台账索引）。 |
| get_evidenceA | 读取报告的证据台账：来源、URL、抓取时间、sha256、原始载荷路径。 复核时先看这里：拿 URL 回原站核对，或比对 raw 目录里的原始载荷哈希。 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
build_report is a composite that internally does probe→resolve→collect→redline, overlapping with probe_sources, resolve_company and risk_sweep, so an agent may wonder whether to call the pipeline or the atomic steps. The manual_* tools are internally distinguishable, but the composite-vs-atomic boundary is genuinely ambiguous.
All names are snake_case with verb_noun or grouping-prefix structure (probe_sources, resolve_company, list_reports, get_report, get_evidence), and the manual_* prefix cleanly groups human-in-loop operations. Minor deviation: manual_findings is noun-style—it reads more like a getter than an action, but naming is still predictable.
Ten tools is well within the sweet spot and each earns its place: three pipeline steps, one orchestration entry, a quick scan, three manual-workflow tools, and three report/evidence readers. No filler tools.
The surface covers the full lifecycle—probe, disambiguate, build, risk scan, manual checklist/record, list, read, and evidence audit. Minor gaps exist, e.g. no delete/export report, and no way to update or re-run just one section of an existing report, but agents can work around this by rebuilding.