手把手教你：用蓝耘 MCP 的图片压缩 + 文件合并服务帮你搞定图片和文件的处理难题！

🌟 嗨，我是Lethehong！🌟

🌍 立志在坚不欲说，成功在久不在速🌍

🚀 欢迎关注：👍点赞⬆️留言收藏🚀

🍀欢迎使用：小智初学计算机网页IT深度知识智能体

🚀个人博客：Lethehong有一起互链的朋友可以私信我

✅GPT体验码：私信博主~免费领取体验码

目录

写在前面

关于MCP

MCP它是啥、干啥的？

MCP它为啥牛、有啥特别？

如何使用MCP

第一步：查看对应MCP的部署文档

第二步：召唤“瘦身大师” - 调用图片压缩服务

开始实操

第三步：召唤“合并小能手” - 调用文件合并服务

开始实操

写在最后

写在前面

1. 点击注册链接：蓝耘智算平台

2. 进入下面图片界面，输入手机号并获取验证码，输入邮箱，设置密码，点击注册

3. 注册之后点击访问蓝耘MCP Server商店：开启服务调用新旅程​​​​​​

4. 选择自己需要搭配的MCP Server即可

关于MCP

MCP它是啥、干啥的？

MCP，中文叫主控程序或多道程序控制程序，你可以把它想象成早期大型电脑（比如 Burroughs B5000 那些大家伙）系统里的大管家。它的活儿就是总管整个电脑：CPU 算力、内存空间、打印机磁带机这些设备，还有上面跑的各种程序（也叫作业或进程）。它最牛的本事是搞“多道程序”，意思就是能让好几个程序同时待在内存里，然后 MCP 这个管家在它们之间快速切换着用 CPU。这样一来，那些死贵的电脑硬件就不会闲着，整个系统的活也干得快多了。

MCP它为啥牛、有啥特别？

在电脑操作系统的历史上，MCP（特别是 Burroughs/Unisys 家的那个）绝对算得上是个开山立派的老前辈，想法特别超前。它不光是最早一批真正的操作系统，还玩出了很多后来才普及的招数：比如搞硬件支持的虚拟内存（让程序以为内存比实际大）、直接用 ALGOL 这种高级语言写系统软件（当时大多用难搞的汇编）、特别看重安全保密（文件系统设计得跟一个个独立保险柜似的）、还有自动化管理资源。MCP 的设计理念就仨字：好用、安全、高效！后来很多操作系统的设计都从它这儿偷了师，它证明了复杂的系统软件真能把电脑硬件管得服服帖帖，让多个程序同时跑起来。

如何使用MCP

场景： 你有一堆手机拍的或者网上下载的图片，体积太大占地方，想先给它们瘦个身（压缩），然后再把这些瘦身后的图片打包成一个 ZIP 文件，方便发给别人或者存档。你公司正好有现成的 MCP 服务可以用！

工具： 两个 MCP 服务器

1. MCP 图片压缩服务：图像工具MCP是一种模型上下文协议（MCP）服务，它通过TinyPNG API从URL和本地文件中检索图像尺寸并压缩图像。它支持将图像转换为webp、jpeg/jpg和png等格式，并提供关于宽度、高度、类型和压缩的详细信息。

2. MCP 文件合并： 通过简单的MCP界面，启用将多个文件合并到一个文件的功能。提供了一种安全的合并文件的方式，同时限制对仅允许的目录的访问。

在文件系统中找到图像压缩工具MCP+MCP文件合并器 

第一步：查看对应MCP的部署文档

点击图像压缩工具MCP，第二步进行介绍

点击MCP文件合并器，第二步进行介绍

读到这里想必大家已经有了一个很清晰的使用思路了 

第二步：召唤“瘦身大师” - 调用图片压缩服务

查图片大小，分网上和本地的：

• 网上看到一张图，想知道它多宽多高？告诉它图片网址 (get_image_size)，它立马告诉你尺寸、图片类型（是JPG、PNG还是WebP）和对应的文件格式说明。
• 你自己电脑里存了张照片，想看看信息？把文件位置告诉它 (get_local_image_size)，它也能一样给你报出来。

