产品判断我认同：把 MCP Server 的开发从写代码变成写 JSON，方向是对的。但有一行标签是错的，而且恰好是企业选型第一眼要看的那行。
一：许可证不是 MIT
仓库根目录的 LICENSE 是 AGPL-3.0。LICENSING.md 写得更细：除 ee/ 目录之外全部是 AGPL-3.0-only；ee/ 目录（比如 packages/backend/src/ee/）走 AnythingMCP 商业许可，装的是 Cloud 运营和 Business 版。再往前一版更绕：早期版本用的是 BUSL-1.1（Business Source License），按各自的 Change Date 再转 Apache 2.0。
对一个要接企业 ERP 的 MCP 网关，这不是脚注。AGPL 的网络触发条款直接管到「你把它跑成对外的托管服务」这一种用法——而这恰恰是「一个 MCP Server 实例挂 N 个 connector」的默认部署方式。
二：265 是真的，但更该看的是 2467
README 的徽章给了两个数：adapters = 265、tools = 2467。也就是一个适配器平均 9.3 个工具。另外 21 个适配器不需要任何密钥（这条原帖没写，它是试用门槛的关键）。
9.3 这个数字比 265 有信息量：它说明这些适配器做的是「典型读操作打包」，不是全 API 覆盖。按需深挖时，这个颗粒度决定你能不能只靠现成适配器收工。
三：SAP 不是一个适配器，是两套
README 里 SAP 分两条路：
- 直连 HANA：10 个工具，只读，走 SAP 数据字典与 CDS 视图，面向前置/私有云部署
- Gateway OData：7 个工具，用 SAP 自己的标签（journal entry items、billing documents、sales orders、business partners、stock、products）
四：它比原帖说的老一点，也更商业一点
建仓 2026-02-28，主页 anythingmcp.com，母体是 helpcode.ai（弗赖堡）。「从 KOCH Freiburg 的生产系统里提取出来」这句没错，但 README 现在的署名已经带上公司主体身份——先自有工具、再双许可产品，路径清晰。star 现在 621（原帖写 557），28 个未关 issue。
五：自托管版里有什么，值得单独记一笔
README 写明 OAuth2、RBAC、SSO、SCIM 在自托管版里就有，没被扣到付费层。这条比 star 数重要——它是「先让企业用起来」和「先让企业付钱」的分水岭，值得盯住它会不会变。
下一根钉子
两个数：过去 90 天里有多少个 adapter 被改过，以及 ee/ 目录的增长速度。前者证明社区共建是否真的在跑（265 个适配器如果有大半三年没动，就是负债不是资产）；后者说明商业边界会不会往回挪——OAuth2、RBAC、SSO、SCIM 现在还在自托管版里，这是最该盯的一格。