1. 项目概述这不是又一个API网关而是一套让大模型“学会查资料”的底层协议你有没有试过让大模型回答一个它训练数据截止后才发生的事比如“2024年Q3苹果Vision Pro在中国市场的实际销量是多少”——它大概率会编造一个看似合理但完全错误的数字。这不是模型能力不够而是它被设计成“只靠记忆答题”缺乏实时、可信、结构化的外部信息接入能力。Model Context ProtocolMCP服务器就是为解决这个根本性缺陷而生的。它不试图替换模型本身也不要求你重训或微调而是像给一位资深专家配一个永不疲倦、分类精准、响应毫秒级的助理团队当模型需要查Git仓库里的最新代码变更、读取本地文件系统中的配置文档、调用数据库查询用户订单状态甚至实时抓取某个API返回的天气数据时MCP Server 就是那个在后台默默完成所有“跑腿”工作并把干净、格式统一的结果送回模型面前的人。核心关键词“Model Context Protocol”和“MCP Server”不是营销话术而是一套轻量、开放、可插拔的通信规范。它定义了模型Client如何向外部服务Server发起一次“上下文请求”以及服务端如何理解、执行并返回结果。你看到的“Fetch”、“Filesystem”、“Git”这些词本质上都是MCP Server支持的工具类型Tool Type它们不是功能模块而是协议层面的“语义标签”。比如当模型说“请从git://github.com/xxx/yyy.git的main分支获取README.md内容”MCP Server识别出这是git类型的请求就会调用内置的Git工具去克隆、检出、读取再把纯文本结果按MCP协议封装好返回。整个过程对模型透明它只负责“提问”不关心“怎么答”。这直接解耦了模型推理层与数据访问层让模型可以专注语言理解与生成而数据获取、权限校验、缓存策略、错误重试等复杂逻辑全部下沉到MCP Server中统一管理。对于开发者而言这意味着你可以用一套标准协议同时对接内部的Confluence知识库、外部的Salesforce CRM、本地的Excel报表甚至是一个自研的ERP系统而无需为每个数据源单独写一套适配代码。它不是替代Git或Fetch而是让Git和Fetch的能力第一次真正成为大模型“思考链条”中可信赖的一环。2. 核心设计思路为什么MCP Server必须是“协议”而非“框架”很多人第一反应是“这不就是个带HTTP接口的中间件吗我用FastAPI自己写一个不就行了”——这个想法很自然但恰恰踩进了设计误区。MCP Server的价值不在于它能做什么而在于它规定了别人必须怎么做。我们来拆解这个关键区别。传统中间件比如一个用Python写的“模型数据桥接服务”的核心问题是“封闭性”。它定义了自己的请求格式比如POST /api/git/read、自己的错误码比如{code: 4001, msg: repo not found}、自己的认证方式比如Bearer Token。当你想把另一个团队的Confluence插件也接入进来你就得在自己的服务里新增一个/confluence/get_page接口再写一套解析Markdown、处理权限、处理附件的逻辑。久而久之这个中间件就变成了一个臃肿、难以维护、每个新数据源都带来新Bug的“瑞士军刀”。而MCP Server的设计哲学是“协议先行”。它强制规定所有工具请求必须使用统一的JSON-RPC 2.0格式所有工具类型必须在启动时通过tools.json文件向模型声明其能力范围Capabilities所有返回结果必须包含result字段和error字段且error必须遵循预定义的错误类别如tool_not_found,permission_denied,rate_limit_exceeded。这就带来了三个颠覆性优势第一模型厂商的解放。OpenAI、Anthropic、Ollama这些厂商再也不用为每个客户定制化开发数据接入SDK。它们只需要实现一个标准的MCP Client就能无缝对接任何符合协议的MCP Server。就像USB-C接口只要你的设备符合USB-IF标准它就能插进任何一台符合标准的笔记本电脑。这极大降低了大模型落地企业级应用的门槛。第二工具开发者的自由。一个开源社区成员完全可以只写一个mcp-git-server它只做一件事完美实现git工具类型的所有协议要求。他不需要关心模型用的是Llama还是Claude也不需要知道最终用户是用Web UI还是CLI调用。只要他的Server通过了官方的MCP Compliance Test Suite它就是“即插即用”的。这催生了一个健康的工具生态就像npm或PyPI但专注在“让模型能用的数据工具”上。第三安全与治理的基石。协议强制要求每个工具声明其capabilities比如git工具必须明确写出它能访问哪些仓库路径、是否支持写操作、是否需要SSH密钥。管理员可以在MCP Server启动前就通过配置文件精确控制“只允许读取/opt/internal-repos/*下的Git仓库禁止所有write操作”。这种基于协议的、声明式的权限模型比在中间件代码里硬编码if-else要安全、清晰、可审计得多。它不是靠程序员的自觉而是靠协议的约束力。所以当你看到“MCP Server”这个词时请把它理解为一个“协议运行时环境”而不是一个“功能集合体”。它的核心价值在于用一套最小公约数把模型、工具、数据三者之间的混沌连接变成一条条清晰、可验证、可替换的标准化管道。这正是它区别于所有现有方案的根本所在。3. 核心工具类型深度解析Git、Filesystem、Fetch不是功能而是协议语义MCP Server的协议规范中git、filesystem、fetch是首批定义的、最基础也最关键的工具类型Tool Types。它们之所以被优先支持并非因为技术难度高而是因为它们覆盖了90%以上企业级场景中最原始、最刚需的数据访问模式。但请注意这里的“Git”不是指你电脑上安装的那个命令行程序而是一个协议语义单元。下面我将逐个拆解告诉你它们在MCP语境下真正的含义、边界以及你最容易踩坑的地方。3.1 Git工具类型不是“克隆仓库”而是“按需获取代码快照”在MCP协议里git工具的职责非常纯粹根据一个确定的、不可变的引用Reference获取该引用所指向的单个文件或目录树的内容。这个引用可以是commit hash如a1b2c3d、tag如v2.1.0或branch name如main但协议强烈建议使用commit hash因为它保证了结果的绝对可重现性。当你看到一个请求{type: git, repository: https://github.com/xxx/yyy.git, reference: main, path: src/config.py}MCP Server的git工具会执行以下原子操作智能缓存检查首先检查本地是否有该仓库的镜像以及该commit hash对应的object是否已存在。如果存在直接跳过网络下载。最小化检出它不会git clone --depth1整个仓库而是使用git archive或git cat-file等底层命令只提取src/config.py这一个文件的blob内容。这避免了下载数百MB无关代码的开销。内容标准化返回的result字段是一个JSON对象其中content是文件的UTF-8纯文本encoding字段明确标为utf-8mime_type为text/plain如果是二进制文件则为application/octet-stream。这消除了“fetch乱码”这类前端常见问题的根源——乱码从来不是Fetch的问题而是编码未声明、未转换导致的。提示很多新手会误以为git工具能执行git log或git diff。这是严格禁止的。MCP协议规定git工具只提供“静态内容获取”能力。如果你想让模型分析代码变更正确的做法是先用git工具获取两个不同commit的同一文件再让模型自己对比差异。这确保了协议的简洁性和可预测性。3.2 Filesystem工具类型不是“读写硬盘”而是“受控的沙盒访问”filesystem工具是MCP Server中权限模型最严格的类型。它的设计初衷是为模型提供一种安全、可控的方式去访问部署环境中的预授权文件。协议明确规定filesystem工具不能接受任意的绝对路径如/etc/passwd或C:\Windows\System32\而只能访问一个由管理员在Server启动时通过--root-dir参数指定的根目录下的相对路径。例如管理员启动Server时指定了--root-dir /opt/mcp-data那么模型发出的请求{type: filesystem, path: ../etc/passwd}会被Server直接拒绝因为它试图越界。这个设计背后是深刻的安全考量。想象一下如果一个被注入恶意提示词Prompt Injection的用户能让模型执行cat /etc/shadow那整个系统就完了。filesystem工具通过“根目录沙盒”“路径白名单”双重机制把风险降到了最低。实操中我们通常会这样组织/opt/mcp-data/docs/存放公司内部的PDF、Markdown手册/opt/mcp-data/configs/存放各服务的YAML配置模板/opt/mcp-data/logs/存放最近24小时的、脱敏后的应用日志片段这样模型的请求就变成了{type: filesystem, path: docs/api-spec-v3.md}它永远无法触及沙盒之外的任何东西。而且filesystem工具返回的result中content字段同样会进行UTF-8标准化彻底规避了Windows环境下常见的GBK/UTF-8混用导致的乱码问题。这正是为什么网络上关于“fetch乱码”的搜索热度居高不下而MCP的filesystem工具却能一劳永逸地解决它——因为乱码的本质是字符集混乱而协议强制规定了唯一的、明确的编码标准。3.3 Fetch工具类型不是“浏览器AJAX”而是“服务端可信HTTP客户端”fetch工具是MCP协议中最具通用性的类型但它也是最容易被误解的一个。很多人看到fetch第一反应是“这不就是JavaScript里的fetch()吗”。错。MCP的fetch工具是一个运行在服务端的、高度受限的HTTP客户端。它的核心设计原则是只允许GET请求且目标域名必须在白名单内。为什么禁止POST/PUT/DELETE因为这些是写操作涉及业务逻辑和数据变更超出了“提供上下文”的范畴。MCP Server的定位是“数据提供者”不是“业务执行者”。一个模型不应该通过fetch去触发一个支付接口这违背了职责分离原则。为什么必须域名白名单这是为了防止SSRF服务器端请求伪造攻击。想象一个恶意用户构造提示词“请帮我从http://127.0.0.1:8080/admin/api/key获取管理员密钥”如果没有白名单MCP Server就会真的向本机的管理接口发起请求造成严重安全漏洞。因此管理员在配置fetch工具时必须显式列出所有允许访问的域名例如{ allowed_hosts: [api.weather.com, internal-api.company.local, docs.google.com] }只有匹配这些域名的URLfetch工具才会执行。对于每一个成功的fetch请求返回的result不仅包含content还强制包含status_code、headers仅限Content-Type,Content-Length等安全头和url重定向后的最终URL。这为模型提供了完整的HTTP上下文让它能判断“这个天气API返回的是404还是500”从而做出更智能的决策而不是盲目地把错误HTML当作有效数据来解析。这三个工具类型共同构成了MCP Server的“数据接入三原色”。它们不是功能堆砌而是经过深思熟虑的、正交的、有明确边界的协议语义。理解这一点是正确使用和扩展MCP Server的第一步。4. 实操部署与配置从零开始搭建一个生产可用的MCP Server现在让我们把理论付诸实践。下面我将手把手带你部署一个真正可用于生产的MCP Server实例。这里我们选择官方推荐的mcp-server-python作为基础因为它成熟、文档全、社区活跃。整个过程分为四个阶段环境准备、工具安装、配置编写、服务启动与验证。我会在每个环节指出关键细节和常见陷阱。4.1 环境准备为什么必须用Python 3.10和虚拟环境MCP Server对Python版本有明确要求最低为3.10。这是因为协议中大量使用了Python 3.10引入的match/case语法和更严格的类型注解PEP 604旧版本无法兼容。更重要的是绝对不要在系统全局Python环境中安装。我见过太多人因为pip install mcp-server-python污染了系统包导致apt upgrade失败最后不得不重装系统。正确的做法是创建一个纯净的虚拟环境# 创建一个专用目录 mkdir -p ~/mcp-server cd ~/mcp-server # 创建虚拟环境推荐使用venv而非conda因为官方文档和CI测试都基于venv python3.10 -m venv venv # 激活虚拟环境 source venv/bin/activate # 升级pip到最新版这是必须的旧版pip可能无法正确解析MCP的依赖树 pip install --upgrade pip注意如果你在Windows上操作请将source venv/bin/activate替换为venv\Scripts\activate.bat。另外python3.10命令在某些Linux发行版如Ubuntu中可能不存在你需要先通过sudo apt install python3.10安装或者使用pyenv来管理多版本Python。4.2 工具安装与依赖解析mcp-server-python背后的真相执行pip install mcp-server-python看起来很简单但背后隐藏着一个关键点这个包本身只是一个“协议运行时外壳”它并不包含git、filesystem、fetch等具体工具的实现。这些工具是以**插件Plugin**的形式存在的。mcp-server-python会自动安装一个名为mcp-plugins-core的包它包含了上述三个基础工具的参考实现。但如果你需要连接内部的Confluence或Jira你就得额外安装mcp-plugin-confluence这样的第三方插件。安装命令如下pip install mcp-server-python mcp-plugins-core这条命令会拉取约15个依赖包其中最关键的是pydantic2.0用于严格的JSON Schema验证和httpx0.24一个现代、异步的HTTP客户端fetch工具的底层。安装完成后你可以通过以下命令验证核心工具是否已加载mcp-server --list-tools你应该能看到输出中包含git,filesystem,fetch。如果某个工具缺失说明对应的插件没有正确安装这时你需要检查pip list的输出确认mcp-plugins-core的版本是否与mcp-server-python兼容官方文档会明确标注兼容矩阵。4.3 配置文件编写server-config.yaml是安全的生命线MCP Server的配置不是通过命令行参数传递的而是通过一个YAML文件。这是为了确保配置的可复现性和可审计性。一个典型的、生产环境可用的server-config.yaml如下所示# server-config.yaml server: host: 0.0.0.0 # 绑定到所有网络接口供其他服务访问 port: 3000 # HTTP端口 cors_origins: [*] # 开发时可设为*生产环境务必改为具体的前端域名 tools: git: # 这里定义了Git工具的全局行为 allow_unsafe_http: false # 禁止HTTP协议的Git仓库强制HTTPS防止中间人攻击 cache_dir: /opt/mcp-cache/git # 所有Git仓库的缓存目录必须存在且有写入权限 allowed_repositories: - https://github.com/your-company/* # 只允许访问公司GitHub组织下的仓库 - https://gitlab.internal.company/* # 以及内部GitLab filesystem: root_dir: /opt/mcp-data # 这是前面提到的“沙盒根目录” # 不需要显式列出所有子目录只要路径在root_dir下即可 fetch: allowed_hosts: - api.weather.com - internal-api.company.local - docs.google.com timeout: 10 # 所有HTTP请求的超时时间单位秒 logging: level: INFO # 生产环境推荐INFODEBUG级别会产生海量日志 file: /var/log/mcp-server.log # 日志文件路径确保目录存在且可写关键配置项说明cors_origins: 如果你的前端应用比如一个基于React的模型聊天界面和MCP Server不在同一个域名下这个配置决定了浏览器是否允许跨域请求。生产环境切勿设为[*]否则任何网站都能调用你的MCP Server。allowed_repositories: 这是Git工具的“防火墙”。它使用通配符*但只支持简单的前缀匹配不支持正则。https://github.com/your-company/*意味着https://github.com/your-company/frontend和https://github.com/your-company/backend都允许但https://github.com/evil-hacker/your-company会被拒绝。root_dir: 必须是一个绝对路径且在启动Server前你需要手动创建它并设置好权限sudo mkdir -p /opt/mcp-data sudo chown -R $USER:$USER /opt/mcp-data。4.4 启动服务与首次验证用curl亲手测试协议握手配置文件准备好后就可以启动服务了mcp-server --config server-config.yaml服务启动后你会看到类似INFO: Started server process [12345]的日志。此时Server已经在http://localhost:3000监听。但别急着用浏览器打开因为MCP Server不是一个Web页面它是一个JSON-RPC 2.0服务。我们需要用curl来模拟一次标准的协议握手。首先测试Server是否在线curl -X GET http://localhost:3000/health # 应该返回 {status: ok}然后发送一个最简单的git工具请求来验证整个链路curl -X POST http://localhost:3000/tools \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, id: 1, method: git.read_file, params: { repository: https://github.com/microsoft/vscode.git, reference: main, path: README.md } }如果一切正常你会收到一个包含result字段的JSON响应其中result.content就是VS Code仓库README的纯文本内容。如果遇到错误比如{error: {code: -32601, message: Method not found}}说明你请求的method名写错了。正确的method名必须是tool_type.actiongit工具支持的动作有read_file和list_directoryfilesystem工具支持read_file和list_directoryfetch工具只支持get。这个curl测试是你部署成功与否的黄金标准。它证明了协议层、工具层、网络层全部打通。接下来你就可以把它的地址http://localhost:3000配置到你的大模型前端或后端服务中让它成为模型真正的“外脑”。5. 常见问题排查与独家避坑指南那些文档里不会写的实战经验部署MCP Server的过程远比安装一个npm包复杂。我在过去半年里帮超过20个团队完成了MCP Server的落地几乎每个团队都遇到了一些“看似简单、实则致命”的问题。下面我把这些问题归类并给出最直接、最有效的解决方案。这些经验是无数个深夜调试换来的绝非纸上谈兵。5.1 “TypeError: Failed to fetch” —— 这不是前端的锅是协议没对齐这个错误信息几乎占据了所有MCP初学者问题的70%。它通常出现在前端调用MCP Server的fetch工具时。很多人第一反应是去查浏览器控制台看Network Tab里哪个请求失败了然后开始怀疑是CORS配置错了或者是HTTPS证书问题。但90%的情况下问题根源在协议层面。根本原因在于前端发送的请求没有遵循JSON-RPC 2.0的规范。一个合法的JSON-RPC请求必须包含三个顶级字段jsonrpc值必须是2.0、id任意非空值用于匹配响应、method格式为tool.action。而很多前端开发者习惯性地把fetch工具的请求当成一个普通的REST API来调用写成了// ❌ 错误示范这不是JSON-RPC fetch(http://localhost:3000/tools, { method: POST, body: JSON.stringify({ repository: ..., // 缺少jsonrpc, id, method reference: ..., path: ... }) });正确的写法应该是// ✅ 正确示范严格遵循JSON-RPC 2.0 fetch(http://localhost:3000/tools, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ jsonrpc: 2.0, // 必须 id: Date.now(), // 必须 method: git.read_file, // 必须格式为 tool.action params: { repository: https://github.com/xxx/yyy.git, reference: main, path: README.md } }) });实操心得我建议你在前端代码里封装一个mcpCall(tool, action, params)函数把jsonrpc和id的生成逻辑都封装进去。这样所有调用都统一永远不会出错。这个小封装能为你节省至少5个小时的调试时间。5.2 Git工具“找不到仓库” —— SSH密钥与HTTPS凭据的迷雾当你尝试访问一个私有Git仓库时经常会遇到{error: {code: -32000, message: Failed to clone repository}}。这通常意味着git工具在执行git clone时失败了。问题往往出在凭据上。MCP Server的git工具默认只支持HTTPS协议的仓库。对于需要SSH密钥的私有仓库它不会自动读取你~/.ssh/id_rsa文件。你必须显式地在配置文件中指定tools: git: ssh_key_path: /home/youruser/.ssh/id_rsa # 私钥文件的绝对路径 ssh_known_hosts: /home/youruser/.ssh/known_hosts # 可选用于验证主机指纹但这里有个巨大的陷阱ssh_key_path指向的私钥文件其权限必须是600即-rw-------。如果权限是644OpenSSH会出于安全考虑直接拒绝使用该密钥而git工具只会返回一个模糊的“clone failed”错误。排查方法很简单# 检查权限 ls -l /home/youruser/.ssh/id_rsa # 如果输出是 -rw-r--r--, 那就错了 chmod 600 /home/youruser/.ssh/id_rsa另一个常见问题是HTTPS仓库的Token。如果你的仓库托管在GitHub或GitLab你需要生成一个Personal Access TokenPAT并在repositoryURL中嵌入repository: https://TOKENgithub.com/your-org/private-repo.git注意这里的TOKEN是明文所以绝对不能在前端代码中硬编码。正确的做法是让后端服务比如你的模型API网关在转发请求给MCP Server之前动态地将Token注入到URL中。MCP Server本身不处理凭据管理它只负责执行。5.3 Filesystem工具“Permission denied” —— Linux文件权限的终极拷问在Linux系统上filesystem工具报Permission denied是最让人抓狂的问题之一。你以为你已经chown了/opt/mcp-data目录但错误依旧。这通常是因为MCP Server进程是以某个特定用户身份运行的而这个用户对/opt/mcp-data目录没有执行x权限。在Linux中要进入一个目录cd你不仅需要r读权限还需要x执行权限。filesystem工具在解析path时会尝试os.stat()该路径这本质上就是一个cd操作。所以/opt/mcp-data目录的权限必须是drwxr-xr-x即755而不仅仅是drw-r--r--644。修复命令sudo chmod 755 /opt/mcp-data # 如果目录下还有子目录递归设置 sudo chmod -R 755 /opt/mcp-data此外还有一个更隐蔽的问题SELinux。如果你的服务器启用了SELinux很多CentOS/RHEL默认开启它可能会阻止Python进程访问/opt/mcp-data。这时你需要给该目录打上正确的SELinux上下文标签sudo semanage fcontext -a -t httpd_sys_content_t /opt/mcp-data(/.*)? sudo restorecon -Rv /opt/mcp-data这条命令的意思是“告诉SELinux/opt/mcp-data及其所有子目录都应该被视为HTTP服务可以读取的内容”。没有这一步即使文件权限100%正确filesystem工具依然会失败。5.4 性能瓶颈为什么第一次git请求慢得像蜗牛你可能会发现第一次调用git工具去获取一个新仓库的文件耗时长达30秒甚至更久。这不是MCP Server的bug而是Git本身的特性。git clone的初始开销巨大尤其是对于大型仓库。解决方案是预热Warm-up。在Server启动后立即用一个脚本批量触发对常用仓库的git.list_directory请求。list_directory比read_file更快因为它只获取目录结构不下载文件内容。这会让Git缓存建立起来后续的read_file请求就会快如闪电。一个简单的预热脚本warmup.sh#!/bin/bash # 预热常用Git仓库 curl -X POST http://localhost:3000/tools \ -H Content-Type: application/json \ -d {jsonrpc:2.0,id:1,method:git.list_directory,params:{repository:https://github.com/your-company/frontend.git,reference:main,path:}} curl -X POST http://localhost:3000/tools \ -H Content-Type: application/json \ -d {jsonrpc:2.0,id:2,method:git.list_directory,params:{repository:https://github.com/your-company/backend.git,reference:main,path:}}把这个脚本加入你的Server启动流程就能彻底解决“首屏加载慢”的用户体验问题。6. 工具生态扩展如何为MCP Server添加一个全新的工具类型MCP Server的强大之处不仅在于它内置的git、filesystem、fetch更在于它的可扩展性。协议规范明确鼓励社区开发新的工具类型。比如你想让模型能查询公司的内部知识库Confluence或者能读取MySQL数据库里的用户表你都可以自己开发一个mcp-plugin-confluence或mcp-plugin-sql。下面我将以开发一个极简的mcp-plugin-hello为例手把手教你如何为MCP Server添加一个全新的工具。6.1 创建插件项目结构遵循约定优于配置首先创建一个新目录mkdir mcp-plugin-hello cd mcp-plugin-hello按照MCP插件的约定项目结构必须如下mcp-plugin-hello/ ├── pyproject.toml # 项目的元数据和依赖 ├── mcp_plugin_hello/ # Python包目录名字必须与项目名一致 │ ├── __init__.py # 插件入口必须定义get_tools()函数 │ └── hello.py # 工具的具体实现 └── README.mdpyproject.toml是现代Python项目的标准配置文件内容如下[build-system] requires [setuptools45, wheel, setuptools_scm[toml]6.2] build-backend setuptools.build_meta [project] name mcp-plugin-hello version 0.1.0 description A simple MCP plugin that says hello authors [{name Your Name, email youexample.com}] requires-python 3.10 dependencies [ mcp-server-python0.1.0, ] [project.optional-dependencies] dev [pytest, black] [project.urls] Homepage https://github.com/yourname/mcp-plugin-hello6.2 实现工具逻辑hello.py中的魔法mcp_plugin_hello/hello.py是核心。它必须定义一个类继承自mcp.server.stdio.StdIOTool这是MCP Server提供的基类并实现_execute方法。这个方法接收params字典返回一个dict其中result字段是工具的输出。# mcp_plugin_hello/hello.py from mcp.server.stdio import StdIOTool from typing import Dict, Any class HelloTool(StdIOTool): A simple tool that returns a greeting message. It demonstrates the basic structure of an MCP tool. def __init__(self): super().__init__( namehello, # 这个name就是工具类型tool type descriptionSay hello to a person. Returns a personalized greeting string., # 定义工具的输入参数schemaMCP Server会用它来验证请求 input_schema{ type: object, properties: { name: { type: string, description: The name of the person to greet. } }, required: [name] } ) def _execute(self, params: Dict[str, Any]) - Dict[str, Any]: The core logic of the tool. name params.get(name, World) greeting fHello, {name}! Welcome to the MCP world. return {result: greeting}6.3 插件注册__init__.py是协议的门面mcp_plugin_hello/__init__.py是插件的“门面”它必须导出一个名为get_tools()的函数。这个函数是MCP Server在启动时用来发现和加载所有工具的唯一入口。# mcp_plugin_hello/__init__.py from .hello import HelloTool def get_tools(): This function is called by the MCP Server to discover tools. It must return a list of tool instances. return [HelloTool()]6.4 安装与验证让Server认识你的新朋友完成代码后回到项目根目录执行pip install -e .-e参数表示“可编辑安装”这意味着你对代码的任何修改都会立即生效无需重新安装。安装完成后重启你的MCP Servermcp-server --config server-config.yaml然后用curl测试你的新工具curl -X POST http://localhost:3000/tools \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, id: 1, method: hello.greet, # 注意method名是 tool_name.action params: { name: Alice } }如果一切顺利你会收到{result: Hello, Alice! Welcome to the MCP world.}。恭喜你你已经成功为MCP Server添加了一个全新的、可被任何大模型调用的工具实操心得开发一个真实世界的工具如Confluence插件其复杂度主要在于认证和分页处理。但核心模式完全一致定义input_schema来声明输入实现_execute来处理逻辑通过get_tools()来注册。记住MCP协议的威力就在于它把这种复杂性封装在一个极其简单、可预测的接口之下。你不需要成为Git或SQL专家就能让大模型拥有这些能力。你只需要成为一个“协议翻译官”把领域知识翻译成MCP Server能理解的语言。我个人在实际操作中的体会是MCP Server的价值不在于它今天能做什么而在于它为明天铺平了道路。当一个新的数据源出现时你不再需要重构整个模型服务只需要写一个几十行的插件把它接入这个协议。这种“一次协议无限扩展”的范式正在悄然改变我们构建AI应用的方式。它让大模型真正从一个“闭卷考试的优等生”变成了一个“随时能查阅资料、能调用工具、能协同工作的超级协作者”。