创建自己的mcp server

官方示例参考

uv init 创建项目目录

uv venv， uv sync

uv venv = 创建虚拟环境，并为这个虚拟环境选择一个 Python 解释器uv sync = 根据项目的 pyproject.toml / uv.lock，把依赖同步安装到虚拟环境里

让 VS Code 选择这个虚拟环境

Ctrl + Shift + P
Python: Select Interpreter

安装开发mcp必备的依赖 uv add mcp[cli]

uv add "mcp[cli]" httpx

@mcp.tool 装饰器，把函数注册成工具，自动生成 schema（参数结构）=读取函数签名 + 类型注解 + docstring → 映射成 JSON Schema

把函数注册为tool,他会从函数的注释里面，提取这个函数的用途，以及每个参数的含义，并传给模型，以便模型决定调用这个函数的最佳时机

@mcp.tool()
👉 装饰器作用：
把函数注册成工具
自动生成 schema（参数结构）
让 LLM 可以调用

自动生成 schema = 读取函数签名 + 类型注解 + docstring → 映射成 JSON Schema

docstring 就是写在函数/类/模块里面的一段“官方说明文字”。只有“紧跟在定义后面的第一个字符串”，才是 docstring

mcp.run(transport=‘stdio’) 启动 MCP 服务，并用“标准输入/输出（stdio）”作为通信通道.mcp server与mcp client的沟通方式.启动一个可以被外部进程连接的协议服务端

mcp.run(transport=“stdio”) 的本质是：
把你的 MCP server 变成一个“通过标准输入输出接收 JSON-RPC 的进程级服务”

mcp.run(transport=“sse”)

启动 MCP server，并用 SSE（Server-Sent Events）作为“HTTP流式通信通道”，让客户端可以持续收发 JSON-RPC 消息
SSE 模式 = “MCP server 变成一个支持流式响应的 HTTP 服务”
mcp.run(transport=“sse”) = 启动一个基于 HTTP + SSE 的 MCP server，让工具调用结果可以以流式方式实时推送给客户端

下面是老版mcp的示例，常用sse交互参考改连接的sse章节

MCP SSE 模式 = “HTTP 发请求 + SSE 收响应”的双通道 JSON-RPC 系统

在 SSE 模式下：请求和响应是“分离的”——请求通过 HTTP 发出，响应统一通过 SSE 通道返回

流式协议如何在客户端重组结果

配置到cline中

{
  "mcpServers": {
    "weather": {
      "disabled": false,
      "timeout": 60,
      "command": "uv",
      "args": [
        "--directory",
        "D:\\code\\VideoCode\\MCP终极指南-进阶篇\\weather",
        "run",
        "weather.py"
      ],
      "transportType": "stdio"
    }
  }
}

uv --directory D:\code\VideoCode\MCP终极指南-进阶篇\weather run weather.py

让 uv 先切换到 weather 这个目录，
然后在这个目录对应的 Python 项目环境里，
运行 weather.py 这个脚本。

–directory 的说明就是：在运行命令之前切换到指定目录；相对路径会以该目录作为基准解析。

uv run 不用手动激活虚拟环境，直接用项目自己的 Python 环境运行命令。没有会自动创建

uv run 后面不一定只能跟 .py 文件，也可以跟各种命令

mcp 底层协议分析

mcp server是cline启动的，它的输入和输出只有cline才能看到，那我们怎么才能看到呢？
新建一个mcp_logger.py,脚本的参数就是启动mcp server的命令。用来获取cline与mcp server的输入和输出

"weather": {
      "disabled": false,
      "timeout": 60,
      "command": "python",
      "args": [
        "D:\\code\\VideoCode\\MCP终极指南-进阶篇\\weather\\mcp_logger.py",
        "uv",
        "--directory",
        "D:\\code\\VideoCode\\MCP终极指南-进阶篇\\weather",
        "run",
        "weather.py"
      ],
      "transportType": "stdio"
    }

输入输出和冒号是mcp_logger.py写的

