빠른 시작: 다음 프롬프트를 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 picgoMCP 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}"
}
}
}지원 변수:
변수 | 예시 | 설명 |
|
| 로컬 날짜 |
|
| 초 단위 로컬 시간 |
|
| 확장자를 제외한 원본 파일명 |
|
| 원본 확장자 |
|
| 일괄 업로드 시 0부터 시작하는 순번; 단일 업로드 시 비어 있음 |
권장 설정:
${dateTime}-${fileName}${extName}${dateTime}${extName}만 사용하면 같은 초에 업로드된 이미지의 파일명이 중복될 수 있습니다. 템플릿은 화이트리스트의 자리 표시자만 치환하고 JavaScript는 실행되지 않으며, 파일명을 통해 ../와 같은 추가 경로를 쓸 수 없습니다. 원격 디렉터리는 업로더의 path 구성을 사용해야 합니다.
설치 위치:
{
"settings": {
"picgoMcp": {
"outputFormat": "${url}"
}
}
}지원 변수:
${url}: 업로드 completed 후 이미지 URL.
${uploadedName}: `.확장자를 제외한 업로드된 파일명.
일반 형식:
${url}
도구 응답에는 항상 이미지 정보, URL 배열, Markdown 및 템플릿으로 생성된 formattedOutput이 포함되므로 호출자는 필요에 따라 필드를 선택할 수 있습니다.
upload_image로컬 또는 원격 이미지 하나를 업로드합니다:
{
"source": "/path/to/image.png"
}upload_images1–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
}
],
"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"
}MCP 클라이언트는 일반적으로 picgo-mcp stdio 프로세스를 시작하고 현재 클라이언트 세션 동안 이를 재사용합니다. 업로드 도구를 호출할 때만 이미지를 읽고 이미지의 소스 및 호스트 서비스에 접근합니다. 클라이언트가 연결을 닫으면 server 프로세스는 종료되고 메모리를 해제합니다.
PicGo는 인스턴스에 가변 입력/출력 상태를 저장하므로, 이 프로젝트는 동시 업로드 요청을 직렬로 실행합니다.
명령 인수에 token을 전달하지 마세요. 자격 증명은 PicGo 구성으로 관리해야 합니다.
MCP 도구는 호스트 자격 증명을 반환하지 않습니다. 상태 도구는 필드 이름만 반환합니다.
홈 디렉터리 경로는 도구 응답에서 ~로 대체됩니다.
HTTP(S) 이미지는 PicGo가 먼저 다운로드한 후 구성된 호스트에 업로드됩니다.
PicGo는 구성에 따라 plugin을 로드합니다. 신뢰할 수 있는 plugin만 설치하고 활성화하세요.
stdio server를 신뢰할 수 없는 클라이언트에 노출하지 마세요.
PicGo 3.0.1의 의존성 트리에는 현재 image-size와 이전 버전 inquirer/tmp의 npm 보안 공지가 포함됩니다. 전자는 특수하게 제작된 이미지를 처리할 때 프로세스 서비스 거부를 유발할 수 있습니다. 후자는 이 프로젝트가 호출하지 않는 PicGo CLI의 상호작용 경로에 있습니다. 이러한 의존성은 PicGo 업스트림이 업그레이드해야 합니다.
npm install
npm test
npm run check
npm run build현재 테스트는 구성 발견, 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