
Businessmcp
com.businessmcp由 businessmcp.com 发布官方发布者v3.0.0更新于 Oct 24, 2026
Your whole business as one MCP server: analytics, CRM, SEO, ads, revenue. Scoped per data class.
概览
受 OAuth 保护的远程 MCP 端点,把企业的分析、CRM、SEO、广告和营收数据作为一个服务器提供,并按数据类别划分权限范围。
- 可以做什么
- 未公布工具清单,能力只能从描述得知:助手可通过单一托管端点访问分析、CRM、SEO、广告和营收等业务数据。
- 访问按数据类别划分范围,助手能看到什么取决于连接时授予的权限。
- 厂商随附的 README 介绍的是网关加固工具(URL/SSRF 校验、上游错误分类、工具名命名空间、传输回退),而非该托管服务器的工具。
- 适用场景
- 当你希望助手通过一个托管 MCP 连接查询多个业务系统(分析、CRM、SEO、广告、营收),而不想分别对接,并且能接受厂商托管的 OAuth 服务时,可以考虑使用。
- 运行要求
- 需要厂商域名上的远程 streamable HTTP 端点,且必须使用 OAuth 认证。未声明环境变量或请求头。README 中单独的 npm 工具包需要 Node.js,其传输辅助模块还需以对等依赖方式安装 MCP 客户端包。
安装
在 SourceWeft 中
- 打开 控制台中的 Businessmcp,将其添加到工作区。
- 连接 所需的 凭据。它们会被私密存储,绝不会在公开页面上展示。
- 为需要使用其工具的对话启用该服务。
Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。
交给智能体安装
把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体,或 SourceWeft 对话中。智能体会读取该服务器的安装指南,先向你展示发布者、端点和登录方式,经你同意后再把它添加到你的客户端。密钥不会写进任何命令。
阅读 https://sourceweft.com/mcp/com.businessmcp%2Fbusinessmcp/install.md,并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前,先告诉我它的发布者、端点和登录方式,等我确认。不要把 API 密钥写进命令或我会提交的文件;问我密钥应从哪里获取。其他 MCP 客户端
把它添加到你客户端的 mcpServers 配置中。 客户端会在首次连接时完成 OAuth 登录。
{
"mcpServers": {
"businessmcp": {
"type": "http",
"url": "https://businessmcp.com/api/mcp"
}
}
}README
mcp-gateway
Hardening utilities for an MCP gateway — a server that fronts other people's MCP servers.
These are extracted from BusinessMCP's production gateway, which lets a workspace connect third-party MCP servers and re-expose them through one governed endpoint. Fronting someone else's server means fetching a URL a user supplied, on your infrastructure, and that has a small number of ways to go badly wrong. This is what we run.
MIT. No dependencies for the two core modules — two Node builtins and nothing else.
1. The SSRF guard, and the bypass that survived a passing test suite
A gateway takes a URL from a user and fetches it. Without a guard that is a direct path to
http://169.254.169.254/ and your cloud credentials.
The obvious implementation checks the host against a list of reserved ranges. Ours did, including IPv4-mapped IPv6:
That regex never fired in production. The WHATWG URL parser — new URL(), what every caller
actually uses — normalizes IPv6 hosts to their canonical form, and the canonical form of an
IPv4-mapped address is hex:
The dotted spelling the regex matched is a shape no caller can produce. The unit test passed because it called the guard with the dotted string directly. It was green, and it was meaningless: the guard was only ever exercised through an input the real code path could not generate.
Every one of these reached the fetch:
Adding more prefixes to the list is not the fix. IPv6 has several mechanisms that embed an IPv4
address, and matching text means playing whack-a-mole against a normalizer you do not control. This
guard decodes the address to its eight 16-bit groups and checks numerically, unwrapping every
embedding it knows (::ffff: mapped, :: compatible, 64:ff9b:: NAT64, 2002:: 6to4) and
recursing into the inner IPv4. Undecodable input fails closed — an address you cannot parse is
one you cannot vouch for.
isPublicHttpUrl resolves the hostname and requires every returned address to be public, which
is a best-effort DNS-rebinding defence. It is not a complete one: a rebind between this check and the
socket connect is a real TOCTOU window, and closing it means pinning the resolved IP into the
connection. We accept that residual risk and think you should know about it rather than discover it.
There is a second trap this does not solve for you. Validating a host once and then calling
fetch(url, { redirect: 'follow' }) is a bypass: the server 302s to http://127.0.0.1/ and the
follow is never checked. Follow redirects manually and re-validate every hop.
2. Classify upstream failures — never swallow them
The version of this code that shipped first wrapped every upstream call in catch {} and dropped
the server from the tool list. Auth failure, unsupported transport, timeout, blocked host and
"server is fine, returned nothing" were indistinguishable — which is to say invisible. Users saw
tools silently missing, with no explanation anywhere in the product.
The reason is also what makes a retry decision honest: only a handshake-shaped failure is worth retrying on another transport. An auth rejection fails identically either way.
3. Namespace tool names without collisions
Aggregating N servers means prefixing their tools. MCP caps names at 64 characters, so prefixing plus truncation can map two different upstream tools to the same string — and then a lookup by name dispatches the call to the wrong server.
When truncation is needed a short hash of the full name is appended, so two long names stay distinct.
4. Transport fallback
MCP's 2026-07-28 revision dropped legacy HTTP+SSE for servers, but plenty of servers you connect
to still only speak it. withUpstream tries streamable HTTP, falls back to SSE, and tells you
which worked so you can persist it and skip the probe next time.
Requires @modelcontextprotocol/client as a peer dependency. The other modules do not.
Honest limits
- Utilities, not a framework. There is no gateway here — no aggregation, no auth, no policy layer. Those are meaningfully coupled to how you store connections, and a fake abstraction over that would be worse than none.
- No external audit. This is what we run in production. That is a reason to take it seriously and not a substitute for review.
- The aggregation and inspection layers are deliberately not included, partly because they are coupled to our database and partly because they have no test coverage. Everything shipped here is from the tested side.
- DNS-rebinding TOCTOU is open, as described above.
Development
This package is generated from the BusinessMCP monorepo, where these modules are in active production use. Fixes should go there and be regenerated — a patch applied only here would be overwritten, and two hand-maintained copies of a security guard is the exact failure that produced the bypass in section 1.
Issues and reports are welcome here regardless.
来源:README.md,提交 0cb0536
工具
0版本历史
1- v3.0.0最新Sep 18, 2026
评分
已满足适用检查项的 85%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通必需25 分
- 已声明认证方式必需10 分
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分