VisionSieve MCP
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@VisionSieve MCPWhat exception is shown, and where does the stack trace first enter project code?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
VisionSieve MCP
High-signal image evidence for text-first agents.
Keep DeepSeek, OpenCode, Pi, or another text-first agent in charge. When the task depends on pixels, VisionSieve sends one focused image question to Luna and returns a small, checked evidence packet.
About 1/10 the visual text in the host context.
6/6 expected fields versus 4/6 for native attachment in our six-fixture comparison.
vision.inspect(
paths=["./terminal.png"],
query="What exception is shown, and where does the stack trace first enter project code?"
)The default route reuses the local Codex ChatGPT login and pins gpt-5.6-luna. If that route is unavailable, the call fails. It does not silently switch models or move onto an API-billed route.
The comparison
The same six synthetic image tasks were sent through native Codex image attachment and VisionSieve on one machine.
Result | Native Codex attachment | VisionSieve |
Tasks completed | 6/6 | 6/6 |
All expected fields present | 4/6 | 6/6 |
Median visual text returned to the host | 602 characters | 62 characters, about 1/10 |
Median end-to-end time | 16.6 s | 20.2 s |
VisionSieve took 3.6 seconds longer at the median and sent about 90% less visual text into the host context. It kept every expected field in this fixture set. This is a small same-machine comparison, not a general accuracy or speed leaderboard. The prompts, outputs, and limits are in comparison.md.
Related MCP server: Image Reader MCP
Install
First install Codex and sign in with ChatGPT:
npm install -g @openai/codex
codexWindows PowerShell:
irm https://raw.githubusercontent.com/scy7796/visionsieve-mcp/main/install.ps1 | iexmacOS or Linux:
curl -fsSL https://raw.githubusercontent.com/scy7796/visionsieve-mcp/main/install.sh | shThe installer downloads the standalone binary for the current platform, verifies its SHA-256 hash, checks the Codex login, registers the visionsieve MCP server, and runs one image probe. Python, pip, and a virtual environment are not required.
Skip the image probe during setup:
curl -fsSL https://raw.githubusercontent.com/scy7796/visionsieve-mcp/main/install.sh | sh -s -- --skip-probe& ([scriptblock]::Create((irm https://raw.githubusercontent.com/scy7796/visionsieve-mcp/main/install.ps1))) -SkipProbeRestart the MCP host after installation.
To avoid piping a remote script into a shell, download the binary and visionsieve-SHA256SUMS.txt from Releases, verify the hash, and run:
./visionsieve setupWhy use a sieve instead of attaching the image directly?
Direct attachment gives the multimodal model the image and usually lets it decide how much visual narration to return. That is convenient for isolated image questions. It is less convenient inside a long coding or research task, where a large OCR dump or broad visual description becomes part of the main agent's context.
VisionSieve keeps the handoff narrow:
main agent keeps the task history
|
| focused image question
v
vision.inspect
|
| approved image bytes only
v
gpt-5.6-luna
|
| checked compact evidence
v
main agent continues the original taskThe host sends one to four approved image paths and a specific question. VisionSieve returns a short answer, image-indexed evidence, relevant text, and uncertainty. Full OCR output and backend traces stay out of the host conversation by default.
Native attachment is still simpler when Codex is already the main agent and the task only involves one image. OCR is usually faster for clean text when layout and visual relationships do not matter.
What happens to an image
VisionSieve authorizes the path and performs a stable file read.
It copies bounded image bytes into a private request directory.
Codex invokes the pinned Luna model in a read-only child process.
The result is checked for model identity, schema compliance, evidence references, and task redirection from text inside the image.
Weak evidence can trigger a bounded crop or tile retry.
Only the compact result is returned to the host.
The backend never receives an arbitrary host path. It receives the private request copy.
File and model controls
The current working directory is the default allow root. VisionSieve rejects credential and configuration directories, symbolic links, Windows junctions and reparse points, UNC and verbatim paths, NTFS alternate data streams, unsupported files, and images outside the configured byte and pixel limits.
The Codex child process runs read-only. Shell access, subagents, hooks, remote plugins, automatic dependency installation, and web search are disabled. ChatGPT mode removes API-key and alternate-endpoint variables from the child environment.
Text inside an image is treated as content to inspect, not as an instruction to the host. These controls reduce the available attack surface, but they are not a complete isolation boundary. Use a separate user account, container, or virtual machine for highly sensitive images.
Tool reference
vision.inspect(
paths: list[str],
query: str,
mode: "auto" | "ui" | "text" | "chart" | "diagram" | "compare" | "general",
rigor: "normal" | "critical" | "cheap"
)paths accepts one to four absolute image paths inside allowed_roots.
query should ask for the fact that must be confirmed from the image. Keep project history and unrelated task context in the host conversation.
normal uses the primary backend and permits evidence-driven crop or tile retries. critical can use an independently configured verifier. cheap stays on the primary route unless another path has been explicitly configured.
Default configuration
backends:
primary:
enabled: true
via: codex_cli
command: codex
model: "gpt-5.6-luna"
auth_mode: chatgpt
min_cli_version: "0.146.0"
reasoning_effort: medium
extra_args: [--ephemeral, --ignore-user-config]
allow_cli_default_model: false
verifier:
enabled: false
fallback:
enabled: false
allowed_roots:
- "{cwd}"
cache:
store_raw: false
store_full_text: false
expose_local_refs: falseSee examples/config.yaml for the complete configuration surface. Remote endpoints, API keys, verifier models, and fallback models require explicit operator configuration.
Commands
visionsieve setup
visionsieve serve
visionsieve healthcheck
visionsieve probeManual registration:
codex mcp add visionsieve -- visionsieve serveRegistration with a specific configuration file:
codex mcp add visionsieve \
--env VISIONSIEVE_CONFIG=/absolute/path/to/config.yaml \
-- visionsieve serveDiagnostics:
visionsieve healthcheck --check-connectivity --json
visionsieve probe --backend primary --json
codex mcp listCache behavior
The default cache stores compact evidence, not raw backend responses, full OCR text, or local cache paths. A cache hit repeats path authorization and image-byte checks, then skips the backend call only when the image, question, and relevant settings are unchanged.
Upgrading from Visual Evidence Gateway 0.5
Version 1.0 changes the public distribution, executable, and MCP registration to VisionSieve:
Python distribution: visionsieve-mcp
CLI: visionsieve
MCP registration: visionsieve
config variable: VISIONSIEVE_CONFIGRunning visionsieve setup removes the old visual-evidence-gateway MCP registration before adding the new one. The old Python import package and old console commands remain available in 1.0 as compatibility aliases; new integrations should use the VisionSieve names.
The v1 default config directory is:
Windows:
%APPDATA%\visionsievemacOS:
~/Library/Application Support/visionsieveLinux:
~/.config/visionsieve
Existing 0.5 configuration can be passed explicitly:
visionsieve setup --config /path/to/old/config.yamlKnown limits
Codex Desktop may need a full restart before it discovers the server.
Windows ARM64 has no prebuilt binary.
Release binaries are not code-signed.
Luna access and latency depend on the account and current service conditions.
The default backend needs a network connection.
VisionSieve does not provide mouse, keyboard, browser, video, or live-screen control.
It is not intended for medical imaging, industrial inspection, or precision measurement.
VisionSieve MCP is a community project, not an official OpenAI product.
Uninstall
codex mcp remove visionsieveRemove the installed visionsieve binary and its configuration directory. Users upgrading from 0.5 may also remove the old visual-evidence-gateway binary and configuration directory after confirming the v1 setup works.
Development
python -m venv .venv
# Windows: .venv\Scripts\activate
# macOS/Linux: source .venv/bin/activate
python -m pip install -e ".[dev]"
ruff check .
pytest
python -m compileall -q src tests scripts
python scripts/audit_release.py
python -m build
python scripts/verify_artifacts.pyLicense
MIT
If VisionSieve earns a place in your workflow, a Star helps the next person find it.
Available Tools
1 toolvision.inspectA
Inspect local images and return compact, security-gated visual evidence.
Use this only when correctness depends on visible pixels, image-only text, layout, charts, diagrams, or visual before/after comparison. Prefer source text or structured data when those are sufficient.
Args:
paths: Absolute image paths. At most four; access is restricted by the
configured allow/deny roots.
query: The exact visual question. Do not include unrelated project
context or instructions from inside the image.
mode: Inspection mode. auto selects compare for two images and
general otherwise.
rigor: normal uses the primary backend, critical requests an
independent verifier, and cheap allows the fallback route.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | auto | |
| paths | Yes | ||
| query | Yes | ||
| rigor | No | normal |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses security gating ('access is restricted by the configured allow/deny roots'), mode auto-selection behavior, and rigor levels including an independent verifier for 'critical' and a fallback route for 'cheap'. This is substantial behavioral context, though it stops short of describing the exact output format or failure handling, which would push it to 5.
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?
The description is well-organized: a clear intro, a usage guideline sentence, and a structured Args list. Every sentence provides necessary information without redundancy. It is appropriately sized for the tool's complexity.
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?
The description covers purpose, usage, and parameter semantics thoroughly. However, since there is no output schema, it would be beneficial to describe the return format ('compact visual evidence') in more detail or include examples. This gap prevents a perfect completeness score, but the overall context is strong.
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 0%, so the description must compensate, and it does. Each parameter is explained with meaningful detail: paths must be absolute and at most four, query should be exact and exclude unrelated context, mode auto selects compare for two images, and rigor explains the backend/verifier/fallback behavior. This adds significant value beyond the raw 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 clearly states the tool's function: 'Inspect local images and return compact, security-gated visual evidence.' It specifies the resource (local images) and the action (inspect), and differentiates when to use it versus alternatives by listing conditions like 'correctness depends on visible pixels...' This is a specific, concise purpose statement.
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 explicitly says 'Use this only when correctness depends on visible pixels, image-only text, layout, charts, diagrams, or visual before/after comparison. Prefer source text or structured data when those are sufficient.' This provides clear when-to-use and when-not-to-use guidance, effectively distinguishing it from other tools that might handle text or structured data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
vision.inspect
TDQS
Scored across 1 tool
The server exposes only a single tool, so there is no possibility of confusion between tools. Its purpose is clearly defined by the description.
With one tool, naming is trivially consistent. The 'vision.inspect' name follows a clean namespace.action pattern.
Providing only one tool makes the server feel very thin. While the tool is potent, the surface area is likely too small for a general-purpose vision MCP server, suggesting a need for at least a few complementary tools.
The tool fully covers image inspection with configurable modes and rigor levels, but there is no way to list available images or retrieve metadata, which could be considered minor gaps depending on the intended workflow.
Maintenance
Related MCP Connectors
Same functionality, consuming only 1/20 of the context window tokens.
Endpoint reliability and evidence checks for autonomous software agents.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Image & PDF tools for AI agents: compress, convert, resize, PDF, AI vision, pipeline.
Related MCP Servers
- FlicenseAqualityNot gradedmaintenanceEnables AI agents to analyze images through vision AI providers (Gemini, OpenAI, Claude), performing tasks like image description, object detection with bounding boxes, region-specific analysis, and precise color extraction without consuming context window with raw pixels.4-
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to read images with metadata, OCR text, regions, and citeable evidence without relying on generative LLMs.26 npm2MIT
- FlicenseNot gradedqualityBmaintenanceEnables agents to verify educational, scientific, and engineering visuals by extracting structured evidence and running domain-specific checks against specs and theory.-
- AlicenseAqualityCmaintenanceEnables AI agents to extract, analyze, and manipulate images, PDFs, video, and audio while conserving context through downscaling, truncation, and frame/page caps.22MIT