Inicio rápido: envía el siguiente prompt a tu agente de programación:
请从 https://github.com/timerring/PicGo-MCP 安装并配置 PicGo MCP Server。
Un servidor MCP stdio que integra PicGo Core directamente en el proceso. Permite a clientes MCP como Codex, Claude Desktop, etc., reutilizar las configuraciones de alojamiento de imágenes existentes de PicGo; no requiere que la aplicación de escritorio de PicGo esté en ejecución y no pasa por 127.0.0.1:36677.
Llama directamente a PicGo Core 3, sin dependencia de la aplicación de escritorio.
Admite archivos locales, URL file:// y URL de imágenes HTTP(S).
Admite la subida de una sola imagen y la subida en lote de hasta 20 imágenes.
Detecta automáticamente las configuraciones de PicGo Desktop, PicGo Core y CLI.
Admite personalizar el nombre de archivo de subida y el formato de retorno.
Las llamadas concurrentes se encolan automáticamente para evitar que el estado de subida mutable de PicGo se contamine entre sí.
Las herramientas de estado no devuelven valores de configuración como tokens o secretos, y muestran el directorio principal del usuario como ~.
Related MCP server: flin-imgbb-mcp
Node.js >=20.19.0
Un archivo de configuración de PicGo funcional
Instalar desde el código fuente:
npm install
npm run build
npm install -g .Confirmar que el comando está disponible:
picgo-mcp --helpcodex mcp add picgo -- picgo-mcp
codex mcp get picgoDespués de agregar el servidor MCP, crea una nueva tarea o actualiza el cliente para que la lista de herramientas se recargue.
Después de la instalación global, se puede usar la siguiente configuración stdio:
{
"mcpServers": {
"picgo": {
"command": "picgo-mcp"
}
}
}Cuando se necesita especificar explícitamente el archivo de configuración:
{
"mcpServers": {
"picgo": {
"command": "picgo-mcp",
"args": ["--config", "/path/to/picgo/config.json"]
}
}
}También se puede definir la variable de entorno PICGO_CONFIG_PATH. La opción --config tiene prioridad sobre la variable de entorno y sobre la detección automática.
Por defecto se busca en el siguiente orden:
macOS: ~/Library/Application Support/picgo/data.json
Windows: %APPDATA%/picgo/data.json
Linux: $XDG_CONFIG_HOME/picgo/data.json o ~/.config/picgo/data.json
Todos los sistemas: ~/.picgo/config.json
El siguiente ejemplo sube las imágenes al directorio images/ del repositorio y devuelve la dirección CDN a través de jsDelivr:
{
"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}"
}
}
}El token de GitHub necesita permiso de escritura en el repositorio de destino. No envíes tokens reales a Git, Issues, registros o conversaciones de chat, y restringe los permisos del archivo de configuración para que el usuario actual pueda leerlo:
chmod 600 ~/.picgo/config.jsonPicGo Core 3 puede agregar la configuración uploader y metadatos internos al leer por primera vez una configuración antigua; esto es un comportamiento de migración automática normal.
Ubicación de configuración:
{
"settings": {
"picgoMcp": {
"uploadNameTemplate": "${dateTime}-${fileName}${extName}"
}
}
}Variables admitidas:
Variable | Ejemplo | Descripción |
|
| Fecha local |
|
| Hora local con precisión de segundos |
|
| Nombre de archivo original, sin extensión |
|
| Extensión original |
|
| Índice de base cero para subidas en lote; vacío para subida de una sola imagen |
Uso recomendado:
${dateTime}-${fileName}${extName}Si se usa solo ${dateTime}${extName}, las imágenes subidas en el mismo segundo pueden provocar conflictos de nombre. La plantilla solo realiza el reemplazo de marcadores de posición de la lista blanca, no ejecuta JavaScript y no permite escribir rutas adicionales como ../ mediante el nombre de archivo; el directorio remoto debe configurarse con la opción path del subidor.
Ubicación de configuración:
{
"settings": {
"picgoMcp": {
"outputFormat": "${url}"
}
}
}Variables admitidas:
${url}: la URL de la imagen después de la subida.
${uploadedName}: el nombre del archivo después de la subida, sin extensión.
Formato común:
${url}
La respuesta de la herramienta siempre incluye información de la imagen, un arreglo de URL, el formato Markdown y formattedOutput generado según la plantilla, por lo que la parte que invoca puede seleccionar los campos según lo que necesite.
upload_imageSube una imagen local o remota:
{
"source": "/path/to/image.png"
}upload_imagesSube de 1 a 20 imágenes en lote:
{
"sources": [
"/path/to/first.png",
"https://example.com/second.jpg"
]
}get_picgo_statusDevuelve si existe la configuración, la versión de PicGo, el subidor actual, los nombres de campos configurados y los subidores disponibles. Esta herramienta no devuelve valores de configuración ni credenciales de la base de imágenes.
{
"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
}
],
"urls": [
"https://cdn.example.com/images/2026-08-23-17-34-47-example.png"
],
"markdown": "",
"formattedOutput": "https://cdn.example.com/images/2026-08-23-17-34-47-example.png"
}Los clientes MCP suelen iniciar un proceso stdio de picgo-mcp y reutilizarlo durante toda la sesión del cliente. La imagen se lee y se tiene un servidor de la imagen o el alojamiento únicamente cuando se llama a la herramienta de subida. Cuando el cliente cierra la conexión, el proceso del servidor finaliza y libera memoria.
PicGo guarda estado de entrada y salida mutable en la instancia, por lo que este proyecto serializa las solicitudes de subida concurrentes.
No pases tokens en los parámetros de la línea de comandos: los credenciales deben gestionarlos la configuración de PicGo.
Las herramientas MCP no devuelven credenciales del alojamiento de imágenes; la herramienta de estado solo devuelve nombres de campos.
En las respuestas de las herramientas de subida, la ruta del directorio principal se reemplaza por ~.
Las imágenes HTTP de tipo HTTP se descargan primero con PicGo y luego se suben al alojamiento configurado.
PicGo carga los plugins según la configuración; instala y usa únicamente las plug-ins de confianza.
No expongas el servidor stdio a clientes no confiables.
El árbol de dependencias de PicGo 3.0.1 aún incluye avisos de seguridad de npm para image-size y las otras versiones anteriores de inquirer/tmp. El primero puede causar una denegación de servicio del proceso al procesar imágenes especialmente diseñadas; el segundo se encuentra en la ruta de interacción del CLI de PicGo, que este proyecto no utiliza esa. Estas dependencias deben actualizarse por el upstream de PicGo.
npm install
npm test
npm run check
npm run buildLas pruebas actúales cubren detección de configuración, registro de herramientas MCP, ofuscación de estado, validación de entrada de subida, plantillas de nombres, plantillas de salida y comprobación de privacidad de los archivos de publicación.
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