第二篇文章，我删掉了那个只能做加减乘除的计算器代码，重新创建了一个项目。这一回，我把MCP服务器连上了GitHub的开放接口，又给它加上了资源和提示这两样东西。服务器跑起来的那一刻，这东西突然不再是个玩具了——它开始能给正在评估开源依赖的团队提供点儿有用的判断，比如一个项目的安全风险有多大。
先说说这次新接触到的概念。上一篇文章里我们简单提过，MCP把AI可以调用和读取的东西分成了三类原语：工具是让大模型去执行的函数，像get_repo_info()这种，直接给它办事的能力；资源是提供上下文数据的，大模型可以安全地读取某个网址、文件或者API返回的内容，但不会修改它；提示则像个角色设定模板，用来结构化对话，比如“你现在是一名数据科学家，正在分析CHAOSS指标”。这个项目里，我三种全都用上了——工具去抓GitHub的信息，资源用来加载CHAOSS的评估指南，提示则让大模型切换到合适的专家视角。
CHAOSS是Linux基金会下的一个项目，专门制定衡量开源社区健康度的指标和框架。他们出的“实践者指南”有点儿意思，把社区健康这种听起来玄乎的东西——比如安全性、贡献者可持续性、响应速度——翻译成了一堆可落地的数字。这批指南能帮任何分析开源项目数据的人找到改进方向。我这次集中在其中一份《安全实践指南》上，这份指南主要盯着三个指标，它们合在一起，能给你一个起点去打量一个开源项目的安全状况。某个公司的开源项目办公室（OSPO）里的经理，在选依赖或者给安全团队报材料时，缺的可能就是这么个东西。
三个指标里，有一个叫做libyears的概念：假如你的项目依赖了一个库，而那个库的最新版本已经发布了两年，你还在用过时的版本，那你就积攒了2个libyears的滞后。有研究显示，libyears值高的项目，出现安全漏洞的概率要高出4倍。指南把这一类直接可以拿来对标风险的指标提炼出来，省去了你翻几十页报告的时间。
技术栈和上一篇文章基本一致，还是Python、uv和FastMCP，额外加了两个依赖：httpx用来发请求，python-dotenv用来加载放在环境变量里的GitHub令牌。和之前最大的不同是，这个MCP服务器开始跟外部API打交道了。我按照CHAOSS安全指南的意图，给它装了五个工具：获取仓库基础信息和统计数据、获取发布频率、查询安全公告……具体代码里通过FastMCP的装饰器暴露出去，每个函数带上自己的说明。当大模型判断需要调用某个工具时，就能直接触发，拿回结构化的结果。
整个东西跑通之后，一个念头变得很具体：评估开源依赖的安全性，不一定非得靠昂贵的安全审计或者拍脑袋的信任判断。把几个经过验证的社区指标和自动化查询串起来，就可以得到一个相对清醒的风险透视。而且由于MCP本身把工具、资源和提示的边界画得清楚，这个服务器的扩展也不太容易跑歪——下一步想加入响应速度、贡献者多样性这些维度的评估，就只是加几个新函数和对应指南的事。
热门跟贴