cline->mcp server，initialize

你好我是cline，我的软件版本是3.12.3，我用的mcp协议是2024年11月5号出品的

mcp server->cline回复 initialize

你好呀，我用的协议版本和你一样，也是2024年11月5日的协议，另外我有这些能力不支持， 你要记好哦，对了，我叫weather，版本号是1.6.0，很高兴认识你

id=0是对客户端之前id=0的请求的响应。protocolversion，mcp协议的版本

serverinfo:mcp server的名字以及版本

"capabilities"表示这个 MCP server 支持哪些能力。

cline->mcp server "notifications/initialized"收到

cline->mcp server “tools/list”

我想知道mcp server里包含了哪些tool?

mcp sever->cline

get_forecast是获取某个地区的天气预报，并且把每个参数的含义也给了出来，这就是函数里面的注释，在python里叫docstring。@mcp.tool，会提取函数的docstring，放在description字段里，作为tool的描述，这样模型就可以从description中了解到tool的用途，方便选择与用户问题最匹配的tool

inputSchema遵循json schema规范，给出tool的入参规范
json schema本身就是一段json, 只不过这段json有个特殊的功能，它可以用来描述另外一个json的结构
inputSchema也是@mcp.tool从参数里提取出来的，根据参数定义来生成

title

“title” 不是你写出来的
👉 是 schema 自动生成器“顺手加的元数据”

cline->mcp server “resources/list”

cline 询问mcp server有没有资源可用，资源就是一个文件，一个报告之类的东西

cline-> mcp server “resources/templates/list”

cline 询问mcp server有没有资源模板可用，可以理解成动态模板

cline-> mcp server “prompts/list”

cline询问mcp server有有哪些 prompts（提示模板）可用？”

cline->mcp server tools/call

拿到请求之后，mcp server就会去执行对应的函数

mcp server->cline 回复工具调用的结果

cline->llm

之后cline把工具调用的结果发给llm

使用mcp 底层协议直接与mcp server交互

明白细节之后，可以不用mcp client,就可以直接与mcp server沟通，只需要保证发给mcp server的数据符合json-rpc的格式就行

1、终端启动mcp server

"uv --directory D:\\code\\VideoCode\\MCP终极指南-进阶篇\\weather run weather.py"

然后直接进行交互

mcp协议主要是规定了如何发现和调用函数，并没有规定如何与模型交互，只涉及中间，不涉及右边。mcp协议并没有规定如何与模型进行交互。mcp本质上就是一条函数发现与调用的协议

上下文就是环境，环境就是周围有哪些函数可以用来调用，从而获取外界信息，mcp就是让模型感知外部环境的协议。名字起的不太好，容易让人误以为这个协议是规定模型交互的内容

函数的注册与使用

每个mcp server有哪些函数可以用，如何调用这些函数

模型交互协议

Cline 把“工具列表、工具调用请求、工具返回结果”等信息，用 XML 标签包起来发给模型，让模型按这种格式输出要调用的工具。

cherry studio使用function calling

Function calling 是 OpenAI API 提出的一种“工具调用交互格式/能力”， 用来规定模型是怎么调用函数的。
Cline 和 Cherry Studio 的差异，是客户端给模型规定了什么输出格式，以及客户端按什么格式解析模型返回。
大多数模型可以通过 prompt 学会返回 XML/JSON 格式；但客户端必须知道按 XML 还是 function calling 去解析。原生 function calling 的区别是返回不只是普通文本，而是 专门的结构化字段

工具调用这件事被 API 结构化支持了

Function calling 的关键区别是：工具定义通常作为 API 请求里的独立参数传入，而不是塞进 system prompt 文本里

tools 参数不是直接给用户看的 prompt，而是 API 提供的结构化工具说明入口；服务端会把它转换成模型内部能理解的工具调用上下文

OpenAI / Anthropic 官方 API，会把 tools 这类结构化参数，转换成模型内部能理解的工具上下文，再参与推理