1. 项目概述一个系统信息监控的MCP服务器最近在折腾一些自动化工具链发现很多场景下我需要让AI助手比如Claude、Cursor等能够实时“感知”到我本地开发环境的状态。比如我想让它帮我分析一个性能瓶颈它得知道当前CPU和内存的占用情况或者让它帮我规划一个后台任务它得了解当前系统的负载和磁盘空间。手动去查htop或者df -h再把结果复制粘贴给AI这个流程太割裂了。于是我找到了一个非常对胃口的项目carterlasalle/system_information_mcp。简单来说这是一个实现了Model Context Protocol (MCP)的服务器。MCP你可以理解为一套标准化的“插座”和“插头”规范它让不同的AI助手能够以一种安全、可控的方式调用外部工具、读取外部数据。而这个特定的MCP服务器提供的“工具”就是获取你计算机的系统信息。它就像一个翻译官把psutil这类系统库采集到的原始数据翻译成AI助手能理解和操作的标准化指令和资源。这个项目解决的核心痛点就是打通AI与本地系统状态之间的信息壁垒。它让AI从“盲人摸象”变成了“开了天眼”能够基于实时、准确的系统上下文来提供建议或执行操作。无论是开发者、运维工程师还是任何需要结合系统状态进行自动化决策的场景这个工具都能极大地提升工作流的智能化水平。接下来我就结合自己搭建和使用的经验把这个项目的里里外外、从原理到实操、从配置到避坑给你彻底讲明白。2. MCP协议与系统信息采集的核心原理2.1 Model Context Protocol (MCP) 是什么在深入这个项目之前我们必须先搞懂MCP。它不是某个特定AI模型的功能而是一个由Anthropic牵头设计的开放协议。你可以把它想象成电脑的USB标准。在没有USB之前每个外设打印机、鼠标、U盘都需要自己的专用接口和驱动混乱且不兼容。USB协议出现后大家只要遵循这个标准就能即插即用。MCP扮演的就是AI世界的“USB协议”角色。它的核心目标是标准化AI助手与外部工具、数据源之间的交互方式。一个MCP服务器就像我们这个系统信息服务器对外暴露两类东西工具可以被AI调用的函数。比如“获取CPU使用率”、“列出所有进程”。AI助手通过MCP协议向服务器发送请求服务器执行对应的函数并返回结果。资源可以被AI读取的数据流或静态内容。比如一个持续更新的“系统监控仪表板”数据流。这样做的好处显而易见安全性AI助手不再需要直接访问你的文件系统或执行任意命令。它只能通过MCP服务器暴露的、经过严格定义的“工具”来操作权限被牢牢限制在工具范围内。可移植性同一个MCP服务器可以被Claude Desktop、Cursor、Windsurf等任何支持MCP协议的客户端使用无需为每个客户端单独开发插件。模块化你可以为不同的功能系统信息、数据库查询、项目管理工具部署不同的MCP服务器然后按需组合使用非常灵活。carterlasalle/system_information_mcp就是一个严格遵循MCP协议实现的服务器它专门提供系统信息相关的“工具”。2.2 系统信息采集的基石psutil库这个MCP服务器的能力边界很大程度上取决于它底层使用的系统信息库。该项目核心依赖的是Python界的明星库——psutil。psutilprocess and system utilities是一个跨平台的库用于获取系统和进程的运行信息。它用纯Python实现但通过C扩展调用系统底层API因此效率非常高。它的强大之处在于提供了统一的接口无论你在Windows、Linux还是macOS上调用psutil.cpu_percent()或psutil.virtual_memory()它都能返回结构一致的数据省去了开发者处理不同操作系统差异的麻烦。这个MCP服务器本质上就是为psutil的众多功能包上了一层MCP协议的外衣。我们来看看它通常暴露哪些工具具体工具名可能随版本更新但类别大致如下系统概览工具一次性获取CPU、内存、磁盘、网络、传感器温度/风扇等核心指标的概览。细化查询工具独立获取CPU使用率、内存信息、磁盘分区及使用情况、网络接口统计等。进程管理工具列出所有进程、根据PID查询特定进程详情、结束进程等需注意权限。理解了MCP是“插座标准”psutil是“电力来源”你就能明白这个项目是如何工作的它用标准插座MCP把电力系统信息安全、规范地输送给需要它的电器AI助手。3. 环境准备与服务器部署实操3.1 前置条件与依赖安装开始之前确保你的环境满足以下条件Python环境需要Python 3.8或更高版本。推荐使用pyenv或conda管理多版本Python环境。包管理工具pip已更新至最新版。基础开发工具根据操作系统可能需要安装Python开发头文件如Linux上的python3-dev或C编译器因为psutil的部分组件需要编译。首先克隆项目仓库并进入目录git clone https://github.com/carterlasalle/system_information_mcp.git cd system_information_mcp我强烈建议使用虚拟环境来隔离依赖避免污染全局Python环境。这是Python项目开发的黄金准则。# 创建虚拟环境命名为 venv或其他你喜欢的名字 python -m venv venv # 激活虚拟环境 # 在 Linux/macOS 上 source venv/bin/activate # 在 Windows 上 .\venv\Scripts\activate激活后你的命令行提示符前通常会显示(venv)表示已进入虚拟环境。接下来安装项目依赖pip install -e .-e参数代表“可编辑模式”安装这样你对项目代码的任何本地修改都会立即生效方便调试。注意如果安装过程中遇到与psutil编译相关的问题特别是在Windows上可能需要安装Microsoft Visual C Build Tools。在Linux上确保已安装gcc和python3-dev包。3.2 配置MCP客户端以Claude Desktop为例服务器部署好了但它是“服务端”需要一个“客户端”来连接和调用它。目前最流行的MCP客户端之一就是Claude Desktop应用。我们需要配置Claude Desktop告诉它这个MCP服务器的位置。Claude Desktop的配置文件通常位于macOS:~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:%APPDATA%\Claude\claude_desktop_config.jsonLinux:~/.config/Claude/claude_desktop_config.json如果文件或目录不存在手动创建即可。我们需要编辑这个JSON文件添加我们的MCP服务器配置。{ mcpServers: { system-info: { command: /path/to/your/venv/bin/python, args: [ /path/to/your/system_information_mcp/server.py ], env: { PYTHONPATH: /path/to/your/system_information_mcp } } } }关键参数解析system-info这是你给这个服务器起的名字可以自定义在Claude中会以此名称引用工具。command必须指向你虚拟环境中的Python解释器绝对路径。这是最常见的配置错误点如果你用了全局Python可能会导致依赖包找不到。args启动参数这里指向项目中的服务器主脚本通常是server.py。env可选环境变量。设置PYTHONPATH确保脚本能正确找到项目模块。配置完成后务必完全重启Claude Desktop应用否则配置不会生效。3.3 验证服务器运行与连接重启Claude后如何验证连接成功呢直接测试服务器你可以在终端激活虚拟环境后直接运行服务器脚本看是否有错误输出。python server.py正常情况下它会启动一个进程并等待标准输入stdio上的MCP协议消息。你可以按CtrlC退出。在Claude中验证打开Claude新建一个对话。如果你配置正确通常在输入框上方或侧边栏的工具区域能看到一个名为“system-info”或你自定义名称的服务器被加载。更直接的方式是尝试让Claude使用系统信息工具。例如输入“请告诉我当前CPU的使用情况。”如果Claude能够理解并调用工具返回类似“CPU使用率15.2%”的结果那么恭喜你配置成功如果失败Claude通常会提示“无法连接到MCP服务器”或“工具调用失败”。这时需要检查配置文件路径是否正确。虚拟环境Python路径是否绝对正确。依赖是否完整安装尝试在虚拟环境中python -c “import psutil”测试。查看Claude Desktop的日志文件位置因系统而异里面常有更详细的错误信息。4. 核心工具详解与使用场景成功连接后这个MCP服务器具体提供了哪些“趁手兵器”呢我们来逐一拆解并看看在什么场景下它们能大显身手。4.1 系统状态概览工具这通常是第一个被调用的工具因为它提供了一个快速的“仪表盘视图”。工具名可能类似于get_system_overview。返回的数据结构通常包括CPU: 整体使用率百分比、每个逻辑核心的使用率、物理核心数、当前频率。内存: 总内存、可用内存、使用率、已使用内存、缓存等。磁盘: 所有分区的列表包含挂载点、总容量、已用空间、使用率、文件系统类型。网络: 各网络接口的发送/接收字节数、包数、错误数。传感器如果支持CPU温度、风扇转速等。系统启动时间。使用场景示例初步性能诊断当AI助手感知到你的操作如“我的电脑有点卡”时它可以主动调用此工具快速获取系统负载全貌从而判断瓶颈可能出现在CPU、内存还是磁盘I/O。自动化报告生成你可以要求AI助手“每天早上9点给我一份系统健康简报。” AI可以调用此工具获取数据并格式化成一份易读的报告。4.2 细粒度查询工具当概览工具提示某个区域有问题时或者你只需要特定信息时细粒度工具就派上用场了。CPU详情工具(get_cpu_info/get_cpu_percent)提供数据除了使用率还可能包括CPU型号、架构、缓存大小等静态信息以及用户态、系统态、空闲时间等详细时间统计。场景分析CPU密集型应用如代码编译、视频转码的性能影响。AI可以建议“当前CPU使用率已持续超过80%建议暂时停止后台的Docker容器xx。”内存详情工具(get_memory_info)提供数据深入的内存统计包括缓冲buffers、缓存cached、共享内存shared、交换分区swap的使用情况。场景排查内存泄漏。AI可以观察内存使用趋势“过去5分钟内可用内存从4GB持续下降至1GB而your_app进程的RSS增长了3GB疑似内存泄漏。”磁盘详情工具(get_disk_usage,get_disk_partitions)提供数据每个分区的读写次数、读写字节数、读写耗时IO等待时间。场景定位磁盘IO瓶颈。当系统响应慢但CPU内存不高时AI可以检查磁盘IO“/var分区IO等待时间高达30%可能是日志写入过于频繁。”网络详情工具(get_network_io_counters)提供数据每个接口的实时流量、丢包数、错误数。场景诊断网络问题。“eth0接口有持续的丢包可能是网络 cable 问题或交换机端口故障。”4.3 进程管理工具这是功能较强的一组工具需要谨慎使用。进程列表工具(get_process_list)提供数据系统所有进程的列表通常包含PID、进程名、CPU占用、内存占用RSS/VMS、状态、创建时间、命令行等。场景资源占用排序。你可以问“哪个进程占用内存最多” AI调用此工具对结果按内存排序后告诉你。查找特定进程“帮我找到所有包含‘nginx’的进程。”进程详情工具(get_process_details)提供数据给定一个PID返回该进程的详细信息包括打开的文件、网络连接、线程数、环境变量等。场景深度调试。当一个进程行为异常时AI可以帮你分析它打开了哪些文件建立了哪些网络连接。终止进程工具(kill_process)功能向指定PID的进程发送信号如SIGTERM, SIGKILL。场景与警告这是高危操作。AI助手在建议使用此工具时必须极度谨慎通常需要用户明确确认。场景例如“zombie_process已无响应是否尝试终止它”务必注意MCP服务器运行时自身的权限决定了它能终止哪些进程。以普通用户权限运行时通常只能终止自己拥有的进程。重要心得在实际与AI协作中我倾向于主要使用查询类工具概览、详情、进程列表。对于kill_process这类操作工具我通常在配置中将其禁用或者仅在高度信任的、隔离的测试环境中启用。安全永远是第一位的。5. 高级配置与自定义扩展默认配置可能不适合所有场景。这个项目通常设计得比较灵活允许通过配置或扩展来调整其行为。5.1 配置刷新频率与数据过滤持续高频地采集系统信息尤其是磁盘IO和网络本身就会带来开销。你可能会在服务器代码或配置文件中找到相关设置采样间隔例如cpu_percent(interval1.0)中的interval参数。增加间隔可以降低开销但数据实时性会下降。对于后台监控设为2-5秒可能更合适。数据过滤你可能不关心所有磁盘分区或所有网络接口。可以修改代码在返回数据前过滤掉例如/dev/loop*回环设备或docker0Docker虚拟网桥等无关项使返回给AI的结果更简洁。进程列表限制默认可能返回所有进程在进程数很多的系统上这会导致返回数据量巨大。可以修改为只返回CPU或内存占用前N位的进程或者排除系统内核线程。5.2 添加自定义监控指标这是项目最具潜力的部分。psutil库很强大但你可能还想监控一些特定应用指标比如Docker容器的状态和资源使用。特定服务如Nginx、PostgreSQL的内部状态。自定义日志文件的增长速率。扩展步骤通常如下在server.py中找到工具定义部分。工具通常使用tool()装饰器或类似方式注册。编写新的工具函数。例如创建一个get_docker_stats函数使用dockerPython SDK或调用docker stats命令来获取数据。将新函数注册为MCP工具。确保其输入输出符合MCP协议对工具的定义通常是接收参数返回字符串或结构化数据。重启MCP服务器和客户端。例如一个简单的添加磁盘IO等待时间监控的扩展思路# 假设在 server.py 中新增 tool() async def get_disk_io_bottleneck() - str: 检查是否存在磁盘IO瓶颈返回IO等待时间较高的分区。 import psutil disk_io psutil.disk_io_counters(perdiskTrue) bottlenecks [] for disk, io in disk_io.items(): # 简单的逻辑如果读写繁忙时间占比过高 total_time io.read_time io.write_time if total_time 1000: # 假设阈值是1秒 bottlenecks.append(f{disk}: 繁忙时间 {total_time}ms) return 当前磁盘IO瓶颈: (; .join(bottlenecks) if bottlenecks else 无显著瓶颈)5.3 安全加固配置在生产环境或多人共享环境中使用安全配置至关重要权限最小化永远不要以root或Administrator身份运行此MCP服务器。创建一个专用的、权限受限的系统用户来运行它。工具白名单在服务器配置中明确启用和禁用工具。强烈建议禁用kill_process这类高危工具除非有绝对必要。网络隔离MCP协议通常通过stdio或本地socket通信。确保其不监听外部网络端口除非你明确需要并配置了TLS认证。默认的stdio模式是最安全的。审计日志修改服务器代码记录所有工具调用的时间、调用者通过MCP会话ID标识、工具名和参数注意过滤敏感参数便于事后审计。6. 典型应用场景与实战案例理论说了这么多我们来点实际的。下面是我在开发运维中真实用到的一些场景看看它是如何融入工作流的。6.1 场景一智能开发环境助手我正在用VS Code写一个Python数据分析脚本程序跑起来特别慢。我向Cursor已集成MCP提问“为什么我的Python脚本运行这么慢”Cursor的行动调用get_system_overview发现CPU使用率只有30%但内存使用率达85%且交换分区swap有少量使用。调用get_process_list对我的Python进程按内存排序发现它占用了近4GB的RSS内存。Cursor分析后建议“你的脚本可能正在内存中加载一个巨大的数据集。当前系统内存已接近饱和触发了swap导致性能急剧下降。建议你1. 检查代码中是否有pd.read_csv()加载了远超需要的数据2. 考虑使用chunksize参数分块读取。3. 或者是否需要增加物理内存”价值AI不再是凭空猜测而是基于真实的系统指标给出针对性极强的诊断和建议。6.2 场景二自动化运维与故障预判我设置了一个定时任务让Claude在每天业务低峰期比如凌晨2点检查服务器状态。Claude自动执行的流程调用get_system_overview获取整体状态。调用get_disk_usage检查所有关键分区如//var/data的使用率。判断逻辑如果发现/var分区使用率超过90%则执行get_process_list找出在/var目录下写入量最大的进程。生成报告并告警“警报服务器prod-db-01的/var分区使用率已达92%。主要占用进程是postgres的WAL日志写入。建议立即清理旧日志或扩容磁盘空间。” 这份报告可以通过MCP连接的其他工具如邮件服务器、Slack机器人发送给我。价值将传统的监控告警系统与AI的因果分析能力结合从“发生了什么”升级到“为什么发生以及该怎么办”。6.3 场景三性能测试与瓶颈分析我正在对一个新的微服务进行压力测试。我指挥AI“我现在要启动压测命令wrk -t12 -c100 -d30s http://localhost:8080/api。请在压测期间每5秒采集一次系统概览并在压测结束后给我一份性能分析报告。”AI的协作记录压测开始时间。启动一个后台循环每5秒调用一次get_system_overview并将时间戳和数据记录下来。压测结束后AI分析收集到的时序数据“在压测第15-20秒CPU使用率稳定在95%以上但网络接收流量达到峰值后请求延迟从10ms飙升到200ms。同时磁盘/data的IO等待时间升高。结论服务本身CPU处理能力是瓶颈但在高负载下日志写入磁盘/data分区的IO延迟加剧了整体响应延迟。建议1. 优化服务代码CPU效率2. 将日志改为异步写入或输出到更快的存储。”价值AI充当了自动化的性能测试工程师不仅收集数据还能进行关联分析和初步归因。7. 常见问题、故障排查与优化心得在实际部署和使用中你肯定会遇到一些问题。这里把我踩过的坑和解决方案汇总一下。7.1 连接与配置问题问题1Claude Desktop 提示“无法连接到MCP服务器”或工具列表不显示。排查步骤检查配置文件路径和语法JSON格式非常严格多一个逗号或少一个引号都会导致解析失败。使用在线JSON校验工具检查你的claude_desktop_config.json。验证Python路径这是最常见的问题。在终端中执行which python或where pythonon Windows确保输出的路径与配置文件中command字段的路径完全一致并且这个Python环境已安装所有依赖。检查服务器是否可启动在终端中手动运行配置中的命令例如/path/to/venv/bin/python /path/to/server.py。观察是否有导入错误如ModuleNotFoundError: No module named psutil或其它运行时错误。手动运行成功的话应该会挂起等待输入。查看客户端日志Claude Desktop通常有应用日志位置因系统而异如macOS可能在~/Library/Logs/Claude/。日志中常有连接失败的详细原因。解决根据错误信息修正。如果是依赖问题在正确的虚拟环境中重新安装。如果是路径问题使用绝对路径。问题2工具调用超时或无响应。可能原因服务器进程卡住某个工具函数如遍历所有进程详情如果处理逻辑不当可能在系统进程很多时执行缓慢导致MCP请求超时。死锁极少数情况下如果工具函数内部涉及锁或同步操作可能发生死锁。解决为工具函数添加超时机制。虽然MCP服务器框架可能已有超时但在工具函数内部对于可能耗时的操作如大量磁盘I/O可以使用asyncio.wait_for进行内部超时控制。优化工具函数。例如get_process_list不要返回进程的完整命令行可能很长只返回前几个字符。或者实现分页查询。7.2 性能与数据问题问题3频繁调用导致系统自身开销增大。现象感觉装了监控后电脑反而有点“变慢”了。分析psutil本身很高效但频繁调用比如每秒多次cpu_percent(interval0.1)或disk_io_counters()尤其是后者会触发内核统计信息读取产生不可忽视的开销。优化建议降低采样频率对于AI助手场景通常不需要秒级实时数据。将工具的默认采样间隔调整到3-5秒对用户体验影响很小但能显著降低负载。缓存数据对于变化不快的静态信息如CPU核心数、磁盘分区列表、内存总量可以在服务器启动时读取一次并缓存无需每次调用都重新获取。客户端去重指导AI助手不要“疯狂”查询。例如在连续对话中如果刚问过CPU情况10秒内再次询问AI可以主动说“刚刚的数据显示CPU使用率是X%变化通常不会很快需要我立即再查询一次吗”问题4返回的数据过于冗长干扰AI判断。现象AI在分析系统概览时抓不住重点或者把无关的磁盘分区、网络接口信息也罗列出来。解决在服务器端做数据清洗和聚合。过滤在返回磁盘信息前过滤掉/dev/loop、/snap、/boot/efi等通常不关心的只读或小型分区。聚合对于网络接口可以只显示有活跃流量bytes_sent 0 or bytes_recv 0的接口如eth0wlan0 而忽略lo回环和众多Docker虚拟网卡。突出重点在返回的文本中用加粗或特定格式标记异常值如使用率80%的CPU核心、使用率90%的磁盘分区。7.3 安全与隐私考量问题5进程列表暴露了敏感信息。风险get_process_list返回的进程命令行可能包含数据库密码、API密钥等敏感信息例如./myapp --db-passwordsecret123。缓解措施命令行脱敏在服务器端对返回的进程命令行进行正则匹配脱敏。例如将匹配--password\S、--key\S等模式的内容替换为--password***。这需要仔细设计规则避免误伤。权限控制如前所述以低权限用户运行服务器它只能看到该用户有权看到的进程信息这本身就是一个安全边界。意识教育最重要的是永远不要在命令行参数中传递明文密码。应使用环境变量或配置文件。问题6如何控制AI助手的“行动范围”核心原则MCP服务器定义了AI的“能力边界”。你给它什么工具它就只能做什么。最佳实践按需部署不要运行一个“全能”的MCP服务器。为不同的安全等级需求运行不同的服务器实例。例如一个只读的“系统信息查询”服务器和一个具备“服务重启”能力的服务器分开。审慎开放写操作像kill_process、write_file这类工具开放前要三思。如果必须开放可以考虑增加“二次确认”机制例如工具要求传入一个confirmation_token该token需要用户从另一个安全渠道获取。网络隔离确保MCP服务器只通过stdio与本地客户端通信绝不暴露端口到外部网络。这个项目就像为你的AI助手装上了一双感知本地环境的“眼睛”它的价值不在于工具本身有多复杂而在于它如何将标准化的系统状态无缝融入你与AI的对话流中。从一次简单的“电脑为什么卡”的询问到构建一个自动化的运维监控分析链路它的可能性由你的想象力和实际需求决定。我最深刻的体会是配置过程本身也是对MCP协议和系统监控的一次深入学习而成功连接后那种“AI真的懂我电脑状态”的体验会让整个开发运维工作流变得前所未有的流畅和智能。
基于MCP协议与psutil构建AI系统监控服务器实战指南
发布时间：2026/5/18 22:37:49
1. 项目概述一个系统信息监控的MCP服务器最近在折腾一些自动化工具链发现很多场景下我需要让AI助手比如Claude、Cursor等能够实时“感知”到我本地开发环境的状态。比如我想让它帮我分析一个性能瓶颈它得知道当前CPU和内存的占用情况或者让它帮我规划一个后台任务它得了解当前系统的负载和磁盘空间。手动去查htop或者df -h再把结果复制粘贴给AI这个流程太割裂了。于是我找到了一个非常对胃口的项目carterlasalle/system_information_mcp。简单来说这是一个实现了Model Context Protocol (MCP)的服务器。MCP你可以理解为一套标准化的“插座”和“插头”规范它让不同的AI助手能够以一种安全、可控的方式调用外部工具、读取外部数据。而这个特定的MCP服务器提供的“工具”就是获取你计算机的系统信息。它就像一个翻译官把psutil这类系统库采集到的原始数据翻译成AI助手能理解和操作的标准化指令和资源。这个项目解决的核心痛点就是打通AI与本地系统状态之间的信息壁垒。它让AI从“盲人摸象”变成了“开了天眼”能够基于实时、准确的系统上下文来提供建议或执行操作。无论是开发者、运维工程师还是任何需要结合系统状态进行自动化决策的场景这个工具都能极大地提升工作流的智能化水平。接下来我就结合自己搭建和使用的经验把这个项目的里里外外、从原理到实操、从配置到避坑给你彻底讲明白。2. MCP协议与系统信息采集的核心原理2.1 Model Context Protocol (MCP) 是什么在深入这个项目之前我们必须先搞懂MCP。它不是某个特定AI模型的功能而是一个由Anthropic牵头设计的开放协议。你可以把它想象成电脑的USB标准。在没有USB之前每个外设打印机、鼠标、U盘都需要自己的专用接口和驱动混乱且不兼容。USB协议出现后大家只要遵循这个标准就能即插即用。MCP扮演的就是AI世界的“USB协议”角色。它的核心目标是标准化AI助手与外部工具、数据源之间的交互方式。一个MCP服务器就像我们这个系统信息服务器对外暴露两类东西工具可以被AI调用的函数。比如“获取CPU使用率”、“列出所有进程”。AI助手通过MCP协议向服务器发送请求服务器执行对应的函数并返回结果。资源可以被AI读取的数据流或静态内容。比如一个持续更新的“系统监控仪表板”数据流。这样做的好处显而易见安全性AI助手不再需要直接访问你的文件系统或执行任意命令。它只能通过MCP服务器暴露的、经过严格定义的“工具”来操作权限被牢牢限制在工具范围内。可移植性同一个MCP服务器可以被Claude Desktop、Cursor、Windsurf等任何支持MCP协议的客户端使用无需为每个客户端单独开发插件。模块化你可以为不同的功能系统信息、数据库查询、项目管理工具部署不同的MCP服务器然后按需组合使用非常灵活。carterlasalle/system_information_mcp就是一个严格遵循MCP协议实现的服务器它专门提供系统信息相关的“工具”。2.2 系统信息采集的基石psutil库这个MCP服务器的能力边界很大程度上取决于它底层使用的系统信息库。该项目核心依赖的是Python界的明星库——psutil。psutilprocess and system utilities是一个跨平台的库用于获取系统和进程的运行信息。它用纯Python实现但通过C扩展调用系统底层API因此效率非常高。它的强大之处在于提供了统一的接口无论你在Windows、Linux还是macOS上调用psutil.cpu_percent()或psutil.virtual_memory()它都能返回结构一致的数据省去了开发者处理不同操作系统差异的麻烦。这个MCP服务器本质上就是为psutil的众多功能包上了一层MCP协议的外衣。我们来看看它通常暴露哪些工具具体工具名可能随版本更新但类别大致如下系统概览工具一次性获取CPU、内存、磁盘、网络、传感器温度/风扇等核心指标的概览。细化查询工具独立获取CPU使用率、内存信息、磁盘分区及使用情况、网络接口统计等。进程管理工具列出所有进程、根据PID查询特定进程详情、结束进程等需注意权限。理解了MCP是“插座标准”psutil是“电力来源”你就能明白这个项目是如何工作的它用标准插座MCP把电力系统信息安全、规范地输送给需要它的电器AI助手。3. 环境准备与服务器部署实操3.1 前置条件与依赖安装开始之前确保你的环境满足以下条件Python环境需要Python 3.8或更高版本。推荐使用pyenv或conda管理多版本Python环境。包管理工具pip已更新至最新版。基础开发工具根据操作系统可能需要安装Python开发头文件如Linux上的python3-dev或C编译器因为psutil的部分组件需要编译。首先克隆项目仓库并进入目录git clone https://github.com/carterlasalle/system_information_mcp.git cd system_information_mcp我强烈建议使用虚拟环境来隔离依赖避免污染全局Python环境。这是Python项目开发的黄金准则。# 创建虚拟环境命名为 venv或其他你喜欢的名字 python -m venv venv # 激活虚拟环境 # 在 Linux/macOS 上 source venv/bin/activate # 在 Windows 上 .\venv\Scripts\activate激活后你的命令行提示符前通常会显示(venv)表示已进入虚拟环境。接下来安装项目依赖pip install -e .-e参数代表“可编辑模式”安装这样你对项目代码的任何本地修改都会立即生效方便调试。注意如果安装过程中遇到与psutil编译相关的问题特别是在Windows上可能需要安装Microsoft Visual C Build Tools。在Linux上确保已安装gcc和python3-dev包。3.2 配置MCP客户端以Claude Desktop为例服务器部署好了但它是“服务端”需要一个“客户端”来连接和调用它。目前最流行的MCP客户端之一就是Claude Desktop应用。我们需要配置Claude Desktop告诉它这个MCP服务器的位置。Claude Desktop的配置文件通常位于macOS:~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:%APPDATA%\Claude\claude_desktop_config.jsonLinux:~/.config/Claude/claude_desktop_config.json如果文件或目录不存在手动创建即可。我们需要编辑这个JSON文件添加我们的MCP服务器配置。{ mcpServers: { system-info: { command: /path/to/your/venv/bin/python, args: [ /path/to/your/system_information_mcp/server.py ], env: { PYTHONPATH: /path/to/your/system_information_mcp } } } }关键参数解析system-info这是你给这个服务器起的名字可以自定义在Claude中会以此名称引用工具。command必须指向你虚拟环境中的Python解释器绝对路径。这是最常见的配置错误点如果你用了全局Python可能会导致依赖包找不到。args启动参数这里指向项目中的服务器主脚本通常是server.py。env可选环境变量。设置PYTHONPATH确保脚本能正确找到项目模块。配置完成后务必完全重启Claude Desktop应用否则配置不会生效。3.3 验证服务器运行与连接重启Claude后如何验证连接成功呢直接测试服务器你可以在终端激活虚拟环境后直接运行服务器脚本看是否有错误输出。python server.py正常情况下它会启动一个进程并等待标准输入stdio上的MCP协议消息。你可以按CtrlC退出。在Claude中验证打开Claude新建一个对话。如果你配置正确通常在输入框上方或侧边栏的工具区域能看到一个名为“system-info”或你自定义名称的服务器被加载。更直接的方式是尝试让Claude使用系统信息工具。例如输入“请告诉我当前CPU的使用情况。”如果Claude能够理解并调用工具返回类似“CPU使用率15.2%”的结果那么恭喜你配置成功如果失败Claude通常会提示“无法连接到MCP服务器”或“工具调用失败”。这时需要检查配置文件路径是否正确。虚拟环境Python路径是否绝对正确。依赖是否完整安装尝试在虚拟环境中python -c “import psutil”测试。查看Claude Desktop的日志文件位置因系统而异里面常有更详细的错误信息。4. 核心工具详解与使用场景成功连接后这个MCP服务器具体提供了哪些“趁手兵器”呢我们来逐一拆解并看看在什么场景下它们能大显身手。4.1 系统状态概览工具这通常是第一个被调用的工具因为它提供了一个快速的“仪表盘视图”。工具名可能类似于get_system_overview。返回的数据结构通常包括CPU: 整体使用率百分比、每个逻辑核心的使用率、物理核心数、当前频率。内存: 总内存、可用内存、使用率、已使用内存、缓存等。磁盘: 所有分区的列表包含挂载点、总容量、已用空间、使用率、文件系统类型。网络: 各网络接口的发送/接收字节数、包数、错误数。传感器如果支持CPU温度、风扇转速等。系统启动时间。使用场景示例初步性能诊断当AI助手感知到你的操作如“我的电脑有点卡”时它可以主动调用此工具快速获取系统负载全貌从而判断瓶颈可能出现在CPU、内存还是磁盘I/O。自动化报告生成你可以要求AI助手“每天早上9点给我一份系统健康简报。” AI可以调用此工具获取数据并格式化成一份易读的报告。4.2 细粒度查询工具当概览工具提示某个区域有问题时或者你只需要特定信息时细粒度工具就派上用场了。CPU详情工具(get_cpu_info/get_cpu_percent)提供数据除了使用率还可能包括CPU型号、架构、缓存大小等静态信息以及用户态、系统态、空闲时间等详细时间统计。场景分析CPU密集型应用如代码编译、视频转码的性能影响。AI可以建议“当前CPU使用率已持续超过80%建议暂时停止后台的Docker容器xx。”内存详情工具(get_memory_info)提供数据深入的内存统计包括缓冲buffers、缓存cached、共享内存shared、交换分区swap的使用情况。场景排查内存泄漏。AI可以观察内存使用趋势“过去5分钟内可用内存从4GB持续下降至1GB而your_app进程的RSS增长了3GB疑似内存泄漏。”磁盘详情工具(get_disk_usage,get_disk_partitions)提供数据每个分区的读写次数、读写字节数、读写耗时IO等待时间。场景定位磁盘IO瓶颈。当系统响应慢但CPU内存不高时AI可以检查磁盘IO“/var分区IO等待时间高达30%可能是日志写入过于频繁。”网络详情工具(get_network_io_counters)提供数据每个接口的实时流量、丢包数、错误数。场景诊断网络问题。“eth0接口有持续的丢包可能是网络 cable 问题或交换机端口故障。”4.3 进程管理工具这是功能较强的一组工具需要谨慎使用。进程列表工具(get_process_list)提供数据系统所有进程的列表通常包含PID、进程名、CPU占用、内存占用RSS/VMS、状态、创建时间、命令行等。场景资源占用排序。你可以问“哪个进程占用内存最多” AI调用此工具对结果按内存排序后告诉你。查找特定进程“帮我找到所有包含‘nginx’的进程。”进程详情工具(get_process_details)提供数据给定一个PID返回该进程的详细信息包括打开的文件、网络连接、线程数、环境变量等。场景深度调试。当一个进程行为异常时AI可以帮你分析它打开了哪些文件建立了哪些网络连接。终止进程工具(kill_process)功能向指定PID的进程发送信号如SIGTERM, SIGKILL。场景与警告这是高危操作。AI助手在建议使用此工具时必须极度谨慎通常需要用户明确确认。场景例如“zombie_process已无响应是否尝试终止它”务必注意MCP服务器运行时自身的权限决定了它能终止哪些进程。以普通用户权限运行时通常只能终止自己拥有的进程。重要心得在实际与AI协作中我倾向于主要使用查询类工具概览、详情、进程列表。对于kill_process这类操作工具我通常在配置中将其禁用或者仅在高度信任的、隔离的测试环境中启用。安全永远是第一位的。5. 高级配置与自定义扩展默认配置可能不适合所有场景。这个项目通常设计得比较灵活允许通过配置或扩展来调整其行为。5.1 配置刷新频率与数据过滤持续高频地采集系统信息尤其是磁盘IO和网络本身就会带来开销。你可能会在服务器代码或配置文件中找到相关设置采样间隔例如cpu_percent(interval1.0)中的interval参数。增加间隔可以降低开销但数据实时性会下降。对于后台监控设为2-5秒可能更合适。数据过滤你可能不关心所有磁盘分区或所有网络接口。可以修改代码在返回数据前过滤掉例如/dev/loop*回环设备或docker0Docker虚拟网桥等无关项使返回给AI的结果更简洁。进程列表限制默认可能返回所有进程在进程数很多的系统上这会导致返回数据量巨大。可以修改为只返回CPU或内存占用前N位的进程或者排除系统内核线程。5.2 添加自定义监控指标这是项目最具潜力的部分。psutil库很强大但你可能还想监控一些特定应用指标比如Docker容器的状态和资源使用。特定服务如Nginx、PostgreSQL的内部状态。自定义日志文件的增长速率。扩展步骤通常如下在server.py中找到工具定义部分。工具通常使用tool()装饰器或类似方式注册。编写新的工具函数。例如创建一个get_docker_stats函数使用dockerPython SDK或调用docker stats命令来获取数据。将新函数注册为MCP工具。确保其输入输出符合MCP协议对工具的定义通常是接收参数返回字符串或结构化数据。重启MCP服务器和客户端。例如一个简单的添加磁盘IO等待时间监控的扩展思路# 假设在 server.py 中新增 tool() async def get_disk_io_bottleneck() - str: 检查是否存在磁盘IO瓶颈返回IO等待时间较高的分区。 import psutil disk_io psutil.disk_io_counters(perdiskTrue) bottlenecks [] for disk, io in disk_io.items(): # 简单的逻辑如果读写繁忙时间占比过高 total_time io.read_time io.write_time if total_time 1000: # 假设阈值是1秒 bottlenecks.append(f{disk}: 繁忙时间 {total_time}ms) return 当前磁盘IO瓶颈: (; .join(bottlenecks) if bottlenecks else 无显著瓶颈)5.3 安全加固配置在生产环境或多人共享环境中使用安全配置至关重要权限最小化永远不要以root或Administrator身份运行此MCP服务器。创建一个专用的、权限受限的系统用户来运行它。工具白名单在服务器配置中明确启用和禁用工具。强烈建议禁用kill_process这类高危工具除非有绝对必要。网络隔离MCP协议通常通过stdio或本地socket通信。确保其不监听外部网络端口除非你明确需要并配置了TLS认证。默认的stdio模式是最安全的。审计日志修改服务器代码记录所有工具调用的时间、调用者通过MCP会话ID标识、工具名和参数注意过滤敏感参数便于事后审计。6. 典型应用场景与实战案例理论说了这么多我们来点实际的。下面是我在开发运维中真实用到的一些场景看看它是如何融入工作流的。6.1 场景一智能开发环境助手我正在用VS Code写一个Python数据分析脚本程序跑起来特别慢。我向Cursor已集成MCP提问“为什么我的Python脚本运行这么慢”Cursor的行动调用get_system_overview发现CPU使用率只有30%但内存使用率达85%且交换分区swap有少量使用。调用get_process_list对我的Python进程按内存排序发现它占用了近4GB的RSS内存。Cursor分析后建议“你的脚本可能正在内存中加载一个巨大的数据集。当前系统内存已接近饱和触发了swap导致性能急剧下降。建议你1. 检查代码中是否有pd.read_csv()加载了远超需要的数据2. 考虑使用chunksize参数分块读取。3. 或者是否需要增加物理内存”价值AI不再是凭空猜测而是基于真实的系统指标给出针对性极强的诊断和建议。6.2 场景二自动化运维与故障预判我设置了一个定时任务让Claude在每天业务低峰期比如凌晨2点检查服务器状态。Claude自动执行的流程调用get_system_overview获取整体状态。调用get_disk_usage检查所有关键分区如//var/data的使用率。判断逻辑如果发现/var分区使用率超过90%则执行get_process_list找出在/var目录下写入量最大的进程。生成报告并告警“警报服务器prod-db-01的/var分区使用率已达92%。主要占用进程是postgres的WAL日志写入。建议立即清理旧日志或扩容磁盘空间。” 这份报告可以通过MCP连接的其他工具如邮件服务器、Slack机器人发送给我。价值将传统的监控告警系统与AI的因果分析能力结合从“发生了什么”升级到“为什么发生以及该怎么办”。6.3 场景三性能测试与瓶颈分析我正在对一个新的微服务进行压力测试。我指挥AI“我现在要启动压测命令wrk -t12 -c100 -d30s http://localhost:8080/api。请在压测期间每5秒采集一次系统概览并在压测结束后给我一份性能分析报告。”AI的协作记录压测开始时间。启动一个后台循环每5秒调用一次get_system_overview并将时间戳和数据记录下来。压测结束后AI分析收集到的时序数据“在压测第15-20秒CPU使用率稳定在95%以上但网络接收流量达到峰值后请求延迟从10ms飙升到200ms。同时磁盘/data的IO等待时间升高。结论服务本身CPU处理能力是瓶颈但在高负载下日志写入磁盘/data分区的IO延迟加剧了整体响应延迟。建议1. 优化服务代码CPU效率2. 将日志改为异步写入或输出到更快的存储。”价值AI充当了自动化的性能测试工程师不仅收集数据还能进行关联分析和初步归因。7. 常见问题、故障排查与优化心得在实际部署和使用中你肯定会遇到一些问题。这里把我踩过的坑和解决方案汇总一下。7.1 连接与配置问题问题1Claude Desktop 提示“无法连接到MCP服务器”或工具列表不显示。排查步骤检查配置文件路径和语法JSON格式非常严格多一个逗号或少一个引号都会导致解析失败。使用在线JSON校验工具检查你的claude_desktop_config.json。验证Python路径这是最常见的问题。在终端中执行which python或where pythonon Windows确保输出的路径与配置文件中command字段的路径完全一致并且这个Python环境已安装所有依赖。检查服务器是否可启动在终端中手动运行配置中的命令例如/path/to/venv/bin/python /path/to/server.py。观察是否有导入错误如ModuleNotFoundError: No module named psutil或其它运行时错误。手动运行成功的话应该会挂起等待输入。查看客户端日志Claude Desktop通常有应用日志位置因系统而异如macOS可能在~/Library/Logs/Claude/。日志中常有连接失败的详细原因。解决根据错误信息修正。如果是依赖问题在正确的虚拟环境中重新安装。如果是路径问题使用绝对路径。问题2工具调用超时或无响应。可能原因服务器进程卡住某个工具函数如遍历所有进程详情如果处理逻辑不当可能在系统进程很多时执行缓慢导致MCP请求超时。死锁极少数情况下如果工具函数内部涉及锁或同步操作可能发生死锁。解决为工具函数添加超时机制。虽然MCP服务器框架可能已有超时但在工具函数内部对于可能耗时的操作如大量磁盘I/O可以使用asyncio.wait_for进行内部超时控制。优化工具函数。例如get_process_list不要返回进程的完整命令行可能很长只返回前几个字符。或者实现分页查询。7.2 性能与数据问题问题3频繁调用导致系统自身开销增大。现象感觉装了监控后电脑反而有点“变慢”了。分析psutil本身很高效但频繁调用比如每秒多次cpu_percent(interval0.1)或disk_io_counters()尤其是后者会触发内核统计信息读取产生不可忽视的开销。优化建议降低采样频率对于AI助手场景通常不需要秒级实时数据。将工具的默认采样间隔调整到3-5秒对用户体验影响很小但能显著降低负载。缓存数据对于变化不快的静态信息如CPU核心数、磁盘分区列表、内存总量可以在服务器启动时读取一次并缓存无需每次调用都重新获取。客户端去重指导AI助手不要“疯狂”查询。例如在连续对话中如果刚问过CPU情况10秒内再次询问AI可以主动说“刚刚的数据显示CPU使用率是X%变化通常不会很快需要我立即再查询一次吗”问题4返回的数据过于冗长干扰AI判断。现象AI在分析系统概览时抓不住重点或者把无关的磁盘分区、网络接口信息也罗列出来。解决在服务器端做数据清洗和聚合。过滤在返回磁盘信息前过滤掉/dev/loop、/snap、/boot/efi等通常不关心的只读或小型分区。聚合对于网络接口可以只显示有活跃流量bytes_sent 0 or bytes_recv 0的接口如eth0wlan0 而忽略lo回环和众多Docker虚拟网卡。突出重点在返回的文本中用加粗或特定格式标记异常值如使用率80%的CPU核心、使用率90%的磁盘分区。7.3 安全与隐私考量问题5进程列表暴露了敏感信息。风险get_process_list返回的进程命令行可能包含数据库密码、API密钥等敏感信息例如./myapp --db-passwordsecret123。缓解措施命令行脱敏在服务器端对返回的进程命令行进行正则匹配脱敏。例如将匹配--password\S、--key\S等模式的内容替换为--password***。这需要仔细设计规则避免误伤。权限控制如前所述以低权限用户运行服务器它只能看到该用户有权看到的进程信息这本身就是一个安全边界。意识教育最重要的是永远不要在命令行参数中传递明文密码。应使用环境变量或配置文件。问题6如何控制AI助手的“行动范围”核心原则MCP服务器定义了AI的“能力边界”。你给它什么工具它就只能做什么。最佳实践按需部署不要运行一个“全能”的MCP服务器。为不同的安全等级需求运行不同的服务器实例。例如一个只读的“系统信息查询”服务器和一个具备“服务重启”能力的服务器分开。审慎开放写操作像kill_process、write_file这类工具开放前要三思。如果必须开放可以考虑增加“二次确认”机制例如工具要求传入一个confirmation_token该token需要用户从另一个安全渠道获取。网络隔离确保MCP服务器只通过stdio与本地客户端通信绝不暴露端口到外部网络。这个项目就像为你的AI助手装上了一双感知本地环境的“眼睛”它的价值不在于工具本身有多复杂而在于它如何将标准化的系统状态无缝融入你与AI的对话流中。从一次简单的“电脑为什么卡”的询问到构建一个自动化的运维监控分析链路它的可能性由你的想象力和实际需求决定。我最深刻的体会是配置过程本身也是对MCP协议和系统监控的一次深入学习而成功连接后那种“AI真的懂我电脑状态”的体验会让整个开发运维工作流变得前所未有的流畅和智能。
和矩阵存储为例)