压缩图片，省空间利器：

• 网上找到的图太大？给它链接 (compress_image_from_url)，它调用好用的 TinyPNG 服务帮你压一压，图片质量看着还行，但文件变小很多。
• 自己拍的照片或者设计图太大占地方？把文件给它 (compress_local_image)，同样用 TinyPNG 压缩，轻松瘦身。

转换图片格式，按需变身：

• 需要把图变成更省流量的 WebP？或者转成最通用的 JPG/JPEG？再或者需要透明背景的 PNG？它都能搞定，在压缩或处理时指定想要的格式就行。

处理完告诉你详细结果（不管你是查尺寸还是压缩图片，它最后都会清清楚楚告诉你）：

• 宽度、高度（像素）
• 图片类型 (JPG, PNG, WebP)
• 对应的文件格式说明 (MIME类型)
• 如果是压缩过的，还会告诉你压缩效果怎么样，比如压缩前多大、压缩后多大，省了多少空间。

特别方便搞 Figma 设计稿的图：

• 设计师小伙伴给了你一个 Figma 设计稿链接？用 figma 这个功能！它能自动从 Figma 稿子里把里面的图片链接都扒拉出来，然后直接用 TinyPNG 挨个压缩好，一步到位，省得你一个个手动下载再压缩，贼省事。

简单说，这个服务打包成了五个现成的工具：

• get_image_size：查网图尺寸信息。

• get_local_image_size：查自己电脑里图片的尺寸信息。

• compress_image_from_url：压网图（给链接就行）。

• compress_local_image：压自己电脑里的图（给文件位置）。

• figma：专门对付 Figma 设计稿链接，自动找图+压缩。

怎么用呢？ 它是个 MCP 服务，意思就是你可以在你的程序或者工作流里，像调用一个现成的工具箱一样，方便地使用这五个工具来处理图片问题，省心省力。

客户端集成

要使用此 MCP 服务，您需要从 MCP 客户端连接到它。以下是如何与不同客户端集成的示例：

与 Claude Desktop 配合使用

1. 从 claude.ai/download 安装 Claude Desktop
2. 获取 TinyPNG API 密钥：访问 TinyPNG 并获取您的 API 密钥
3. 通过编辑配置文件来配置 Claude Desktop 以使用此 MCP 服务器：

{
  "mcpServers": {
    "image-tools": {
      "command": "npx",
      "args": ["image-tools-mcp"],
      "env": {
        "TINIFY_API_KEY": "<YOUR_TINIFY_API_KEY>",
        "FIGMA_API_TOKEN": "<YOUR_FIGMA_API_TOKEN>"
      }
    }
  }
}

1. 重启 Claude Desktop
2. 请求 Claude 获取图像尺寸：“你能告诉我这个图像的尺寸吗：D:/image.png”
3. 请求 Claude 压缩图像：“你能压缩这个图像吗：D:/image.png”
4. 请求 Claude 压缩本地图像：“你能压缩这个图像吗：D:/image.png”
5. 请求 Claude 压缩本地图像文件夹：“你能压缩这个文件夹吗：D:/image”
6. 请求 Claude 从 Figma API 获取图像链接：“你能从 Figma API 获取图像链接吗：Figma”

与 MCP 客户端库配合使用

import { McpClient } from "@modelcontextprotocol/client";

// Initialize the client
const client = new McpClient({
  transport: "stdio" // or other transport options
});

// Connect to the server
await client.connect();

// Get image dimensions from URL
const urlResult = await client.callTool("get_image_size", {
  options: {
    imageUrl: "https://example.com/image.jpg"
  }
});
console.log(JSON.parse(urlResult.content[0].text));
// Output: { width: 800, height: 600, type: "jpg", mime: "image/jpeg" }

