Версия: 1.0.0
ИИ описывает то, что видит. Генеративный описатель изображений — MCP-сервер + CLI-обёртка вокруг Florence-2 (MIT) для прозаических описаний, OCR и sidecar-файлов подписей для LoRA-датасетов. Работает локально, детерминирован по умолчанию.
Родственный инструмент для ai-eyes-mcp:
ai-eyes-mcp | plain-sight | |
Задача | оценивает изображения | описывает изображения |
Модель | SigLIP2 (дискриминативная) | Florence-2 (генеративная) |
Выход | калиброванные оценки | проза / OCR / файлы подписей |
Режим отказа | не умеет рассказывать | может выдумывать детали |
Когда применять | «содержит ли изображение X?» | «что на этом изображении?» |
Описания генеративны: беглые, обычно точные и способны выдумывать
детали. plain-sight делает вывод воспроизводимым (детерминированное декодирование — одно
и то же изображение даёт одну и ту же подпись), но не гарантированно истинным. Для проверки
конкретного утверждения об изображении используйте image_verify из ai-eyes-mcp — он измеряет,
а не рассказывает. Эти два инструмента относятся к разным семействам моделей по замыслу, поэтому
один может проверять другой.
Related MCP server: fm-mcp-comfyui-bridge
Инструмент | Что делает |
| Одно изображение → прозаическое описание (3 уровня детализации) |
| N изображений → sidecar-файлы подписей |
| 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. Без
числового суффикса — в отличие от узла SaveText в ComfyUI, который добавляет _00001.
Простая конкатенация: sidecar-файл содержит prefix + caption + suffix
без вставленного разделителя. Хотите "mcpt_style, <подпись>"? Поместите
запятую с пробелом в префикс.
Идемпотентные повторные запуски: существующие sidecar-файлы пропускаются (и ничего не стоят),
если не указан --overwrite / overwrite=true.
Детерминированность: do_sample=false + лучевой поиск — повторное создание подписи
для неизменённого изображения воспроизводит тот же текст, поэтому различия имеют смысл.
Собственная лестница задач Florence-2:
Уровень | Токен задачи | Вывод |
|
| одно короткое предложение |
|
| несколько предложений |
|
| полный абзац |
high — это абзац, а не эссе — Florence-2 — компактная модель (0,77B).
Её преимущество — пропускная способность и лицензия, а не глубина художественной критики.
Если подпись выглядит обрезанной, увеличьте max_new_tokens (по умолчанию 1024, максимум 4096).
Переменная окружения | По умолчанию | Назначение |
|
| Модель HuggingFace |
| Кэш HuggingFace по умолчанию | Каталог кэша модели |
|
| Устройство torch |
|
|
|
|
| Лимит генерации по умолчанию |
|
| Ширина луча (детерминированное декодирование) |
|
|
|
| не задано | Если истинно, загрузить модель при запуске сервера |
Логирование: только stderr (stdout — канал протокола MCP), имя логгера
plain_sight.
Первый вызов: модель загружается лениво — первый вызов describe/OCR загружает
Florence-2 (~10–20 с на GPU; первый вызов вообще скачивает ~1,5 ГБ). Последующие
вызовы — ~1–2 с на изображение при детализации high на современном GPU.
Этот инструмент: MIT.
Модель: закреплена за florence-community/Florence-2-large —
официальная конверсия native-transformers релиза Microsoft Florence-2.
MIT (тег лицензии на хабе проверен 2026-08-19). Коммерческое использование чистое.
Почему не microsoft/Florence-2-large? Те же веса, та же лицензия MIT,
но оригинальные репозитории поставляются с конфигами pre-native, которые загружаются только
через trust_remote_code — а этот инструмент отказывается от этого по принципиальным соображениям.
Конвертация сообщества загружается встроенными классами Florence-2 из transformers.
Сознательно не предлагается: зоопарк дообученных версий Florence-2 (MiaoshouAI
PromptGen, CogFlorence, SD3/Flux captioners, Castollux). Их лицензии
не проверены; они не включаются, пока не будут подтверждены. Переопределение
PLAIN_SIGHT_MODEL_ID на одну из них возможно, но вопрос лицензии ложится на вас.
Без удалённого кода: движок использует только нативную поддержку Florence-2
в transformers — trust_remote_code никогда не передаётся, поэтому никакой Python-код,
полученный с хаба, никогда не выполняется. Для этого требуется transformers >= 4.51.
Этот инструмент работает только локально.
Обрабатываемые данные: локальные файлы изображений (только чтение); кэш моделей HuggingFace
(записывается один раз при первом скачивании); sidecar-файлы подписей .txt — ЕДИНСТВЕННЫЕ файлы,
которые он записывает, и только туда, куда попросил вызывающий (out_dir или рядом с изображением),
а существующие sidecar-файлы заменяются только при явном --overwrite.
Нет исходящего сетевого трафика во время выполнения — модель скачивается один раз при первом использовании, затем весь вывод происходит локально.
Нет выполнения удалённого кода — только нативные классы transformers;
trust_remote_code никогда не передаётся, поэтому никакой Python-код, полученный с хаба,
никогда не выполняется.
Нет обработки секретов, нет телеметрии — ничего не читается и никуда не отправляется.
Только структурированные ошибки — сырые трассировки стека никогда не попадают к MCP-клиентам или пользователям CLI. Коды выхода CLI: 0 — успех · 1 — ошибка пользователя · 2 — ошибка выполнения · 3 — частичный успех.
Полная политика: SECURITY.md. Активно поддерживается; поддерживаемые версии перечислены там.
Python >= 3.10
transformers >= 4.51 (нативная поддержка Florence-2)
Рекомендуется GPU CUDA (~2 ГБ VRAM при FP16); запасной вариант на CPU работает (медленнее)
Модель скачивается ~1,5 ГБ при первом использовании
# 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 — то же
разделение движок/сервер, та же форма ошибок, тот же паттерн selftest. Облачный
аналог того же контракта работает на Comfy Cloud как
workflow caption-florence2-v1 (метаданные одного изображения на задачу; этот
инструмент — массовый трек).
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