クイックスタート： 以下のプロンプトをコーディングエージェントに送信してください：
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}"
}
}
}サポートされる変数：
変数 | 例 | 説明 |
|
| ローカル日付 |
|
| 秒単位のローカル日時 |
|
| 拡張子を含まない元のファイル名 |
|
| 元の拡張子 |
|
| 一括アップロード時のゼロ始まりのインデックス。単一画像アップロード時は空 |
推奨設定：
${dateTime}-${fileName}${extName}${dateTime}${extName} のみを使用すると、同一秒内にアップロードされた画像で名前が衝突する可能性があります。テンプレートはホワイトリストに登録されたプレースホルダーの置換のみを実行し、JavaScript は実行しません。また、ファイル名を通じて ../ などの追加パスを書き込むことはできません。リモートディレクトリはアップローダーの path 設定を使用してください。
設定場所：
{
"settings": {
"picgoMcp": {
"outputFormat": "${url}"
}
}
}サポートされる変数：
${url}：アップロード後の画像 URL。
${uploadedName}：拡張子を含まないアップロード後のファイル名。
一般的な形式：
${url}
ツールのレスポンスには常に画像情報、URL 配列、Markdown、テンプレートから生成された formattedOutput が含まれるため、呼び出し側は必要に応じてフィールドを選択できます。
upload_imageローカルまたはリモートの画像を1枚アップロードします：
{
"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 は設定に応じてプラグインを読み込みます。信頼できるプラグインのみをインストールして有効化してください。
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