// Get image dimensions from local file
const localResult = await client.callTool("get_local_image_size", {
  options: {
    imagePath: "D:/path/to/image.png"
  }
});
console.log(JSON.parse(localResult.content[0].text));
// Output: { width: 1024, height: 768, type: "png", mime: "image/png", path: "D:/path/to/image.png" }

// Compress image from URL
const compressUrlResult = await client.callTool("compress_image_from_url", {
  options: {
    imageUrl: "https://example.com/image.jpg",
    outputFormat: "webp" // Optional: convert to webp, jpeg/jpg, or png
  }
});
console.log(JSON.parse(compressUrlResult.content[0].text));
// Output: { originalSize: 102400, compressedSize: 51200, compressionRatio: "50.00%", tempFilePath: "/tmp/compressed_1615456789.webp", format: "webp" }

// Compress local image
const compressLocalResult = await client.callTool("compress_local_image", {
  options: {
    imagePath: "D:/path/to/image.png",
    outputPath: "D:/path/to/compressed.webp", // Optional
    outputFormat: "image/webp" // Optional: convert to image/webp, image/jpeg, or image/png
  }
});
console.log(JSON.parse(compressLocalResult.content[0].text));
// Output: { originalSize: 102400, compressedSize: 51200, compressionRatio: "50.00%", outputPath: "D:/path/to/compressed.webp", format: "webp" }

// Fetch image links from Figma API

const figmaResult = await client.callTool("figma", {
  options: {
    figmaUrl: "https://www.figma.com/file/XXXXXXX"
  }
});
console.log(JSON.parse(figmaResult.content[0].text));
// Output: { imageLinks: ["https://example.com/image1.jpg", "https://example.com/image2.jpg"] }

### Tool Schemas

#### get_image_size

