バージョン: 1.0.0
AIが見たものを語る。 生成型画像ディスクライバー — Florence-2 (MIT) をラップする MCP サーバー + CLI。散文による説明、OCR、LoRA データセット用キャプションサイドカーを提供する。ローカルで動作し、デフォルトで決定論的。
ai-eyes-mcp の兄弟ツールです:
ai-eyes-mcp | plain-sight | |
役割 | 画像を判定する | 画像を説明する |
モデル | SigLIP2 (識別型) | Florence-2 (生成型) |
出力 | 較正されたスコア | 散文 / OCR / キャプションファイル |
失敗モード | 説明できない | 詳細を幻覚することがある |
使うべき場面 | 「この画像にXは含まれるか?」 | 「この画像には何が写っているか?」 |
説明は生成的です。流暢で、通常は正確で、詳細を捏造し得ます。plain-sight は出力を再現可能にします（決定論的デコード——同じ画像は同じキャプションを生成する）が、真実であることを保証するものではありません。画像に関する特定の主張を検証するには、ai-eyes-mcp の image_verify を使ってください。これは測定するものであり、語るものではありません。この2つのツールは設計上異なるモデルファミリーなので、互いに検証し合うことができます。
Related MCP server: fm-mcp-comfyui-bridge
ツール | 機能 |
| 1枚の画像 → 散文による説明（3段階の詳細度） |
| N枚の画像 → |
| OCR — 画像から可視テキストを抽出する |
| ヘルスチェック: モデル、デバイス、ロード状態 |
| 同梱の参照画像を説明し、出力の健全性を確認する |
pip install -e .
plain-sight-mcp # starts the STDIO MCP serverまたはモジュールとして実行: python -m plain_sight
# One image, full paragraph
plain-sight describe hero.png
# One short sentence
plain-sight describe hero.png --detail low
# OCR
plain-sight ocr screenshot.png
# The dataset lane: caption a directory into .txt sidecars with a trigger token
plain-sight batch ./dataset --prefix "mcpt_style, " --detail high
# Re-runs are idempotent — existing sidecars are skipped unless you --overwrite
plain-sight batch ./dataset --prefix "mcpt_style, " --overwrite{
"mcpServers": {
"plain-sight": {
"command": "plain-sight-mcp",
"env": {
"PLAIN_SIGHT_MODEL_DIR": "/path/to/model/cache"
}
}
}
}LoRA トレーニングセット（style-dataset-lab など）向けに設計されています:
正確なベースネームのペアリング: img_0042.png → img_0042.txt。カウンター
サフィックスなし——ComfyUI の SaveText ノード（_00001 を追加する）とは異なります。
そのままの連結: サイドカーには prefix + caption + suffix が
区切り文字を挿入されずに含まれます。"mcpt_style, <caption>" にしたい場合は、
カンマ+スペースをプレフィックスに入れてください。
冪等な再実行: 既存のサイドカーはスキップされます（コストもかかりません）。
--overwrite / overwrite=true を指定した場合のみ上書きされます。
決定論的: do_sample=false + ビームサーチ——変更されていない画像を
再キャプションすると同じテキストが再現されるため、差分に意味があります。
Florence-2 のネイティブなタスクラダー:
段階 | タストークン | 出力 |
|
| 短い文1つ |
|
| 数文 |
|
| 完全な段落 |
high は段落であって、エッセイではありません——Florence-2 はコンパクトな (0.77B) モデルです。
その強みはスループットとライセンスであり、美術評論の深さではありません。キャプションが
途中で切れているように見える場合は、max_new_tokens（デフォルト 1024、最大 4096）を上げてください。
環境変数 | デフォルト | 目的 |
|
| HuggingFace モデル |
| HF デフォルトキャッシュ | モデルキャッシュディレクトリ |
|
| torch デバイス |
| CUDA では |
|
|
| デフォルトの生成上限 |
|
| ビーム幅（決定論的デコード） |
|
|
|
| 未設定 | 真値ならサーバー起動時にモデルをロード |
ログ: stderr のみ（stdout は MCP プロトコルチャネル）、ロガー名は
plain_sight。
初回呼び出し: モデルは遅延ロードされます——最初の describe/OCR 呼び出しで
Florence-2 をロードします（GPU で約10〜20秒; 初回の呼び出しでは約1.5 GBをダウンロード）。
以降の呼び出しは、最新の GPU で high 詳細度の場合、画像1枚あたり約1〜2秒です。
このツール: MIT。
モデル: florence-community/Florence-2-large に固定——Microsoft の Florence-2 リリースの
公式ネイティブ transformers 変換版です。MIT（ハブのライセンスタグは 2026-08-19 に確認済み）。
商用利用も問題ありません。
microsoft/Florence-2-large を使わない理由: 同じ重み、同じ MIT ライセンスですが、
元のリポジトリにはネイティブ以前の設定が同梱されており、trust_remote_code 経由でしか
ロードできません——このツールはその方式を原則として拒否します。コミュニティ変換版は
transformers の組み込み Florence-2 クラスでロードできます。
意図的に提供しないもの: Florence-2 のファインチューン群（MiaoshouAI
PromptGen、CogFlorence、SD3/Flux キャプショナー、Castollux）。これらのライセンスは
未検証であり、確認が取れるまで対象外です。PLAIN_SIGHT_MODEL_ID をそれらのいずれかに
上書きすることは可能ですが、ライセンスの責任はあなたにあります。
リモートコードなし: エンジンは transformers のネイティブ Florence-2
サポートのみを使用します——trust_remote_code は決して渡されないため、ハブから取得した
Python が実行されることはありません。これには transformers >= 4.51 が必要です。
このツールはローカルのみで動作します。
触れるデータ: ローカル画像ファイル（読み取り専用）; HuggingFace モデルキャッシュ
（初回ダウンロード時に一度だけ書き込み）; .txt キャプションサイドカー——書き込むのは
これだけであり、呼び出し元が指定した場所（out_dir または画像の隣）にのみ書き込み、
既存のサイドカーは明示的な --overwrite でのみ置き換えられます。
実行時のネットワーク送信なし——モデルは初回使用時に一度だけダウンロードされ、 以降の推論はすべてローカルです。
リモートコード実行なし——ネイティブ transformers クラスのみ;
trust_remote_code は決して渡されないため、ハブから取得した Python が実行されることはありません。
シークレット処理なし、テレメトリなし——どこからも読み取らず、どこにも送信しません。
構造化エラーのみ——生のスタックトレースが MCP クライアントや CLI ユーザーに 届くことはありません。CLI 終了コード: 0 正常 · 1 ユーザーエラー · 2 ランタイムエラー · 3 部分成功。
完全なポリシー: SECURITY.md。積極的にメンテナンスされており、 サポート対象バージョンはそこに記載されています。
Python >= 3.10
transformers >= 4.51（ネイティブ Florence-2）
CUDA GPU 推奨（FP16 で約2GB VRAM）; CPU フォールバックも動作します（遅い）
初回使用時にモデルを約1.5GBダウンロード
# Install in editable mode with dev dependencies
pip install -e ".[dev]"
# CI-safe tests (no model, no GPU)
pytest tests/test_edge_cases.py -v
# Dogfood tests (real model + GPU)
pytest tests/test_dogfood.py -v
# Full verify: imports, edge tests, build
bash verify.shengine.py Standalone Florence-2 wrapper — no MCP dependency.
Lazy-loads the model; validation runs BEFORE the load.
Importable directly: from plain_sight.engine import Florence2Engine
sidecars.py The training-data contract, pure stdlib: basename pairing,
bare concatenation, directory expansion. Testable without torch.
server.py FastMCP wrapper exposing engine methods as MCP tools.
Thin layer: validation, error shaping, tool metadata.
cli.py argparse CLI over the same engine (describe / ocr / batch /
status / selftest). Structured errors, meaningful exit codes.アーキテクチャは意図的に
ai-eyes-mcp から借用しています——同じ
エンジン/サーバー分割、同じエラー整形、同じセルフテストパターン。同じ契約のクラウド版は
Comfy Cloud で caption-florence2-v1 ワークフローとして動作しています（ジョブごとに
1枚の画像というメタデータライダー; このツールはバルクレーンです）。
MIT
MCP Tool Shop によって構築されました。
Blocks until every image completes -- roughly 1-2 s per image plus ~10-20 s if the model is not yet loaded. Chunk large sets. Existing sidecars are skipped unless overwrite=true, so a retry is cheap.
Caption a batch of images, writing .txt sidecars -- the dataset lane. The training-data contract: EXACT basename pairing (img_0042.png -> img_0042.txt, no counter suffix) and BARE prefix+caption+suffix concatenation (no delimiter injected).
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Detail tier: 'low' | 'medium' | 'high' (default) | high |
| prefix | No | Text prepended to every caption, bare concatenation — include your own separator (e.g. 'mcpt_style, ') | |
| suffix | No | Text appended to every caption, bare concatenation | |
| out_dir | No | Directory for sidecar files (created if missing). Default: next to each image | |
| overwrite | No | Re-caption images whose sidecar already exists (default false: skip them, so re-runs are idempotent and cheap) | |
| image_paths | Yes | List of absolute image file paths (max 100) | |
| manifest_path | No | Optional explicit JSON provenance path. Default none — no manifest is written. Refused if it collides with a sidecar. | |
| max_new_tokens | No | Generation length cap (default 1024, max 4096) | |
| write_sidecars | No | Write each caption to <image-stem>.txt (exact basename pairing). When false, captions are returned in the response instead |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and does so well: it discloses blocking behavior, per-image latency (~1-2 s plus ~10-20 s model load), idempotency via sidecar skipping, and the exact sidecar/manifest naming contract. These are behavioral traits an agent cannot infer from the schema.
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?
Two tight paragraphs, no filler, every clause earns its place. The purpose sentence is slightly buried behind the latency note, so the front-loading is not ideal, but nothing is wasted.
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?
An output schema exists so return values need not be explained, and the description still covers latency, idempotency, and the sidecar contract for a 9-parameter tool. The main omission is routing guidance versus describe_image and any failure/error behavior.
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%, so the parameters (prefix/suffix bare concatenation, overwrite skip semantics, manifest collision refusal) are already fully documented in the schema. Baseline 3 applies because the description largely restates those semantics rather than adding new parameter meaning.
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?
States a specific verb+resource ('Caption a batch of images, writing .txt sidecars') and the 'dataset lane' scope, which separates it from the singular describe_image sibling. It never names describe_image explicitly, so the differentiation rests on the word 'batch' rather than a direct contrast.
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?
Gives operational guidance ('Chunk large sets', retries are cheap because existing sidecars are skipped), which implies when this tool is appropriate. It does not, however, state when to prefer describe_image or describe_batch, nor any preconditions beyond chunking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe an image in prose — an AI says what it sees.
Uses Florence-2 (MIT-licensed, runs locally) with deterministic decoding: the same image at the same tier reproduces the same description.
Descriptions are generative and can hallucinate detail — for verifying a specific claim about the image, prefer ai-eyes-mcp's image_verify.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Detail tier: 'low' (one sentence), 'medium' (a few sentences), 'high' (full paragraph — default) | high |
| image_path | Yes | Absolute path to the image file | |
| max_new_tokens | No | Generation length cap (default 1024, max 4096) — raise if a high-detail caption looks truncated |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses local execution, licensing, deterministic decoding with reproducibility guarantees, and the hallucination risk inherent to generative captioning. It also explains the max_new_tokens escape hatch for truncated output — behavioral context no structured field provides.
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?
Front-loads the purpose, then behavior, then the routing caveat in three tight paragraphs. The opening clause 'an AI says what it sees' is mildly redundant with the name but the rest earns its place with zero 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?
Output schema exists, so return values need no explanation, and the tool is a single-shot read. The description covers execution model, reproducibility, failure mode, and the alternative tool — nothing an agent needs to call it correctly is 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%, so the schema already documents detail tiers, image_path, and max_new_tokens semantics. The description only echoes the tier concept ('same image at the same tier') without adding syntax or format detail. 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?
States a specific verb and resource ('Describe an image in prose') and names the underlying mechanism (Florence-2, local, deterministic). It implicitly contrasts with read_text (OCR) and explicitly with image_verify, so an agent can distinguish it from siblings.
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?
Explicitly names when NOT to use it ('for verifying a specific claim about the image, prefer ai-eyes-mcp's image_verify') and explains the tier behavior that selects output depth. This is the when/when-not/alternative pattern at full strength.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract visible text from an image (Florence-2 task).
Returns the text the model reads off the pixels — signage, UI labels, documents. Like all generative output it can misread; treat low-stakes.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | Absolute path to the image file | |
| max_new_tokens | No | Generation length cap (default 1024, max 4096) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does real work: it discloses that output is generative, may misread, and is low-stakes. This is genuine behavioral context about reliability. It stops short of covering determinism, retry behavior, or failure modes.
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?
Three short lines with the core action front-loaded. The model-task parenthetical and misread caveat are compact. Slightly fragmentary but nothing wasteful.
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?
Output schema exists, so return shape need not be explained, and annotations are absent. The description covers purpose, examples, and the key reliability caveat for a 2-param generative tool. Adequate without being exhaustive.
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%, so both parameters (image_path, max_new_tokens) are already documented with defaults and limits. The description adds no parameter detail beyond the schema, so 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?
States a specific verb (extract) and resource (visible text from an image), and names the underlying model task (Florence-2 <OCR>). An agent can distinguish this from describe_image's broader captioning role by the scoped 'visible text' target.
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?
Implies usage through examples (signage, UI labels, documents) but never explicitly states when to choose this over describe_image or describe_batch. No exclusions or routing guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Self-test: describe the bundled reference images and confirm the outputs are sane (non-trivial, on-subject, tier ordering holds) — proves the install loaded correctly. Loads the model if it isn't already.
Returns {passed, checks: [{name, expected, measured, ok}], model_id, device, torch_version, transformers_version}.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the side effect ('Loads the model if it isn't already') and enumerates the returned check structure. It does not mention cost, duration, or failure modes when checks fail, keeping it short of full transparency.
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?
Front-loaded with the action and the rationale, and every sentence adds information about scope, side effects, or output. The trailing return-value sentence slightly duplicates the existing output schema, which is the only waste.
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 diagnostic with an output schema, the description covers what it does, why it exists, and the model-loading side effect. It could be more complete by stating what a failed test implies or recommending a follow-up action, but nothing essential is 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?
The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate.
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 — run a self-test that describes bundled reference images and validates the outputs — and clarifies the goal ('proves the install loaded correctly'). It is clearly distinguishable from describe_image/describe_batch, though it never names those siblings directly.
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?
Usage is implied by 'proves the install loaded correctly', which suggests running it as a post-install verification, and it notes the side effect of loading the model. However, it does not tell the agent when to prefer this over the sibling sight_status or when not to run it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check plain-sight server status.
Returns model info, device, and whether the model is currently loaded. The model loads lazily on first tool call — this tool does NOT trigger loading.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a genuinely useful behavior: the model loads lazily and this call deliberately avoids triggering that load. That is a real side-effect disclosure an agent needs. It stops short of stating whether the call has any other cost or failure modes.
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?
Three short sentences, front-loaded with the purpose and followed by return contents and the key caveat. No filler, every sentence carries information.
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?
An output schema exists, so the description needn't restate return values, and the one non-obvious behavior (lazy loading, no load triggered) is covered. It could have pointed to sight_selftest as the follow-up, but nothing essential for correct invocation is 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?
The tool takes zero parameters, so there is nothing to document; baseline for a no-parameter tool is 4. The description correctly adds no parameter noise.
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?
States a specific verb and resource ('Check plain-sight server status') and enumerates what comes back (model info, device, load state). It distinguishes itself from the describe/read siblings by being a diagnostic call, though it doesn't explicitly contrast with sight_selftest.
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 note that the tool does NOT trigger loading implicitly tells the agent when to prefer it (a non-invasive status check), but there is no explicit when-to-use statement nor a routing hint toward sight_selftest for deeper diagnostics. Usage is implied rather than stated.
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.
v1.1.0describe_batchdescribe_imageread_textsight_selftestsight_statusScored across 5 tools
Tools have distinct purposes: single image description, batch captioning with sidecars, OCR, status check, and self-test. The only mild overlap is between describe_image and describe_batch, but the sidecar/dataset contract and blocking behavior make them clearly separable.
Three tools follow verb_noun (describe_image, describe_batch, read_text) while two follow noun_noun with a sight_ prefix (sight_status, sight_selftest). The split is readable but not a single consistent pattern.
Five tools is well within the ideal range for a focused image description/OCR server; each tool has a clear role and none feels redundant.
Core workflows are covered: single and batch description, OCR, status, and self-test. Minor gaps exist, such as no explicit tier selection tool or a way to get batch captions without writing sidecars, but these are workable.
MCP server for Qwen Image 3 AI image generation
MCP server for Flux AI image generation
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
MCP server for Grok Imagine AI video generation