MCP (模型上下文协议)是什么？

模型上下文协议允许应用程序以标准化的方式为LLM提供上下文，从而将提供上下文的任务与实际的LLM交互分离开来。

在使用 Cursor AI 调用 MCP（Managed Code Protocol） 服务时，开发者可能会遇到以下痛点：

1. 官方 SDK 示例无法直接适配 Cursor AI

2. 重复性 MCP 代码开发

• 每个 MCP 服务都需要编写相似的 协议解析、错误处理、日志记录 等基础代码，增加了维护成本。

• 缺乏统一的工程化方案，不同 MCP 服务的代码风格和架构可能不一致，影响团队协作。

1. 官方 SDK 与 Cursor AI 的适配问题

主要原因在于一些核心的配置项如果缺失配置的话，CursorAI只会告诉你Client Closed，并不会告知关闭的原因，可能每次都要排查类似的问题。而这些核心配置项在官方SDK文档的位置也比较后面，对于初次开发的人员来说要定位问题比较麻烦。

2. 重复性 MCP 代码开发
（1）每个 MCP 服务需独立实现协议解析、错误处理等基础逻辑。  
（2）代码冗余，维护困难，且容易引入不一致性。  

对MCP SDK进行工程化封装，提供统一入口和基础模板。首个工具验证通过后，后续工具可复用相同模式快速接入，确保架构统一性。

@modelcontextprotocol/sdk

MCP官方TypeScript SDK，用于搭建MCP的服务器与客户端

Github地址：

https://github.com/modelcontextprotocol/typescript-sdk

作用：

• 提供MCP（Model Context Protocol）的核心功能

• 包含服务器创建、通信协议和类型定义

• 提供与LLM通信的标准接口

主要组件：

• Server：创建MCP服务实例

• StdioServerTransport：基于标准输入/输出的通信传输层

• CallToolRequestSchema：处理工具调用的请求模式

• ListToolsRequestSchema：处理工具列表查询的请求模式

示例用法：

zod

作用：

• 提供TypeScript优先的数据验证库

• 用于定义和验证工具输入参数的结构

• 提供丰富的验证规则和错误处理

主要功能：

• 类型定义与验证

• 自动类型推断

• 错误处理与格式化

• 模式组合与转换

示例用法：

参数说明：

• name：工具名称，使用下划线命名法（如your_tool_name）

• description：工具的详细描述，会展示给LLM

• inputSchema：输入参数的JSON Schema定义

• type：通常为"object"

• properties：定义各个参数的类型和描述

• 每个参数包含type和description

• 可以使用enum定义枚举值

• required：必需参数的名称数组

目录结构如下：

目标：开发一个主要处理将PSD文件中的图层按组的层次结构进行解析与导出，文字部分将会被清空的MCP，并处理为一个工程化MCP模板。

核心实现流程如下所示。

文件位置：src/config.ts

文件位置：src/tools/psd-slice.ts

文件位置：src/schemas/input.ts

文件位置：src/utils/helpers.ts

文件位置：src/index.ts

执行构建命令 npm run build 即可完成脚本的构建，构建产物在项目根目录的 build 文件夹下。

新增一个MCP的服务器

假设构建后脚本的绝对路径是：

/Users/KevinKwok/mcp/psd-slice-mcp/build/index.js。

我们自定义一个服务器的名称，并且将Type设置为command类型。

开启Cursor AI的YOLO模式，以支持能够在Agent中让AI直接调用MCP工具

至此，我们已经实现了相关的自动切图MCP工具服务，我们可以直接到新版Cursor中，开启Agent模式后直接对话调用相关的逻辑即可。

简单使用如下：

执行效果如图所示（可以看到图层结构与PSD文件内一致，preview为PSD的预览图）

在开发过程中，我们容易遇到以下的一些坑点：

1.初始化Server实例的时候，必须带上如下参数，否则MCP服务启动会失败报错。【Server does not support tools (required for tools/list)】

2.在定义输入与输出的参数中，如果涉及到文件路径相关的输入时，需要对参数添加需要为绝对路径的自然语言描述。否则在cursor AI调用相关工具的时候，其传入的文件路径不存在导致问题。

3.在使用已有MCP工具的时候（例如说构建好的产物），需要注意安装相关依赖，即需要确保相关内容在本地是可以直接正常执行的，否则也会使得MCP服务无法正常使用。

期望基于该MCP工程化项目构建一个智能化的MCP开发框架，以实现以下几点功能：

1.开发者提供工具的业务逻辑描述（自然语言/已有的脚本）

2.框架直接按照 config、tools、schema 几个核心步骤生成代码到MCP工程项目内

3.构建后直接能够在MCP的客户端（如Cursor）内直接使用

END