快速开始： 将下面的 prompt 发送给你的 Coding Agent：
请从 https://github.com/timerring/PicGo-MCP 安装并配置 PicGo MCP Server。
一个将 PicGo Core 直接嵌入进程的 MCP stdio server。它可以让 Codex、Claude Desktop 等 MCP 客户端复用已有的 PicGo 图床配置，不要求 PicGo 桌面端运行，也不经过 127.0.0.1:36677。
直接调用 PicGo Core 3，无桌面端依赖。
支持本地文件、file:// URL 和 HTTP(S) 图片 URL。
支持单图与最多 20 张图片的批量上传。
自动发现 PicGo Desktop、PicGo Core 和 CLI 配置。
支持自定义上传文件名与返回格式。
并发调用自动排队，避免 PicGo 的可变上传状态互相污染。
状态工具不返回 token、secret 等配置值，并将用户主目录显示为 ~。
Related MCP server: flin-imgbb-mcp
Node.js >=20.19.0
一个可工作的 PicGo 配置文件
从源码安装：
npm install
npm run build
npm install -g .确认命令可用：
picgo-mcp --helpcodex mcp add picgo -- picgo-mcp
codex mcp get picgo新增 MCP server 后，新建任务或刷新客户端，使工具清单重新加载。
全局安装后，可以使用以下 stdio 配置：
{
"mcpServers": {
"picgo": {
"command": "picgo-mcp"
}
}
}需要明确指定配置文件时：
{
"mcpServers": {
"picgo": {
"command": "picgo-mcp",
"args": ["--config", "/path/to/picgo/config.json"]
}
}
}也可以设置环境变量 PICGO_CONFIG_PATH。--config 的优先级高于环境变量和自动发现。
默认按顺序查找：
macOS：~/Library/Application Support/picgo/data.json
Windows：%APPDATA%/picgo/data.json
Linux：$XDG_CONFIG_HOME/picgo/data.json 或 ~/.config/picgo/data.json
所有平台：~/.picgo/config.json
下面的示例将图片上传到仓库的 images/ 目录，并通过 jsDelivr 返回 CDN 地址：
{
"picBed": {
"uploader": "github",
"current": "github",
"github": {
"repo": "OWNER/REPOSITORY",
"branch": "main",
"path": "images/",
"customUrl": "https://cdn.jsdelivr.net/gh/OWNER/REPOSITORY@main",
"token": "YOUR_GITHUB_TOKEN"
}
},
"picgoPlugins": {},
"settings": {
"picgoMcp": {
"uploadNameTemplate": "${dateTime}-${fileName}${extName}",
"outputFormat": "${url}"
}
}
}GitHub token 需要对目标仓库具备写入权限。不要把真实 token 提交到 Git、Issue、日志或聊天记录中，并将配置文件权限限制为当前用户可读：
chmod 600 ~/.picgo/config.jsonPicGo Core 3 首次读取旧版配置时可能补充 uploader 配置和内部元数据，这是正常的自动迁移行为。
配置位置：
{
"settings": {
"picgoMcp": {
"uploadNameTemplate": "${dateTime}-${fileName}${extName}"
}
}
}支持的变量：
变量 | 示例 | 说明 |
|
| 本地日期 |
|
| 精确到秒的本地时间 |
|
| 原文件名，不含扩展名 |
|
| 原扩展名 |
|
| 批量上传时的零基序号；单图上传为空 |
推荐使用：
${dateTime}-${fileName}${extName}只使用 ${dateTime}${extName} 可能让同一秒内上传的图片发生重名。模板只执行白名单占位符替换，不执行 JavaScript，并且不允许通过文件名写入 ../ 等额外路径；远端目录应使用上传器的 path 配置。
配置位置：
{
"settings": {
"picgoMcp": {
"outputFormat": "${url}"
}
}
}支持的变量：
${url}：上传后的图片 URL。
${uploadedName}：上传后的文件名，不含扩展名。
常用格式：
${url}
工具响应包含 images 图片信息和按模板生成的 formattedOutput。图片链接从 images[].url 获取；需要 Markdown 时，将输出模板设置为 。
响应字段已精简：原先读取 urls 或 markdown 的调用方，应分别改为读取 images[].url 或配置 Markdown 模板后读取 formattedOutput。
upload_image上传一张本地或远程图片：
{
"source": "/path/to/image.png"
}upload_images批量上传 1–20 张图片：
{
"sources": [
"/path/to/first.png",
"https://example.com/second.jpg"
]
}get_picgo_status返回配置是否存在、PicGo 版本、当前上传器、已配置字段名和可用上传器。该工具不会返回配置值或图床凭据。
{
"images": [
{
"url": "https://cdn.example.com/images/2026-08-23-17-34-47-example.png",
"fileName": "2026-08-23-17-34-47-example.png",
"width": 800,
"height": 600,
"size": 123456
}
],
"formattedOutput": "https://cdn.example.com/images/2026-08-23-17-34-47-example.png"
}MCP 客户端通常会启动一个 picgo-mcp stdio 进程，并在当前客户端会话期间复用它。只有调用上传工具时才会读取图片并访问图片来源和图床服务；客户端关闭连接后，server 进程退出并释放内存。
PicGo 会在实例上保存可变的输入和输出状态，因此本项目会将并发上传请求串行执行。
不要在命令参数中传递 token，凭据应由 PicGo 配置管理。
MCP 工具不会返回图床凭据；状态工具只返回字段名。
主目录路径在工具响应中会被替换为 ~。
HTTP(S) 图片会先由 PicGo 下载，再上传到已配置图床。
PicGo 会按配置加载插件，只安装并启用可信插件。
不要把 stdio server 暴露给不可信客户端。
PicGo 3.0.1 的依赖树目前仍包含 image-size 和旧版 inquirer/tmp 的 npm 安全公告。前者处理特制图片时可能造成进程拒绝服务，后者位于本项目不调用的 PicGo CLI 交互路径。这些依赖需要由 PicGo 上游升级。
npm install
npm run build
npm test
npm run check当前测试覆盖配置发现、MCP 工具注册、状态脱敏、上传输入校验、命名模板、输出模板和发布文件隐私检查。
Show the selected config path, PicGo version, active uploader, configured field names, and available uploaders. Secret values are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context by explicitly noting that secret values are never returned, which informs the agent about a meaningful privacy guarantee beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the primary output items, and ends with an important caveat about secrets. Every part contributes value with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only status tool with rich annotations and no output schema, the description fully covers what an agent needs to understand its behavior and call it correctly. No missing information is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema already fully communicates invocation requirements. The description has nothing to add about parameter semantics, and the baseline of 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Show' and names a concrete set of outputs (config path, version, active uploader, field names, available uploaders). It clearly distinguishes this inspection tool from the sibling upload tools by framing it as read-only status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for inspecting current PicGo configuration state rather than performing uploads. It does not explicitly state 'use this before uploading' or name alternatives, but the read-only nature and content list make the intended context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one local image file or HTTP(S) image URL using the active PicGo uploader.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Local file path, file:// URL, or HTTP(S) image URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=false, which the description does not contradict. The description offers one extra context point: it depends on the 'active' PicGo uploader, implying configuration prerequisites. It does not explain side effects, failures, or response behavior, but the annotation coverage reduces the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, direct sentence captures the entire behavior with the key constraint 'one' placed up front. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one well-documented parameter and annotations cover mutability, idempotency, and safety, the description is nearly complete for a simple upload call. It could optionally mention what happens upon success or failure, but that is likely redundant for such a niche tool. The 'active PicGo uploader' hints at a real precondition that could be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since the single parameter 'source' is fully documented as a local file path, file:// URL, or HTTP(S) image URL. The description mostly echoes the same semantics without adding format validations, constraints, or examples. Essentially the full burden is handled by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Upload one local image file or HTTP(S) image URL using the active PicGo uploader.' The word 'one' clearly distinguishes it from the plural sibling tool upload_images. The title reinforces purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The singular 'one' implicitly contrasts with the plural upload_images sibling, giving a subtle cue. However, the description never explicitly states when to use this tool vs upload_images or get_picgo_status, nor any exclusion conditions. Guidance is implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload up to 20 local image files or HTTP(S) image URLs in one PicGo batch.
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes | Local file paths, file:// URLs, or HTTP(S) image URLs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=false, and destructive=false. The description adds that the operation is a batched upload accepting files or URLs, but it does not disclose side effects such as duplicate uploads on repeated calls or how partial failures are handled. This is modest added context beyond annotations, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence captures the action, accepted inputs, count limit, and batching model. It is front-loaded and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the definition is sufficient to understand what to pass and why this tool is relevant. The only meaningful gaps are the absence of an explicit mention of the singular sibling and no description of return values or error behavior, but these are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description mostly restates the schema's own information: local paths, file:// URLs, HTTP(S) URLs, and the 20-item limit. It confirms the parameter's meaning but does not add meaningful detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action verb and resource: uploading local image files or HTTP(S) image URLs. It also specifies the batch boundary of up to 20, which clearly differentiates this tool from the singular sibling upload_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one PicGo batch' plus 'up to 20' clearly establishes this is the tool for multiple-image uploads. It does not explicitly name upload_image for the single-image case or explain when to use get_picgo_status, but the usage context is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_picgo_statusupload_imageupload_imagesScored across 3 tools
upload_image and upload_images are clearly differentiated as singular vs. batch operations, and get_picgo_status serves a distinct diagnostic purpose. No tools overlap in a way that would cause selection confusion.
All tool names follow the same snake_case verb_noun pattern: upload_image, upload_images, get_picgo_status. The naming is predictable and consistent across the set.
Three tools is on the smaller side but well-suited for a focused image-upload server. Each tool provides a distinct needed capability: single upload, batch upload, and status/configuration inspection.
The server covers the core upload lifecycle well, including single and batch uploads plus status/uploader information. A minor gap is the lack of an explicit uploader-selection or configuration tool, but the active uploader is readable via status, so agents can work around it.
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
Convert images to PNG, JPEG, WebP, or AVIF through one public remote MCP tool.
Image processing over MCP: compress and split images, generate images and QR codes.
MCP server for Qwen Image 3 AI image generation