```typescript
{
  options: {
    imageUrl: string // URL of the image to retrieve dimensions for
  }
}

get_local_image_size

{
  options: {
    imagePath: string // Absolute path to the local image file
  }
}

compress_image_from_url

{
  options: {
    imageUrl: string // URL of the image to compress
    outputFormat?: "image/webp" | "image/jpeg" | "image/jpg" | "image/png" // Optional output format
  }
}

compress_local_image

{
  options: {
    imagePath: string // Absolute path to the local image file
    outputPath?: string // Optional absolute path for the compressed output image
    outputFormat?: "image/webp" | "image/jpeg" | "image/jpg" | "image/png" // Optional output format
  }
}

figma

{
  options: {
    figmaUrl: string // URL of the Figma file to fetch image links from
  }
}

技术实现

该项目基于以下库构建：

• probe-image-size - 用于检测图像尺寸
• tinify - 通过 TinyPNG API 进行图像压缩
• figma-api - 用于从 Figma API 获取图像链接

环境变量

• TINIFY_API_KEY ： 用于图像压缩功能。从 TinyPNG 获取您的 API 密钥
• FIGMA_API_TOKEN ： 用于从 Figma API 获取图像链接。从 Figma 获取您的 API 令牌

开始实操

将下面这串代码添加进去

{
  "mcpServers": {
    "image-tools": {
      "command": "npx",
      "args": ["image-tools-mcp"],
      "env": {
        "TINIFY_API_KEY": "<YOUR_TINIFY_API_KEY>",   自己修改
        "FIGMA_API_TOKEN": "<YOUR_FIGMA_API_TOKEN>"  自己修改
      }
    }
  }
}

上图已经显示可以启动了，然后我们直接点击测试

我先弄了一个图片进行测试，图片代码放下面

const fs = require('fs');

// 创建一个1x1像素的透明PNG图片的Buffer
const pngBuffer = Buffer.from([
  0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A, // PNG签名
  0x00, 0x00, 0x00, 0x0D, 0x49, 0x48, 0x44, 0x52, // IHDR块开始
  0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, // 宽度和高度(1x1)
  0x08, 0x06, 0x00, 0x00, 0x00, 0x1F, 0x15, 0xC4, 
  0x89, 0x00, 0x00, 0x00, 0x0A, 0x49, 0x44, 0x41, 
  0x54, 0x78, 0x9C, 0x62, 0x00, 0x02, 0x00, 0x00, 
  0x05, 0x00, 0x01, 0xE2, 0x26, 0x05, 0x9B, 0x00, 
  0x00, 0x00, 0x00, 0x49, 0x45, 0x4E, 0x44, 0xAE, 
  0x42, 0x60, 0x82  // IEND块
]);

// 写入文件
fs.writeFileSync('./public/test.png', pngBuffer);
console.log('成功创建测试图片: ./public/test.png');

 这里显示测试成功，没问题

于是我就弄了一个前端页面，这样功能就显而易见了，到这里就完成了图片压缩工具的搭建

第三步：召唤“合并小能手” - 调用文件合并服务

干啥用的？简单说就是“打包文件”： 这个小工具就干一件事儿——把你指定的多个文件，咔咔一合并，变成一个大的文件。甭管是几个文件，也不管它们有多大，它都能搞定。

特点就是：快、稳、省心、透明：

• 简单： 不用搞复杂操作，一条命令（告诉它要合并哪些文件和合并后放哪儿）就齐活。

• 快： 处理文件很麻利，多大的文件合并起来都不墨迹。

• 安全： 这点很重要！它只在你“允许”的文件夹里活动，不会到处乱翻你的电脑，只动你让它动的文件。

• 透明： 合并完了，它会清清楚楚告诉你：原来每个文件多大，合并后文件总共多大，都合并了哪些文件，让你心里明明白白。

怎么用？两个主要“开关”：

• merge_files (合并文件)：

  • 你告诉它： 要合并哪些文件 (inputPaths - 一个文件路径的清单)，还有合并好的大文件放哪儿、叫啥名 (outputPath)。

  • 它告诉你： 干完了！并且附上刚才说的那份“合并详情报告”（包含了文件大小和合并摘要）。

• list_allowed_directories (看看它能进哪些屋)：

  • 这个就是让你查一下，你之前到底“允许”了它能在哪些文件夹里找文件合并。一目了然，更放心。

这就是个让你轻松把一堆文件打包成一个的工具，操作简单、速度飞快、不乱动你东西、事后还给你详细清单。想合并文件了，就用merge_files告诉它目标和结果位置；想看看它能在哪活动，就用list_allowed_directories查查。

开始实操

这里一样是先安装相对应的模块，否则后续的工作无法开展

# Clone and install
git clone https://github.com/exoticknight/mcp-file-merger.git
cd mcp-file-merger
npm install
npm run build

然后再在你的 Craft_mcp_settings.json 中添加下面的代码模块：

{
  "mcpServers": {
    "file-merger": {
      "command": "npx",
      "args": [
        "-y",
        "@exoticknight/mcp-file-merger",
        "/path/to/allowed/dir"
      ]
    }
  }
}

最终展示的页面如下，唯一的缺陷就是前端有点单调，集成的功能较少，大家可以尝试一下利用MCP制作一个简易的工具箱，那样一定会很完美

小提示：如果只添加一个文档，则无法点击“合并文件”按钮

写在最后

第一，权限是头号大敌！ 这个最容易出岔子。你得保证你用来跑压缩服务和打包服务的那个程序（或者你登录操作的用户账号），实实在在地能访问所有它需要碰的文件和文件夹。具体说就是：它得能看到你那些原始的、没压缩的图片；压缩服务跑完后，它得能把压缩好的图片写进你指定的那个中转文件夹；然后打包服务启动时，它得能从中转文件夹里读到那些压缩好的图片；最后，打包服务还得有权限把生成的ZIP包写进你指定的最终存放位置。特别是如果你用的是云存储（像S3这种），千万别光看文件夹路径对不对！一定要去那个“桶”（Bucket）的管理界面里，仔细检查它的访问权限设置（就是ACL、IAM Policy那些），确认你的程序或者服务账号真的有读写的“钥匙”。 这个地方没配好，后面全白干。

第二，文件路径一定要对得上号，两边都能通。 压缩服务把压缩好的图片吐到哪里了？你告诉打包服务去拿的地方，必须和压缩服务放的地方一模一样！而且最关键的是，压缩服务能写进去，打包服务也得能读出来。最省心、最不容易出错的办法，就是用一个公共的、大家都能访问的地方当中转站。比如公司内网的共享文件夹（NFS或者SMB），或者直接用云上的对象存储（S3之类的）。这样压缩服务放完东西，打包服务立马就能找到，路径也清晰。要是路径写错一个字，或者两边访问权限不匹配，打包服务铁定会报错说“找不到文件”，抓瞎。

第三，提前想好万一出错了怎么办。 事情不会总那么顺利。图片压缩可能会失败，比如某张图本身坏了，或者格式压缩服务根本不认识，或者服务自己抽风了。打包也可能失败，比如上面说的找不到文件、没权限、甚至中转站磁盘满了。你得知道去哪里看服务的运行日志，或者最好服务能提供出错通知（比如发个邮件、发个钉钉消息），告诉你具体是哪一步、哪个文件出了问题。 在你写脚本或者搭自动化流程的时候，一定要考虑这些意外情况。比如，尝试失败后要不要自动重试几次？如果某张图就是压不了，是跳过它继续处理后面的，还是整个任务都停掉？出严重错误了，能不能自动发个警报给负责人？这些处理逻辑加进去，流程才够稳。

第四，压缩和打包的参数别瞎设，先试试水。 压缩的时候，那个质量滑块（比如80%）不是随便拉的。你得在图片体积（小了省空间、传得快）和清晰度（别糊得没法看）之间找个平衡点。批量处理一大堆图之前，强烈建议先拿一两张不同类型的图试试手，看看效果满不满意。 打包设置也一样，最后ZIP包叫什么名字、存到哪个具体位置、ZIP包里面的文件要不要放子文件夹里（比如都放进一个压缩后图片的文件夹里），这些细节都确认好再开干，免得出来个ZIP包跟你想要的结构不一样。

第五，想偷懒省事？可以搞自动化！ 如果每次都要手动操作太麻烦，尤其是图片很多的时候，你可以写个小脚本（用Shell或者Python都行），让它按顺序自动调用压缩服务的API，等压缩完成了，再自动调用打包服务的API。如果任务量特别大，或者流程比较复杂（比如要等压缩完成才能打包），可以考虑用更专业的工具来编排流程，像Airflow、Luigi，或者看看蓝耘MCP平台自己有没有提供工作流工具。 更高级点，可以设置成压缩服务一完成工作，就自动发个消息（比如通过消息队列）去触发打包服务启动，这样连等都不用你等，全自动流水线。

最后，千万！千万！去看文档！ 别嫌麻烦，也别光听别人说。提供的这两个具体MCP服务的文档，一定要仔细读！每个服务的API地址（URL）、调用时需要哪些参数、用什么方式认证（API Key还是Token？）、支持哪些具体功能（比如压缩支持哪些图片格式？打包能不能指定密码？）... 这些细节都可能不一样，文档里才有准信儿。 照着文档操作，能避开很多低级错误，比如地址拼错了、参数名写错了这种冤枉路。 

总结一下我的流程核心（可能从前端看，并没有这么详细，只有看代码才知道）：

[你的原始图片] --> (上传/放置) --> [MCP 图片压缩服务]
                              |
                              | (压缩服务输出到) --> [共享存储位置 A]
                              |
                              V
[MCP 文件合并服务] <-- (告诉它去读取 [共享存储位置 A] 的文件) <-- (你调用合并服务)
                              |
                              | (合并服务输出到) --> [最终 ZIP 存放位置 B]
                              |
                              V
                      [你去位置 B 拿 ZIP 包！]

按照这个步骤走，理清楚权限和文件路径，你就能轻松驾驭这两个 MCP 服务，让它们乖乖帮你处理图片和打包文件了！快去试试吧！遇到具体问题（比如 API 怎么调、路径怎么写）再查你们服务的文档或者F12一下看一下控制台是否报错，如果有报错，在根据报错的原因去网上找解决办法。

​