mini-cc MCP协议：统一AI接口标准

前言

MCP这一概念近期在AI领域引发了广泛讨论。它由Anthropic在2024年底提出，作为一套开放标准，其核心目标是使AI应用能够以标准化方式与外部工具和数据源进行对接。

什么是MCP

你可以将MCP理解为AI世界中的USB-C接口。过去，要为AI添加新能力（比如查天气、查询数据库、发送邮件），每个系统都需要单独编写对接代码。M个模型×N个工具，维护成本会呈指数级增长。

MCP要解决的核心问题正是标准化。采用MCP之后，复杂度从M×N变为M+N。任何一个MCP客户端都可以连接任何一个MCP服务器，就像USB-C接口一样实现了标准统一。

MCP的三个核心概念

根据官方规范，MCP定义了服务器能够提供的几类功能。具体而言，三个最核心的概念如下：

1. Tools（工具）：AI能够主动调用的函数，例如“查天气”“读文件”。这是最核心的能力，由AI自行决定何时调用。
2. Resources（资源）：被动提供的数据，例如文件内容、API数据。AI不能主动调用，只能在需要时读取。
3. Prompts（提示词模板）：预定义的提示词模板，用户可以一键调用。

举例来说：一个MCP Server可以同时提供“搜索文档”（Tool）和“项目说明文档”（Resource），AI既能自主决定何时需要搜索，也能在用户提问时直接读取文档。

架构：Host → Client → Server

MCP采用三层架构：

• Host：用户直接打交道的AI应用，如Claude Desktop、Cursor或mini-cc。
• Client：Host内部维护的模块，每个MCP Server对应一个Client，负责具体的JSON-RPC通信。
• Server：实际执行任务的后台，可以使用任何语言编写——Python、Node.js、Go、Rust均可。

通信采用JSON-RPC协议，传输方式支持stdio（本地进程间通信）和HTTP/SSE（远程服务）。

mini-cc中的MCP实现

那么mini-cc中这套机制具体如何实现？查看源码后会发现，其实并不复杂。

预加载策略

mini-cc采用预加载策略，而非按需加载。启动时将所有MCP Server连接好，工具直接注册到工具注册中心。

设计时面临一个选择：每次需要使用工具时再连接，还是启动时一次性连接？最终选择了预加载策略。原因是mini-cc运行过程中子Agent会频繁创建，如果每次创建都重新连接MCP Server，延迟会明显增加。启动时稍慢一点可以接受，但子Agent创建顺畅更重要。

当然，预加载也有代价——如果某个MCP Server出现故障，启动可能变慢甚至整体挂起。因此实现了容错处理：某个Server连接失败时仅打出警告并继续启动，不影响核心功能。

启动流程大致如下：

启动 mini-cc
↓
扫描 MCP Server 配置
↓
全部连接，获取工具列表
↓
注册到全局 ToolRegistry
↓
Agent 循环可以直接使用

配置文件的优先级

MCP Server的配置存放在.minicc/mcp.json文件中。配置文件的查找遵循优先级规则：先查找当前工作目录下的.minicc/mcp.json，若未找到则查找用户的~/.minicc/mcp.json，两者都找不到时视为没有MCP Server。

环境变量的优先级更高：环境变量 > 项目配置 > 全局配置。这样设计的好处是，可以在特定项目中配置特殊的MCP Server，而不影响其他项目。

两种Server连接方式

mini-cc支持两种MCP Server连接方式：

stdio模式：本地进程，通过标准输入输出进行通信，最为常用。配置示例：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/Desktop"],
      "env": { "DEBUG": "true" }
    }
  }
}

HTTP/SSE模式：远程服务，通过HTTP配合Server-Sent Events进行通信，适用于需要中心化部署的场景。

配置中还支持环境变量自动展开，格式为${ENV_VAR}或带默认值的${ENV_VAR:-default}。

工具适配器

mini-cc中有一个MCPToolAdapter，其工作方式非常直接：将MCP Server返回的工具定义进行包装，转换为mini-cc自身的Tool接口格式，然后在execute方法中将调用转发给MCP Client并等待结果。

class MCPToolAdapter implements Tool {
  name: string;
  description: string;
  inputSchema: JSONSchema;

  async execute(args: any, context: ToolUseContext): Promise<ToolResult> {
    const result = await this.client.callTool(this.name, args);
    return result;
  }
}

这样一来，Agent在调用工具时完全不知道这个工具是内置的还是MCP插件——接口已经抹平了所有差异。

MCP客户端的核心逻辑

