基于MCP协议构建AI邮件助手：lettr-mcp架构设计与实现详解

1. 项目概述一个连接AI与外部世界的“翻译官”最近在折腾AI应用开发的朋友估计都绕不开一个词MCPModel Context Protocol。简单来说它就像给大语言模型比如ChatGPT、Claude装上了一套标准化的“手”和“眼睛”让AI不仅能和你聊天还能安全、可控地去操作外部的工具、查询数据库、读取文件甚至控制智能家居。而今天要聊的这个lettr-com/lettr-mcp就是一个非常典型的MCP服务器实现它来自一个叫Lettr的团队。你可以把它理解为一个专门为AI打造的“邮件助手”或“通讯接口”。它的核心使命就是让AI模型能够通过一套标准协议去调用邮件相关的功能。想象一下你正在和Claude对话说一句“帮我查一下昨天客户发来的邮件并总结要点”Claude就能通过这个lettr-mcp服务器安全地连接到你的邮箱执行查询、阅读、甚至回复的操作然后把结果用自然语言反馈给你。整个过程你不需要手动登录邮箱、复制粘贴AI替你完成了所有繁琐的中间步骤。这个项目之所以值得关注不在于它实现了多么复杂的邮件协议事实上它可能基于成熟的库如nodemailer或imap而在于它精准地踩中了AI Agent智能体发展的关键节点工具调用Tool Calling的标准化。以前每个AI应用想连接外部服务都得自己写一套胶水代码协议五花八门安全也难以保障。MCP的出现就是为了解决这个“最后一公里”的问题。lettr-mcp作为一个具体领域的MCP实现为我们提供了一个绝佳的样板去理解如何将一个现实世界的服务电子邮件安全、高效地“暴露”给AI模型使用。对于开发者而言研究它你能学到如何基于MCP协议构建自己的工具服务器对于AI应用使用者理解它你能更清晰地看到未来AI如何无缝融入你的工作流。接下来我们就从设计思路开始一层层拆解这个项目。2. 核心设计思路与架构拆解2.1 为什么是MCP协议选择的深层考量在lettr-mcp出现之前让AI操作邮件并非不可能。你可以写一个脚本用OpenAI的Function Calling或者LangChain的Tool定义来调用一个发送邮件的函数。但这会带来几个显著问题紧耦合与重复劳动你的邮件功能代码和特定的AI应用框架如LangChain绑定死了。如果想换一个AI前端比如从Claude Desktop换到其他兼容MCP的客户端几乎需要重写一遍集成逻辑。安全性挑战如何将敏感的邮箱凭证安全地传递给AI应用硬编码在客户端环境变量每次都需要复杂的配置。能力发现与动态性AI模型如何知道你这个“邮件工具”具体能干什么是只能发送还是能搜索、标记、管理文件夹传统的集成方式需要静态地声明功能列表不够灵活。MCP协议正是为了解决这些问题而生的。它的核心思想是“关注点分离”工具提供方Server如lettr-mcp只专注于一件事提供稳定、安全的邮件操作能力。它定义好工具Tools并准备好资源Resources比如收件箱列表。AI模型端Client如Claude Desktop、Cursor等只专注于理解和规划通过标准协议向Server请求执行工具或读取资源。协议层MCP充当中间的标准“语言”规定双方如何打招呼初始化、Server能提供什么列表工具/资源、Client如何请求调用工具、结果如何返回。对于lettr-mcp的开发者来说选择实现MCP协议意味着一次开发多处使用只要遵循MCP协议这个邮件服务器可以被任何兼容MCP的客户端使用极大扩展了工具的适用范围。内置的安全模型MCP强调Server独立运行通常通过进程间通信IPC或SSEServer-Sent Events与客户端连接避免了将敏感逻辑和凭证暴露在AI应用进程中。凭证管理、连接池、错误重试等都可以封装在Server内部。动态的工具描述Server可以在初始化时动态地告诉客户端“我这里有这些工具可用比如send_email,search_emails每个工具需要什么参数参数是什么类型。” AI模型可以根据这些描述自主决定在何时、如何使用它们。2.2 lettr-mcp 的架构猜想与模块划分虽然我们无法看到其未开源的完整代码但基于MCP协议规范和项目描述我们可以合理推断lettr-com/lettr-mcp的架构主要由以下几个核心模块构成协议适配层MCP Adapter职责这是项目的“外壳”负责实现MCP协议定义的所有标准接口。包括initialize与客户端握手声明自身能力。tools/list列出所有可用的邮件工具。tools/call接收客户端的工具调用请求解析参数并分发给对应的业务逻辑处理器。resources/list与resources/read可能用于提供只读的邮件资源如“未读邮件列表”、“特定标签的邮件”等。实现很可能使用官方提供的MCP SDK如TypeScript的modelcontextprotocol/sdk来构建这能处理大部分协议通信的底层细节。业务逻辑层Email Service Core职责这是项目的“心脏”包含了所有真实的邮件操作逻辑。每个MCP工具Tool都对应这里的一个服务函数。核心工具猜想send_email调用SMTP库构建并发送邮件。需要处理收件人、主题、正文纯文本/HTML、附件等。search_emails连接IMAP服务器根据关键词、发件人、时间范围等条件搜索邮件。get_email获取特定邮件ID的详细内容和元数据。mark_as_read/unread标记邮件的已读/未读状态。move_email将邮件移动到其他文件夹。实现会依赖成熟的Node.js邮件库如nodemailer(用于发送/SMTP)、imap或node-imap(用于接收/IMAP)。配置与凭证管理Configuration Manager职责安全地加载和管理邮箱连接所需的敏感信息。这是安全性的关键。实现方式绝不会将密码硬编码在代码中。通常通过环境变量如EMAIL_USER,EMAIL_PASSWORD,EMAIL_IMAP_HOST,EMAIL_SMTP_HOST或配置文件如config.json但需加入.gitignore来读取。更高级的实现可能会支持OAuth 2.0认证流程避免直接使用密码。连接池与状态管理Connection Pool职责管理到IMAP/SMTP服务器的网络连接。对于IMAP保持长连接并监听新邮件如果支持通知是常见需求但需要妥善处理连接超时、重连逻辑。重要性避免为每个工具调用都建立和断开连接这能极大提升性能尤其是频繁搜索或监听时。错误处理与日志Error Handling Logging职责将底层邮件库的复杂错误如网络错误、认证失败、协议错误转化为MCP协议规定的、AI模型能理解的标准化错误信息。实现需要精细分类错误例如“凭证错误”、“网络超时”、“目标邮箱不存在”并以结构化的方式返回给客户端方便AI模型向用户给出准确的反馈。这个架构设计确保了核心的邮件功能与MCP协议层解耦。未来如果MCP协议升级或者想把这个邮件能力以其他方式如REST API提供只需要替换或增加适配层即可核心业务代码几乎不用动。3. 关键实现细节与核心技术点剖析3.1 MCP工具Tools的定义与设计哲学在lettr-mcp中每一个邮件操作都对应一个MCP工具。工具的定义不仅仅是函数名更是一份给AI模型的“说明书”。这份说明书的质量直接决定了AI模型能否正确、高效地使用它。以send_email工具为例一个设计良好的定义可能包含{ name: send_email, description: Send an email to one or more recipients. Supports HTML and plain text content, as well as attachments., inputSchema: { type: object, properties: { to: { type: array, items: { type: string }, description: Email addresses of the primary recipients. }, subject: { type: string, description: Subject line of the email. }, body: { type: string, description: The HTML content of the email body. If plain text is needed, use the textBody parameter. }, textBody: { type: string, description: The plain text content of the email body. Used as a fallback if HTML is not supported. }, cc: { type: array, items: { type: string }, description: Email addresses to carbon copy. }, bcc: { type: array, items: { type: string }, description: Email addresses to blind carbon copy. } }, required: [to, subject, body] } }设计要点解析描述description要具体且包含用例不要只写“发送邮件”。要说明支持的功能HTML/纯文本、附件和典型使用场景。这能帮助AI模型在规划时做出更合适的选择。参数设计要符合AI的“思维”习惯to字段定义为数组因为AI模型自然理解“给张三和李四发邮件”是多个收件人。同时提供body(HTML) 和textBody(纯文本) 两个参数是很好的实践。AI模型如Claude通常更擅长生成结构化的HTML内容但邮件客户端兼容性需要纯文本回退。在实现时业务逻辑层应该优先使用HTMLbody同时将textBody作为备选或自动从HTML中提取纯文本。cc和bcc也是数组符合直觉。严格的输入校验inputSchemaMCP Server必须在调用工具前校验参数。lettr-mcp的实现里会利用JSON Schema来验证客户端传来的参数是否完整、类型是否正确。缺少to或subject就应该立即返回错误而不是让底层邮件库报出难以理解的异常。实操心得工具定义的“粒度”把握工具定义不是越细越好。是把“发送邮件”和“添加附件”拆成两个工具还是合并成一个这需要权衡。合并一个工具处理所有让AI单次调用更高效但参数会变复杂。拆分多个工具更符合“单一职责”但需要AI进行多次调用和状态管理。对于邮件场景send_email包含附件是合理的因为附件是邮件的一部分。但“搜索邮件”和“下载邮件附件”可能就是两个独立的工具因为搜索结果是列表下载是针对特定项的操作。lettr-mcp的设计者需要基于最常见的用户指令来划分工具边界。3.2 资源Resources的巧妙运用除了工具MCP还有“资源Resources”的概念。资源代表一些可被AI读取的、结构化的数据片段。在lettr-mcp中资源可能被这样使用resource://lettr/Inbox代表收件箱列表。客户端可以“读取”这个资源服务器返回一个当前收件箱邮件的摘要列表如ID、发件人、主题、时间。resource://lettr/Email/{id}代表一封具体的邮件。读取它返回邮件的完整内容、头部信息等。资源与工具的区别在于资源是只读的、用于获取信息工具是可执行的、用于改变状态。AI模型可以先通过list_resources发现有一个“收件箱”资源读取它来了解概况然后决定调用search_emails工具进行更精确的查询或者调用get_email工具或读取Email/{id}资源来查看详情。这种设计让AI与服务器的交互更加灵活和符合认知。用户问“我的收件箱有什么”AI可以直接读取一个资源来回答而不必调用一个可能带有副作用的“工具”。3.3 安全性与凭证管理实战这是lettr-mcp这类工具服务器最需要谨慎处理的部分。绝不能将邮箱密码写在代码或配置文件里提交到仓库。标准实践环境变量.env文件# .env.example (提供模板) EMAIL_USERyour-emailgmail.com EMAIL_PASSWORDyour-app-specific-password # 注意对于Gmail建议使用应用专用密码 EMAIL_IMAP_HOSTimap.gmail.com EMAIL_IMAP_PORT993 EMAIL_SMTP_HOSTsmtp.gmail.com EMAIL_SMTP_PORT587在代码中通过process.env.EMAIL_USER读取。使用dotenv包在开发时加载.env文件生产环境则由部署平台如Railway、Fly.io注入。OAuth 2.0更安全、更现代对于Gmail、Outlook等支持OAuth 2.0的邮箱服务这是首选方案。lettr-mcp服务器需要实现一个简单的Web回调端点引导用户完成授权流程获取access_token和refresh_token。将refresh_token安全地存储如加密后存数据库或安全的密钥管理服务用于长期获取新的access_token。这样服务器不保存用户密码只有有时效性的访问令牌且用户可以随时在邮箱提供商处撤销授权。在MCP上下文中的特殊考量MCP客户端如Claude Desktop如何将凭证传递给lettr-mcp服务器通常有两种模式服务器预配置lettr-mcp作为一个长期运行的后台服务在启动时就通过环境变量配置好了邮箱凭证。所有通过该服务器连接的客户端都共享这个邮箱身份。这适合个人使用或团队共享一个功能邮箱的场景。动态凭证传递更复杂MCP协议理论上支持在初始化时传递参数。但这要求客户端能安全地获取并存储用户凭证并将其传递给服务器。这对客户端的安全性提出了很高要求目前不是主流做法。因此大多数个人使用的MCP服务器都采用第一种“预配置”模式。重要警告关于应用专用密码如果你使用Gmail并启用了两步验证直接使用账户密码是无法通过SMTP/IMAP连接的。你必须生成一个“应用专用密码”。在lettr-mcp的配置中EMAIL_PASSWORD填的就是这个16位字符的专用密码而不是你的Gmail登录密码。这大大提升了安全性即使这个密码泄露也不会危及你的主账户。4. 从零构建一个类似的MCP邮件服务器理解了设计思路和关键点后我们可以尝试勾勒出一个简化版lettr-mcp的实现骨架。这里我们使用Node.js和官方MCP SDK。4.1 环境准备与项目初始化首先创建一个新项目并安装核心依赖mkdir my-email-mcp-server cd my-email-mcp-server npm init -y npm install modelcontextprotocol/sdk nodemailer imap dotenv npm install --save-dev typescript types/node types/nodemailer types/imap ts-node创建tsconfig.json{ compilerOptions: { target: ES2022, module: commonjs, outDir: ./dist, rootDir: ./src, strict: true, esModuleInterop: true, skipLibCheck: true } }创建.env文件并确保它在.gitignore中EMAIL_USERyouremailgmail.com EMAIL_PASSWORDyour-app-specific-password EMAIL_IMAP_HOSTimap.gmail.com EMAIL_IMAP_PORT993 EMAIL_SMTP_HOSTsmtp.gmail.com EMAIL_SMTP_PORT5874.2 核心服务器类实现在src/server.ts中我们开始构建MCP服务器import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { CallToolRequestSchema, ListToolsRequestSchema, Tool, } from modelcontextprotocol/sdk/types.js; import * as dotenv from dotenv; import nodemailer from nodemailer; import Imap from imap; dotenv.config(); // 配置检查 const requiredEnvVars [EMAIL_USER, EMAIL_PASSWORD, EMAIL_IMAP_HOST, EMAIL_SMTP_HOST]; for (const varName of requiredEnvVars) { if (!process.env[varName]) { console.error(错误缺少必需的环境变量 ${varName}); process.exit(1); } } class EmailMCPServer { private server: Server; private transporter: nodemailer.Transporter; private imapClient: Imap; constructor() { // 1. 初始化MCP服务器 this.server new Server( { name: my-email-mcp-server, version: 0.1.0, }, { capabilities: { tools: {}, // 声明我们支持工具 resources: {}, // 声明我们支持资源可选 }, } ); // 2. 设置请求处理器 this.setupHandlers(); // 3. 初始化邮件客户端懒加载或按需连接 this.transporter nodemailer.createTransport({ host: process.env.EMAIL_SMTP_HOST, port: Number(process.env.EMAIL_SMTP_PORT) || 587, secure: false, // 对于端口587通常使用STARTTLS auth: { user: process.env.EMAIL_USER, pass: process.env.EMAIL_PASSWORD, }, }); this.imapClient new Imap({ user: process.env.EMAIL_USER, password: process.env.EMAIL_PASSWORD, host: process.env.EMAIL_IMAP_HOST, port: Number(process.env.EMAIL_IMAP_PORT) || 993, tls: true, tlsOptions: { rejectUnauthorized: false }, // 仅用于测试生产环境应验证证书 }); } private setupHandlers() { // 处理工具列表请求 this.server.setRequestHandler(ListToolsRequestSchema, async () { const tools: Tool[] [ { name: send_email, description: 发送一封电子邮件。支持HTML正文、纯文本正文和附件基础实现。, inputSchema: { type: object, properties: { to: { type: array, items: { type: string }, description: 主要收件人的电子邮件地址列表。, }, subject: { type: string, description: 邮件主题。 }, htmlBody: { type: string, description: 邮件的HTML正文内容。 }, textBody: { type: string, description: 邮件的纯文本正文内容。如果未提供将从HTML中提取。 }, cc: { type: array, items: { type: string }, description: 抄送CC的电子邮件地址列表。, }, bcc: { type: array, items: { type: string }, description: 密送BCC的电子邮件地址列表。, }, }, required: [to, subject, htmlBody], }, }, { name: search_emails, description: 在收件箱中搜索符合条件的邮件。返回匹配邮件的简要列表。, inputSchema: { type: object, properties: { query: { type: string, description: 搜索关键词用于匹配主题或正文。 }, from: { type: string, description: 发件人地址。 }, maxResults: { type: number, description: 返回的最大结果数默认10。, default: 10 }, }, required: [], }, }, ]; return { tools }; }); // 处理工具调用请求 this.server.setRequestHandler(CallToolRequestSchema, async (request) { const { name, arguments: args } request.params; try { switch (name) { case send_email: return await this.handleSendEmail(args as any); case search_emails: return await this.handleSearchEmails(args as any); default: throw new Error(未知的工具: ${name}); } } catch (error: any) { // 将错误转换为MCP协议格式 return { content: [ { type: text, text: 工具调用失败: ${error.message}, }, ], isError: true, }; } }); } private async handleSendEmail(args: { to: string[]; subject: string; htmlBody: string; textBody?: string; cc?: string[]; bcc?: string[]; }) { const { to, subject, htmlBody, textBody, cc, bcc } args; // 如果没有提供纯文本正文尝试从HTML中简单提取生产环境应用更健壮的库如html-to-text const plainText textBody || this.htmlToText(htmlBody); const mailOptions { from: MCP Email Server ${process.env.EMAIL_USER}, to: to.join(, ), subject, text: plainText, html: htmlBody, cc: cc ? cc.join(, ) : undefined, bcc: bcc ? bcc.join(, ) : undefined, }; const info await this.transporter.sendMail(mailOptions); return { content: [ { type: text, text: 邮件发送成功消息ID: ${info.messageId}, }, ], }; } private async handleSearchEmails(args: { query?: string; from?: string; maxResults?: number }) { const { query, from, maxResults 10 } args; // 这是一个简化的搜索实现。真实场景需要构建IMAP搜索条件数组。 const searchCriteria: any[] [ALL]; // 搜索所有邮件 if (from) { searchCriteria.push([FROM, from]); } // 注意IMAP的TEXT搜索开销大且不支持中文等复杂分词。这里仅为演示。 if (query) { searchCriteria.push([TEXT, query]); } return new Promise((resolve, reject) { const results: Array{ seqno: number; subject: string; from: string; date: string } []; this.imapClient.once(ready, () { this.imapClient.openBox(INBOX, false, (err, box) { if (err) reject(err); this.imapClient.search(searchCriteria, (searchErr, resultsSeqnos) { if (searchErr) reject(searchErr); if (resultsSeqnos.length 0) { this.imapClient.end(); return resolve({ content: [{ type: text, text: 未找到匹配的邮件。 }], }); } // 限制结果数量 const fetchSeqnos resultsSeqnos.slice(0, maxResults); const fetch this.imapClient.fetch(fetchSeqnos, { bodies: [HEADER.FIELDS (FROM SUBJECT DATE)] }); fetch.on(message, (msg) { let buffer ; msg.on(body, (stream) { stream.on(data, (chunk) { buffer chunk.toString(utf8); }); }); msg.once(end, () { // 解析邮件头简化处理 const header Imap.parseHeader(buffer); results.push({ seqno: msg.seqno, subject: header.subject ? header.subject[0] : (无主题), from: header.from ? header.from[0] : 未知发件人, date: header.date ? header.date[0] : 未知日期, }); }); }); fetch.once(error, (fetchErr) reject(fetchErr)); fetch.once(end, () { this.imapClient.end(); const resultText results.map(r #${r.seqno}: 来自 ${r.from} - ${r.subject} (${r.date})).join(\n); resolve({ content: [{ type: text, text: 找到 ${results.length} 封邮件:\n${resultText} }], }); }); }); }); }); this.imapClient.once(error, (err) reject(err)); this.imapClient.connect(); }); } // 一个简单的HTML到纯文本的转换函数用于演示 private htmlToText(html: string): string { return html .replace(/[^]*/g, ) // 移除标签 .replace(/\s/g, ) // 合并空白字符 .trim(); } async run() { const transport new StdioServerTransport(); await this.server.connect(transport); console.error(MCP 邮件服务器已启动通过stdio传输); } } // 启动服务器 const server new EmailMCPServer(); server.run().catch(console.error);4.3 运行与测试编译并运行npx ts-node src/server.ts服务器会等待通过标准输入输出stdio接收MCP协议消息。这是Claude Desktop等客户端连接MCP服务器的标准方式。在Claude Desktop中配置 编辑Claude Desktop的MCP配置文件通常在~/Library/Application Support/Claude/claude_desktop_config.json或类似位置{ mcpServers: { my-email-server: { command: node, args: [/绝对路径/to/your/project/dist/server.js], env: { EMAIL_USER: your-emailgmail.com, EMAIL_PASSWORD: your-app-password, EMAIL_IMAP_HOST: imap.gmail.com, EMAIL_SMTP_HOST: smtp.gmail.com } } } }重启Claude Desktop后你就可以在对话中尝试“用我的邮箱给 testexample.com 发一封测试邮件主题是‘Hello from MCP’内容就写‘这是一封通过MCP服务器发送的测试邮件。’”注意事项IMAP连接管理上面的示例代码为了清晰在每次调用search_emails时都新建并断开IMAP连接。这在生产环境中是低效的。一个健壮的实现应该维护一个连接池或持久连接并处理自动重连。同时IMAP的TEXT搜索条件性能很差且对非ASCII字符支持不佳。真实项目应考虑使用HEADER搜索如[HEADER, Subject, query]或使用邮件服务商提供的更高效的搜索API如Gmail的API。5. 常见问题、排查与进阶思考5.1 部署与连接问题排查当你尝试运行或连接自己的MCP邮件服务器时可能会遇到以下典型问题问题现象可能原因排查步骤与解决方案服务器启动立即退出或报错1. 环境变量未正确设置。2. TypeScript编译错误。3. 依赖未安装。1. 检查.env文件是否存在且变量名正确或确保生产环境变量已注入。2. 运行npx tsc --noEmit检查TypeScript错误。3. 运行npm install确保所有依赖已安装。Claude Desktop无法识别服务器1. MCP配置文件路径或格式错误。2.command或args指向的路径不正确。3. Claude Desktop版本过旧不支持MCP。1. 确认配置文件路径正确JSON格式有效无尾随逗号。2. 使用绝对路径指向编译后的JS文件或ts-node脚本。确保Node.js在系统PATH中。3. 更新Claude Desktop到最新版本。发送邮件失败报“认证失败”1. 邮箱密码错误特别是Gmail未使用应用专用密码。2. SMTP服务器地址/端口错误。3. 邮箱提供商的安全设置如“允许不够安全的应用”已关闭。1. 对于Gmail前往账户安全设置生成并使用16位应用专用密码。2. 核对SMTP主机和端口Gmail: smtp.gmail.com:587。3. 对于Gmail如果未启用两步验证可能需要暂时开启“允许不够安全的应用”不推荐建议用OAuth或应用密码。搜索邮件失败或超时1. IMAP服务器地址/端口错误。2. 网络问题或防火墙阻止。3. IMAP连接未正确结束导致资源泄漏。1. 核对IMAP主机和端口Gmail: imap.gmail.com:993。2. 尝试使用telnet imap.gmail.com 993测试网络连通性。3. 确保代码中在所有路径成功、错误上都正确调用了imapClient.end()。工具调用无响应或超时1. 服务器代码中存在未捕获的异常导致进程崩溃。2. 工具处理函数是同步的或包含阻塞操作未及时返回Promise。1. 在服务器入口函数添加process.on(uncaughtException, ...)全局错误处理记录日志。2. 确保所有工具处理器都是async函数或返回Promise。对于长时间操作考虑流式返回部分结果。5.2 性能、安全与生产化考量一个玩具级的MCP服务器和可用于日常生产的服务器之间存在巨大鸿沟。以下是lettr-com/lettr-mcp这类项目需要考虑的进阶问题连接池与超时管理问题为每个工具调用创建新的IMAP/SMTP连接在频繁请求下会导致性能瓶颈和端口耗尽。方案使用连接池库如generic-pool管理IMAP连接。SMTP的nodemailer本身支持连接池通过pool: true配置。必须为所有连接设置合理的超时commandTimeout,greetingTimeout等和最大重试次数。错误处理与重试逻辑问题网络闪断、邮件服务商临时故障会导致工具调用失败。方案实现指数退避的重试机制。对于暂时性错误如网络超时、5xx错误自动重试几次。对于永久性错误如认证失败、无效地址直接返回给用户。错误信息应友好例如“无法连接到邮件服务器请检查网络”而非底层的“ECONNREFUSED”。支持多邮箱账户挑战当前的单环境变量设计只支持一个邮箱。如何让AI操作多个邮箱思路这触及了MCP协议的设计边界。一种方案是让lettr-mcp服务器管理一个“默认”邮箱。更复杂的方案是扩展协议让客户端在调用工具时通过参数指定邮箱配置但这需要客户端管理多套凭证。更常见的生产模式是为每个需要连接的用户或团队部署一个独立的lettr-mcp服务器实例。附件处理与大小限制实现send_email工具需要支持attachments参数类型为数组每个元素包含filename,content(base64编码),contentType。服务器端需要解码base64并构造邮件附件。限制必须设置附件大小上限如10MB防止内存耗尽或被滥用。对于大附件可以考虑先上传到云存储然后在邮件中发送链接。更精细的权限控制场景你可能希望AI只能“读”邮件不能“发”邮件或者只能发送给特定域名的地址。实现在工具调用处理器内部根据预定义的策略如访问控制列表ACL进行校验。例如在handleSendEmail函数开头检查to地址的域名是否在白名单内。5.3 超越邮件MCP生态的启示lettr-com/lettr-mcp的价值不仅在于它本身更在于它展示了一种范式如何将任何现有的API或服务“MCP化”。你可以遵循同样的模式创建calendar-mcp让AI帮你查询日历、创建会议。github-mcp让AI浏览代码仓库、创建Issue、评论PR。database-mcp让AI安全地查询数据库通过严格的SQL模板或自然语言转SQL并限制为只读或特定表。smart-home-mcp让AI控制灯光、恒温器通过Home Assistant或米家等平台的API。核心步骤总是相似的定义能力边界想清楚你要暴露给AI哪些安全、可控的操作Tools和数据Resources。封装现有SDK利用该领域成熟的客户端库如Gmail API SDK、GitHub Octokit、数据库驱动实现业务逻辑。实现MCP协议层使用MCP SDK将你的业务逻辑函数包装成标准的Tool和Resource。加固安全与配置处理好认证、凭证管理、输入校验、错误处理和日志。通过lettr-mcp这个案例我们看到MCP协议正在成为AI与真实世界交互的“USB-C接口”——标准化、可插拔、生态丰富。作为开发者现在正是深入理解并参与构建这个生态的好时机。从将一个自己常用的服务封装成MCP服务器开始你就能亲手为AI赋予一项新的“超能力”。