Technographics

@pipeworx/technographics

直接从网页读取网站使用的技术。无需密钥。

属于 Pipeworx 的一部分——一个将 AI Agent 连接到 1683+ 个实时数据源的 MCP 网关。

工具

• tech_detect(url) — 网站加载的技术栈：电商平台、支付、CMS、JS 框架、分析、营销自动化、聊天、广告像素、CDN、Web 服务器、访客识别工具。每项检测都附带其依据。
• tech_detect_coverage() — 检测器按类别识别的所有技术，以及它无法检测的内容。

选择的路径及许可证考量

我们编写了自己的特征规则，没有使用 Wappalyzer 规则集。 这就是全部的许可证考量，也是未来维护者需要了解的部分：

项目	许可证	实际情况
enthec/webappanalyzer	GPL-3.0	Wappalyzer 特征库的持续维护版本
HTTPArchive/wappalyzer	GPL-3.0	HTTP Archive 对同一项目的分支
projectdiscovery/wappalyzergo	MIT	MIT 代码——其 README 声明使用了上述两个项目的数据
rverton/webanalyze	MIT	情况相同：MIT 代码，使用 Wappalyzer 系列的数据

Wappalyzer 在商业化前已从 MIT 许可证转为其他许可证，其所有持续维护的分支都继承了 copyleft。MIT 包装器不会改变其所使用数据库的许可证，因此“用那个 MIT 版本”并不像看起来那样能规避问题。

src/signatures.ts 包含的是我们对公开可观察事实的自主表述——Shopify 会设置 _shopify_y cookie，Cloudflare 会返回 cf-ray，Next.js 会输出 __NEXT_DATA__。这些事实不属于任何人；但针对这些事实整理出的特定数据库则属于其创建者。我们没有使用、导入或随项目分发任何 GPL 代码或数据。

**为此付出的代价：**涵盖 29 个类别的约 167 项技术，而商业数据库涵盖数万项。每条响应都会明确说明这一权衡，不会将其隐藏。

每条响应都会如实说明的两个限制

• 不会执行 JavaScript。 我们读取的是服务器返回的 HTML。任何由标签管理器在客户端注入的内容都不可见——对于这一类别来说，这是一个显著的盲区，而非微小误差，因为营销工具正是通过标签管理器安装的。一个只显示“Google Tag Manager”的网站，底层可能运行着十几种工具。
• 未发现不代表不存在。 答案中缺少某项技术，可能只是因为它不在特征集内。tech_detect_coverage() 可用于核实检测结果为阴性后再决定是否采信。

提供依据，而非布尔值

每项检测都会返回匹配到的字符串——cookie _shopify_y、response header x-vercel-id: …、resource https://js.stripe.com/v3。检测器如果无法核查其结果，人们第一次发现结果有误时就会不再信任它。在开发过程中，这种做法还帮我们发现了一个真实错误：vercel.com 被报告为 Mintlify，仅仅因为页面在客户 Logo 中提到了 Mintlify。现在，匹配规则依据的是技术实际输出的内容，而不是正文中的产品名称。

安全地获取调用者提供的 URL

此工具会获取调用者指定的地址；这种设计可能让数据网关变成访问私有空间的代理。因此，我们只允许 http/https 和标准端口，并拒绝私有、环回、链路本地（包括 169.254.169.254 处的云元数据）、CGNAT 和多播地址。我们会手动跟踪重定向，并在每一跳都重新检查——真正的攻击方式是让公开 URL 通过 302 跳转到元数据端点，而只检查第一跳并不能阻止这种情况。响应正文上限为 1.5 MB。

数据来源

实时网站。无需第三方 API，无需密钥，也不依赖供应商。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "technographics": {
      "url": "https://gateway.pipeworx.io/technographics/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/technographics/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、 discover_tools、search_within、remember/recall 和网关级工具集中的其他工具。因此，你看到的工具数量会多于此表：目前，单个工具包端点除了列出该工具包自身的工具外，还会列出约 30 个共享工具。连接的 initialize 响应会说明确切的范围，是判断当天情况的权威依据。

这是有意为之，并非意外复用。这些元工具使限定范围的连接也能回答此工具包未涵盖的问题——通过 ask_pipeworx 跨整个目录进行路由——而无需添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点；如果额外的架构定义所占用的上下文多于路由带来的价值，请连接一次完整网关，而不是连接多个工具包端点。

或者，连接完整的 Pipeworx 网关，直接列出每个工具包的工具，而不仅是此工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都连接到同一个网关和相同的 1683+ 个数据源。唯一的区别是直接列出哪个工具包的工具；无论连接哪个端点，ask_pipeworx 都能访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/tech_detect \
  -H 'Content-Type: application/json' \
  -d '{"url":"shopify.com"}'

首次调用无需账户。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/tech_detect。查找工具：使用 {"query":"..."} 调用 POST https://gateway.pipeworx.io/v1/tools/search_packs。

独立运行（无需网关账户）

此软件包也可作为本地 stdio MCP 服务运行——无需 Pipeworx 账户，也无需经过网关往返：

{
  "mcpServers": {
    "technographics": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-technographics"]
    }
  }
}

也可以直接运行，以确认它能正常启动：

npx -y @pipeworx/mcp-technographics

它通过 stdin/stdout 使用 MCP 通信，并为仅限此工具包的工具响应 initialize/tools/list/tools/call——不包含上文的网关连接所添加的任何共享元工具。相同的源代码、相同的工具，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗英语提问，而不必直接调用工具——此方式既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Technographics data" })

网关会选择合适的工具并自动填充参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT