MCP 生态变热以后，一个新的问题开始浮出水面：工具越接越多，模型还没开始干活，光是读取工具列表和 JSON Schema 就已经消耗了一大段上下文。

今天推荐的 atlassian-labs/mcp-compressor 正是为这个问题设计的。它是 Atlassian Labs 开源的 MCP server wrapper，目前在 GitHub 上有 52 stars，最新版本 v0.19.6 发布于 2026 年 5 月 19 日。

项目概览

属性详情
仓库atlassian-labs/mcp-compressor
Stars52
Forks7
语言Rust、TypeScript、Python
许可Apache-2.0
最新版本v0.19.6

它解决什么问题

一个强大的 MCP server 往往会暴露几十甚至上百个工具。每个工具都带着名称、描述、输入参数、嵌套 JSON Schema。对于 Agent 来说，这些信息有时是必要的，但不是每一轮对话都需要完整展开。

mcp-compressor 的思路很简单：先给模型一个压缩后的工具表面，等模型确定要调用哪个工具时，再按需展开完整 schema。

这会带来三个直接收益：

  • 减少工具描述占用的上下文
  • 降低每轮请求的 token 成本
  • 让多个 MCP server 同时接入时更不容易撑爆上下文窗口

两种使用方式

作为 MCP 代理

如果你已经有一个 MCP client，可以把 mcp-compressor 放在 client 和后端 MCP server 之间：

mcp-compressor -c medium -- python server.py

前端模型通常只看到少数几个包装工具，例如：

  • list_tools
  • get_tool_schema
  • invoke_tool

模型先通过压缩列表选择目标工具，再请求完整 schema，最后调用真实后端工具。

作为 SDK 嵌入应用

项目也提供 Python、TypeScript 和 Rust SDK。对于自己写 Agent runtime 或工具编排层的人来说，可以直接在代码里启动本地 proxy。

TypeScript 示例大致是：

import { CompressorClient } from "@atlassian/mcp-compressor";

const proxy = await new CompressorClient({
  servers: {
    alpha: { command: "python", args: ["server.py"] },
  },
  compressionLevel: "medium",
}).connect();

这类 API 对开发自定义 Agent 系统很友好，因为它不要求所有东西都绕 stdio 子进程走。

为什么值得关注

我觉得 mcp-compressor 有意思的地方不在于“压缩”这个词，而在于它指出了 MCP 生态下一阶段的真实痛点：工具不是越多越好，工具面也需要设计。

当 Agent 连接一个小工具时，直接暴露完整 schema 没问题。但当它连接 Jira、Confluence、GitHub、浏览器、数据库、云服务这类大型 server 时，工具描述本身就会变成一种负担。

这其实和人类使用软件很像：我们不希望打开一个应用时，所有菜单、所有 API、所有高级设置同时摊在眼前。更合理的方式是先看到概览，需要时再展开细节。

适合谁

场景适合程度
正在写 MCP client很适合
维护大型 MCP server值得评估
做内部 Agent 平台很适合
只接入两三个简单工具暂时不一定需要
对 token 成本敏感值得尝试

需要注意的地方

项目还比较新，star 数也很低，说明它仍处于早期关注阶段。对于生产系统，最好先在低风险环境里测试：

  • 压缩后的工具描述是否足够让模型正确选择工具
  • schema 按需展开是否增加了调用轮次
  • 与现有 MCP client 的兼容性如何
  • 日志里是否能清楚追踪真实工具调用

换句话说，它不是“无脑加速器”，而是一个值得认真测试的 Agent 基础设施组件。

总结

mcp-compressor 是一个很小众但方向很准的项目。MCP 工具生态越繁荣，工具 schema 膨胀的问题就越明显。与其让模型每次背着一整包工具说明前进，不如给它一个更轻的入口。

如果你正在搭建自己的 Agent 工具链，尤其是已经接入多个 MCP server，这个 52 stars 的项目值得放进观察列表。

项目地址：https://github.com/atlassian-labs/mcp-compressor