MCP客户端核心并不复杂，就是通过stdio与Server进程通信，使用JSON-RPC发送请求并解析响应。

不过在编写客户端时，需要正确处理ChildProcess的标准输入输出。数据粘包（多个响应拼接在一起）或解析卡死的问题时有发生。好在官方MCP SDK（@modelcontextprotocol/sdk）已经封装了底层逻辑，可以直接使用。mini-cc中也引用了这个包。如果你自己编写MCP客户端，建议直接使用SDK，避免重复造轮子。

MCP的安全特性

需要明确指出，MCP协议本身不负责安全，安全需要自行实现。MCP的角色是运输层，而非安全层。不过mini-cc也设计了若干防护措施：

1. 进程隔离

每个MCP Server都是独立进程，崩溃不会影响主程序。同时实施了资源限制：

const process = spawn(serverPath, [], {
  stdio: ['pipe', 'pipe', 'pipe'],
  resourceLimits: {
    maxCPU: 1000, // 最多运行1秒CPU时间
    maxMemory: 512 * 1024 * 1024 // 限制512MB内存
  }
});

2. 严格模式

如果希望某个环境“必须”存在MCP Server，可以通过MINICC_MCP_STRICT=1环境变量让启动失败：

场景	普通模式	严格模式
缺少MCP依赖	警告 + 跳过	启动失败
MCP配置文件格式错误	警告 + 跳过	启动失败
MCP Server连接失败	警告 + 跳过	启动失败
没有MCP配置文件	正常运行	正常运行

这种设计非常实用：本地开发时MCP并非必需品，连接失败就跳过；但在CI/CD流水线上，如果MCP测试环境没有配置好，就应该提前报错，避免问题带入生产环境。

3. 用户审批

敏感操作需要用户明确授权，这在之前关于工具系统的文章中已详细说明。

MCP官方网站对安全提出了三条核心建议：

• 用户同意：涉及数据访问和操作必须获得用户明确同意
• 数据隐私：不得未经同意将用户数据传输给第三方
• 工具安全：工具本质上是可执行任意代码的，调用前必须由用户确认

mini-cc在设计时已基本考虑了这些原则。

测试你的MCP Server

开发MCP Server时如何进行调试？官方提供了一个MCP Inspector工具：

npx @modelcontextprotocol/inspector node your-server.js

打开浏览器即可看到Server暴露了哪些Tools和Resources，还可以交互式测试调用。在编写第一个MCP Server时，这个工具能够帮助逐步验证，节省大量时间。

一个简单的MCP Server示例

一个最简单的Node.js天气插件代码如下：

#!/usr/bin/env node
const { Server } = require('@modelcontextprotocol/sdk/server');
const { StdioServerTransport } = require('@modelcontextprotocol/sdk/server/stdio');

const server = new Server({
  name: 'weather-server',
  version: '1.0.0'
});

server.setRequestHandler('list_tools', async () => ({
  tools: [{
    name: 'get_weather',
    description: '获取城市天气',
    inputSchema: {
      type: 'object',
      properties: {
        city: { type: 'string', description: '城市名称' }
      },
      required: ['city']
    }
  }]
}));

server.setRequestHandler('call_tool', async (request) => {
  if (request.params.name === 'get_weather') {
    const city = request.params.arguments.city;
    const weather = cities[city] || { temp: '未知', condition: '未知' };
    return { content: `${city} 天气: ${weather.temp}°C ${weather.condition}` };
  }
});

const transport = new StdioServerTransport();
server.connect(transport);

配置完成后重启mini-cc，get_weather工具便会出现在Agent的工具列表中。当用户在聊天中提及天气时，Agent会自动决定调用这个工具。

总结

MCP协议是mini-cc插件生态的基石：

1. 标准化接口：统一的工具定义和调用方式，无需为每个AI单独编写对接代码
2. 语言无关：插件可以使用任何语言编写——Python、Node.js、Go、Rust均可
3. 安全隔离：插件运行在独立进程中，崩溃不会影响主程序
4. 预加载策略：启动时全部加载并缓存，子Agent创建时零延迟

如果觉得mini-cc自带工具不够用，随时可以自己开发MCP插件来扩展功能。

关于安全方面，MCP协议本身只定义了消息如何发送，安全仍需上层Host自行实现。mini-cc设计了一套审批流程，敏感工具调用前会弹出确认窗口。如果在生产环境中使用MCP，建议增加一个网关进行权限控制、审计和限流，否则日志和审计可能会比较棘手。