从零开发Python MCP Server：打造你的AI智能体插件

AI智能体已经能聊天、能回答问题了，但很多人卡在同一个地方：怎么让它长期记住并管理你的个人数据？比如记录饮食、体重、断食，一个月后还能精确统计，而不是每次重新对话。B站“大熊课堂”用一期视频给出了一个干脆的解法——用Python写一个MCP Server，把数据操作交给程序，把交互交给AI智能体。

为什么需要MCP Server？

现在的AI可以记录“今天吃了什么”，也能回答“我最近七天摄入多少热量”。问题在于，这些记忆是对话式的、非结构化的。一个月后想按天查询、修改某条记录或者做趋势统计，聊天记忆根本撑不住。

正如视频中所说，AI智能体的聊天记忆没法结构化数据，要完成“最近一个月体重变化了多少”“删除某一天的饮食记录”这类操作，必须依赖数据库和精确的SQL查询。于是系统被拆成两部分：AI智能体负责理解语言、估算热量、分析需求；Python程序负责存储、查询、修改和删除。两者通过MCP协议连接。

AI智能体聊天记忆的局限

MCP到底是什么？

MCP全称Model Context Protocol，中文译为“模型上下文协议”，最早由Anthropic（Claude模型背后的公司）提出。现在主流AI智能体和大模型公司都接受并遵循了这一协议，各类服务厂商也在跟进。

视频里用一段动画解释了它的价值：AI想访问文件、调用工具，但每个工具都有不同的接入方式，混乱不堪。MCP提供了一种标准化的连接方式，AI说“我需要这个信息”，MCP负责把请求传输到正确的工具，再把结果带回给AI。一句话概括：AI是大脑，工具是手，MCP是它们之间的标准连接。

一个Python函数如何变成AI工具

先看一个普通函数：它接收食物名称和卡路里两个参数，用来记录饮食。函数本身没问题，但AI智能体并不知道它存在——不知道放在哪、接收什么参数、怎么执行。

使用MCP SDK后，只需在函数前加一个装饰器，标记为MCP工具，函数体完全不用改。AI智能体连接到这个MCP服务后，就能发现工具、理解用途，并在合适的时机调用它。

用MCP SDK注册Python函数为工具

MCP在技术实现上采用客户端-服务器架构：AI智能体作为MCP客户端，通过标准化的JSON-RPC消息与MCP服务器通信。协议定义了三种核心能力——工具（Tools，可执行的操作，如增删改查）、资源（Resources，可供读取的数据，如数据库记录）、提示（Prompts，预设的交互模板）。服务器通过list_tools等方法向客户端声明自己提供哪些工具及其参数模式（JSON Schema），客户端据此决定何时调用、传什么参数。这种设计使工具接入与具体AI模型解耦，同一个MCP服务器可被Claude、ChatGPT等不同智能体复用，这也是它被业界广泛采纳的关键原因。

MCP SDK的核心抽象是FastMCP服务器对象：开发者实例化服务器后，用@mcp.tool()装饰器标记函数，SDK会自动从函数签名和类型注解（如food_name: str, calories: int）生成JSON Schema参数描述，并注册到工具列表中。函数下方的docstring会被当作工具描述一并暴露给AI，因此写清楚docstring直接影响AI能否在正确时机调用。启动时调用mcp.run()即可通过stdio或HTTP/SSE传输层对外提供服务。这意味着函数体内的业务逻辑与MCP协议完全解耦，同一函数既能被AI调用，也能在普通Python脚本中直接测试。

职责划分：AI与MCP各司其职

这个项目的设计思路很清晰。AI智能体负责它擅长的事：理解自然语言、识别食物名称、估算热量和营养成分、分析历史记录、用自然语言回答用户。MCP服务负责程序擅长的事：接收AI传来的参数、验证参数、查询数据库、执行增删改查、返回执行结果。

AI智能体与MCP服务各司其职

举个例子：用户说“今天早上我吃了一根中等大小的香蕉，请记录一下”。AI智能体先估算香蕉的热量、蛋白质、碳水、脂肪，然后调用记录食物的工具，参数可能是食物名称、热量、重量、营养元素、餐次类型（早餐）。工具写入数据库后返回结果，AI再告诉用户“已记录早餐香蕉，热量多少”。

整个过程没有调用任何第三方营养API，也没有开发iOS应用或小程序。传统做法需要识别语句、调用热量接口、建食物热量对照表、匹配、统计、写库，非常繁琐；而现在，这些繁琐操作被AI智能体自身的理解能力接了过去，开发者只需要写好MCP工具。

课程要开发什么？

视频明确了四个核心数据模块，每个都做增删改查：饮食记录、运动记录、体重记录、断食记录。功能听起来简单，但覆盖了个人健康追踪的主要场景。

体重记录等四个数据模块的增删改查

技术选型也很务实：Python编写MCP Server，调用第三方包即可，专注业务逻辑；MCP SDK负责注册和运行工具；SQLite作为单文件数据库，持久化存储且支持SQL增删改查；包管理用UV（PIP也行）；本地调试用MCP Inspector；连接AI智能体用OpenAI工具做桥梁。

部署：从本地到云端

本地测试有个绕不开的问题：电脑一关，本地MCP服务就停了，AI智能体连不上。解决方案是用Docker把MCP服务部署到云服务器，7×24小时运行，随时随地通过AI智能体记录和查询数据。

值得一提的是，整个方案没有使用任何Python后端框架，也没有前端。界面就是AI智能体现成的对话窗口——打字、语音、拍照都能直接操作MCP Server。三个角色理清楚：AI智能体是交互入口，MCP Server是工具，SQLite是数据存储。

MCP Inspector是官方提供的本地调试工具，运行后会在浏览器中打开一个交互界面，列出服务器注册的所有工具，允许手动填写参数、触发调用并查看返回的原始JSON结果。它相当于MCP服务器的"Postman"，能在接入AI智能体之前验证工具是否按预期工作、参数校验是否生效、数据库读写是否正确。调试通过后再配置智能体连接，可以显著减少排查链路中"究竟是AI调用错了还是工具本身有bug"的成本。

这套方案适合谁？

如果你想让AI智能体真正管理个人数据，而不只是聊天，MCP Server是一条值得走的路。它把复杂应用的开发成本压到很低：不用做UI，不用接第三方API，不用写完整后端，只需要定义好工具函数和数据库操作。AI负责“听懂人话”，程序负责“管好数据”，边界清晰，配合自然。

视频到这里只是开篇，下一节才正式进入代码编写。但光是这个架构思路，已经足够说明MCP为什么正在成为AI智能体连接外部世界的标准方式。