A
licenseA
qualityA
maintenanceA portable image-understanding MCP server that lets agents analyze local images, URLs, or base64 images via an OpenAI-compatible vision model.
1
310
72
MIT
Codex Vision MCP
by darkamenosa
Uses OpenAI's Codex/Responses backend to provide computer vision capabilities, enabling text-only agents to analyze images, screenshots, diagrams, and local files.
Click on "Install 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., "@Codex Vision MCPwhat does ./demo.png describe?"
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.
Codex Vision MCP
Codex Vision MCP is a local MCP server that adds computer-vision tools to coding agents and models that do not support native image input. It uses existing Codex OAuth credentials and calls the ChatGPT/Codex Responses backend.
The main use case is running a strong text/code model, such as GLM 5.2, while still giving the agent a way to inspect screenshots, diagrams, UI mockups, chart images, and local image files through MCP tools.
Name
Use Codex Vision MCP.
Vision MCP is too generic. The important differentiator is that this server uses Codex OAuth and the Codex Responses backend as the vision provider.
The package and executable names are:
package:
codex-vision-mcpcommand:
codex-vision-mcpsuggested MCP server name:
codex-vision
Related MCP server: multimodal-mcp
Tools
ui_to_artifactextract_text_from_screenshotdiagnose_error_screenshotunderstand_technical_diagramanalyze_data_visualizationui_diff_checkanalyze_imageanalyze_video
Tool names are intentionally compatible with the Z.AI vision MCP tool shape so prompts and agent behavior can transfer easily.
How It Works
The MCP client calls one of the vision tools with a local file path, remote URL, or data:image/... URL. This server loads the image, sends it to the Codex Responses backend with Codex OAuth, and returns a text result to the calling agent.
This is useful when the active model is text-only or when the model provider rejects native image input.
Current Limitation
In Claude Code, pasting an image directly into the client does not automatically call this MCP server. Claude Code transcodes pasted images and sends them directly to the selected model. If the selected model does not support image input, the model call can fail before MCP tools are involved.
For now, use a local file path and ask the agent to inspect that file:
What does ./demo.png describe?or:
Use codex-vision to analyze /absolute/path/to/demo.pngA future Claude Code integration can intercept pasted images before the model call, route them through this MCP server, and continue with a text-only prompt.
Install From Source
npm install
npm run build
node dist/index.js --smoke--smoke checks Codex OAuth discovery and prints redacted auth metadata.
Add To Claude Code
Project-local registration is recommended. It keeps this vision server enabled only for the repository that needs it.
cd /path/to/your/project
claude mcp add --scope local codex-vision -- npx -y codex-vision-mcpFor local development from this checkout:
cd /path/to/your/project
claude mcp add --scope local codex-vision -- node /absolute/path/to/vision_mcp/dist/index.jsOn Windows PowerShell:
cd C:\path\to\your\project
claude mcp add --scope local codex-vision -- npx -y codex-vision-mcpAuth
Current auth discovery prioritizes local Codex auth first after explicit environment overrides:
CODEX_VISION_AUTH_JSONCODEX_IMAGEN_AUTH_JSONCODEX_AUTH_JSONCODEX_HOME/auth.json~/.codex/auth.json
The server refreshes near-expiry OAuth tokens through https://auth.openai.com/oauth/token and writes them back atomically.
Environment
CODEX_VISION_MODEL: Responses model, defaultgpt-5.5CODEX_VISION_BASE_URL: defaulthttps://chatgpt.com/backend-api/codexCODEX_VISION_AUTH_JSON: explicit auth JSON pathCODEX_VISION_IMAGE_DETAIL:auto,low,high, ororiginalCODEX_VISION_TIMEOUT_MS: default300000CODEX_VISION_MAX_IMAGE_MB: default10CODEX_VISION_MAX_VIDEO_MB: default50CODEX_VISION_VIDEO_FRAMES: default4CODEX_VISION_MCP_LOG_PATH: optional log file path
Platform Support
The server is implemented in Node.js and should run on macOS, Linux, and Windows with Node.js 22 or newer.
Cross-platform notes:
Local paths are resolved with Node
pathandos.homedir().~/.codex/auth.jsonmaps to the current user's home directory on each OS.Auth file permissions are tightened with
chmodonly on non-Windows systems.The optional Codex CLI version lookup falls back safely if
codexis not onPATH.analyze_videorequiresffmpegonPATH; installffmpegseparately on each OS or extract frames manually and useanalyze_image.
This has been checked for obvious macOS-only assumptions in the source. Windows and Linux should work, but still need real-machine smoke testing.
Development
npm run check
npm run buildRun the server directly:
node dist/index.jsAvailable Tools
8 toolsanalyze_data_visualizationAnalyze Data VisualizationARead-only
Analyze charts, graphs, dashboards, and other data visualizations to extract metrics, trends, anomalies, and recommendations.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | What insights or information to extract from this visualization. | |
| image_detail | No | Optional Codex Responses input_image detail. Defaults to CODEX_VISION_IMAGE_DETAIL or high. | |
| image_source | Yes | Local file path, remote URL, or data:image URL to the chart or dashboard. | |
| analysis_focus | No | Optional focus area, such as trends, anomalies, comparisons, or metrics. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| success | Yes | |
| metadata | No |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true. The description adds contextual detail about extracting metrics, trends, anomalies, and recommendations, which aligns with read-only behavior. However, it does not disclose potential limitations (e.g., inability to extract specific data points) beyond what annotations imply. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 17 words, front-loaded with the key purpose. Every word is necessary, and there is no repetition or filler. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but mentioned), the description does not need to explain return values. It adequately covers the input and expected output type (insights). However, it could be slightly more specific about the scope (e.g., supporting static charts vs. interactive dashboards), but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters well. The description does not add meaningful semantics beyond what the schema provides (e.g., it does not explain the 'analysis_focus' parameter or how 'image_detail' affects analysis). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Analyze' and the resource 'charts, graphs, dashboards, and other data visualizations'. It distinguishes from siblings like 'analyze_image' (general) and 'understand_technical_diagram' (technical diagrams), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for data visualization analysis but lacks explicit guidance on when to use this tool vs alternatives (e.g., when to use 'analyze_image' instead). There is no mention of when not to use it or prerequisites, leaving the agent to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_imageAnalyze ImageARead-only
General-purpose image analysis for cases not covered by the specialized tools. Use as a fallback for flexible visual understanding.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Detailed description of what to analyze, extract, or understand from the image. | |
| image_detail | No | Optional Codex Responses input_image detail. Defaults to CODEX_VISION_IMAGE_DETAIL or high. | |
| image_source | Yes | Local file path, remote URL, or data:image URL to the image. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| success | Yes | |
| metadata | No |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds minimal behavioral context beyond 'flexible visual understanding', but does not contradict annotations. With strong annotation coverage, description adds limited extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, directly communicates purpose and usage. Efficiently structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a general-purpose fallback tool with an output schema (context signal), the description is largely sufficient. Lacks detail on output format or edge cases, but adequate given its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not elaborate on parameter details beyond what the schema already provides, so no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'General-purpose image analysis' and positions itself as a fallback for cases not covered by specialized tools, effectively distinguishing from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using it as a fallback when specialized tools do not apply, providing clear usage context. Lacks explicit when-not-to-use examples but sibling list compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_videoAnalyze VideoARead-only
Analyze a local or remote video by extracting sampled frames with ffmpeg and sending them to Codex vision analysis.
Requires ffmpeg on PATH. For precise video work, extract important frames manually and use analyze_image or ui_diff_check.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Detailed prompt describing what to analyze, extract, or understand from the video. | |
| frame_count | No | Optional number of frames to extract with ffmpeg before sending to Codex. Defaults to 4. | |
| image_detail | No | Optional Codex Responses input_image detail. Defaults to CODEX_VISION_IMAGE_DETAIL or high. | |
| video_source | Yes | Local file path or remote URL to the video. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| success | Yes | |
| metadata | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive. The description adds that it requires ffmpeg and samples frames, which are behavioral traits not in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are efficient and provide essential information without redundancy. The purpose is stated first, and the guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the key aspects: purpose, external dependency, and usage alternatives. It is complete enough for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description does not add any additional parameter semantics beyond what is in the schema, so it merits a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes video by extracting sampled frames with ffmpeg and sending them to Codex vision analysis. It distinguishes itself from siblings like analyze_image by noting that for precise work, one should use those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the requirement of ffmpeg on PATH, and provides guidance: for precise video work, extract frames manually and use other tools. This helps the agent decide when not to use this tool, though it could be more explicit about when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diagnose_error_screenshotDiagnose Error ScreenshotARead-only
Diagnose screenshots of error messages, stack traces, exception dialogs, or failed command output.
Returns likely cause, actionable fixes, and prevention notes where possible.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Description of what needs diagnosis in the error screenshot. | |
| context | No | Optional context about when or where the error occurred. | |
| image_detail | No | Optional Codex Responses input_image detail. Defaults to CODEX_VISION_IMAGE_DETAIL or high. | |
| image_source | Yes | Local file path, remote URL, or data:image URL to the error screenshot. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| success | Yes | |
| metadata | No |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so agent knows it is safe. The description adds the output format but does not elaborate on behavioral traits like external API calls or processing time, which are hinted by openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load purpose and output summary without wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers input types and output summary. Given the openWorldHint and optional image_detail parameter, additional context about processing time or image requirements would improve completeness. Output schema exists, so return format is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description does not add further semantic guidance for parameters, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Diagnose' targeting error-related screenshots, listing input types (error messages, stack traces, etc.) and output types (cause, fixes, prevention). It clearly distinguishes from sibling tools like analyze_image (general) and extract_text_from_screenshot (text extraction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for error screenshots but does not explicitly state when not to use it or reference alternative tools for non-error images. It lacks explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_text_from_screenshotExtract Text From ScreenshotARead-only
Extract and recognize text from screenshots, including code, terminal output, logs, documentation, and UI copy.
Use when the user needs faithful OCR or text reconstruction from an image.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Instructions for text extraction and formatting. | |
| image_detail | No | Optional Codex Responses input_image detail. Defaults to CODEX_VISION_IMAGE_DETAIL or high. | |
| image_source | Yes | Local file path, remote URL, or data:image URL to the screenshot. | |
| programming_language | No | Optional programming language hint if the screenshot contains code. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| success | Yes | |
| metadata | No |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds 'faithful OCR' but no additional behavioral context beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with action and examples, followed by usage context. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full parameter descriptions, output schema, and annotations, the description is complete. It explains tool purpose and usage, and the sibling tools cover other image-related tasks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage). Description itself adds no extra parameter meaning; examples are given but not linked to specific parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool extracts text from screenshots, listing specific use cases like code, terminal output, logs, etc. It clearly distinguishes from sibling tools that analyze images or data visualizations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit guidance when to use: 'when the user needs faithful OCR or text reconstruction from an image.' No explicit when-not, but sibling names imply other tools for different tasks, so it's clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ui_diff_checkUI Diff CheckBRead-only
Compare an expected/reference UI screenshot with an actual/current UI screenshot and report visual implementation differences.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Instructions for the comparison and aspects to focus on. | |
| image_detail | No | Optional Codex Responses input_image detail. Defaults to CODEX_VISION_IMAGE_DETAIL or high. | |
| actual_image_source | Yes | Local file path, remote URL, or data:image URL to the actual/current UI. | |
| expected_image_source | Yes | Local file path, remote URL, or data:image URL to the expected/reference UI. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| success | Yes | |
| metadata | No |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool compares and reports differences, which is consistent. It does not disclose additional traits like authorization needs or output format, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. The verb 'compare' is front-loaded. Every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but covers the core function. With 4 parameters fully documented in schema and an output schema present (not needing return value explanation), it is adequate but could add more detail about how the comparison works or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description does not add extra meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two UI screenshots and reports differences. It specifies the verb 'compare' and resources (expected/reference vs actual/current). However, it does not explicitly distinguish from sibling tools like diagnose_error_screenshot or analyze_image, but the purpose is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., analyze_image, diagnose_error_screenshot). The description implies usage for UI diff checking but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ui_to_artifactUI To ArtifactARead-only
Convert UI screenshots into artifacts: frontend code, AI prompts, design specifications, or natural-language descriptions.
Use only for UI screenshots. Do not use for OCR-only screenshots, error messages, diagrams, or charts.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Detailed instructions describing what to generate from the UI image. | |
| output_type | Yes | Artifact to generate: code, prompt, spec, or description. | |
| image_detail | No | Optional Codex Responses input_image detail. Defaults to CODEX_VISION_IMAGE_DETAIL or high. | |
| image_source | Yes | Local file path, remote URL, or data:image URL to the UI screenshot. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| success | Yes | |
| metadata | No |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context about output types and exclusions, but does not disclose additional behavioral traits like permissions, rate limits, or response details. With annotations present, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence describes the core action, the second provides clear usage boundaries. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, 100% schema coverage, annotations, and an output schema, the description is sufficiently complete. It covers purpose, usage boundaries, and output types. Minor improvement could detail image_detail options, but schema already handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantic context by listing artifact types ('frontend code, AI prompts, design specifications, or natural-language descriptions'), which relates to the output_type parameter, enhancing understanding beyond the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Convert UI screenshots into artifacts') and lists artifact types. It explicitly distinguishes from siblings by stating what not to use it for (OCR-only screenshots, error messages, diagrams, charts), making the purpose clear and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Use only for UI screenshots' and 'Do not use for OCR-only screenshots, error messages, diagrams, or charts', providing clear when-to and when-not-to-use guidance. However, it does not explicitly name sibling tools as alternatives, which would be more comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
understand_technical_diagramUnderstand Technical DiagramARead-only
Analyze technical diagrams including architecture diagrams, flowcharts, UML, ER diagrams, network diagrams, and sequence diagrams.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | What you want to understand or extract from this diagram. | |
| diagram_type | No | Optional diagram type hint, such as architecture, flowchart, UML, ER, or sequence. | |
| image_detail | No | Optional Codex Responses input_image detail. Defaults to CODEX_VISION_IMAGE_DETAIL or high. | |
| image_source | Yes | Local file path, remote URL, or data:image URL to the diagram. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| success | Yes | |
| metadata | No |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the agent knows it is a safe read operation. The description adds no further behavioral context (e.g., output format, handling of image types). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Analyze technical diagrams'). It is concise but could benefit from structured categories or bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described. However, the description lacks details on error conditions, input size limits, or prerequisite knowledge. It is adequate but not comprehensive for a complex diagram analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 each parameter thoroughly. The description adds minimal extra meaning beyond listing diagram types, which is also present in the diagram_type parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Analyze' and clearly identifies the resource 'technical diagrams', listing multiple diagram types (architecture, flowcharts, UML, etc.), which effectively differentiates it from sibling tools like analyze_data_visualization or analyze_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for technical diagrams but does not explicitly state when to use this tool over siblings or when not to use it. No exclusions or alternative tool references are provided.
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.
8 tool updates
v0.1.0- First observed
analyze_data_visualization - First observed
analyze_image - First observed
analyze_video - First observed
diagnose_error_screenshot - First observed
extract_text_from_screenshot - First observed
ui_diff_check - First observed
ui_to_artifact - First observed
understand_technical_diagram
TDQS
A3.9/5.0
Scored across 8 tools
Disambiguation4/5
Tools target distinct visual domains (charts, UI, diagrams, errors) with clear descriptions. The fallback analyze_image could overlap but is explicitly a catch-all. Only extract_text_from_screenshot and diagnose_error_screenshot have slight boundary ambiguity, but usage notes clarify.
Naming Consistency4/5
All names use lowercase snake_case and a verb_noun or adjective_noun pattern. Some verbs vary (analyze, diagnose, extract, ui_diff_check, ui_to_artifact, understand), but the structure is predictable and readable.
Tool Count5/5
8 tools is well-scoped for a vision analysis server. Each tool addresses a specific common use case without overcrowding. The count is appropriate for the domain.
Completeness4/5
The tool set covers major vision tasks: general image/video analysis, UI comparison, error screenshots, text extraction, diagram understanding, and artifact generation. Minor gaps like object detection exist, but the set is comprehensive for typical developer workflows.
Maintenance
ActivityStale
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server for agentverse documentation, generated by doc2mcp.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Related MCP Servers
- FlicenseAqualityBmaintenanceLocal MCP server that adds multimodal capabilities to text-only models like Codex/DeepSeek, offering tools for image description, audio transcription, video analysis, image/video generation, and speech synthesis.10-
- FlicenseNot gradedqualityBmaintenanceA lightweight MCP server that provides vision capabilities to text-only models like Claude Code and Codex by forwarding images to an OpenAI-compatible multimodal model, offering tools for image analysis and OCR.-
- AlicenseNot gradedqualityCmaintenanceMCP server that gives text-only agents like Claude Code and Codex image, video, and audio analysis capabilities through local setup and multiple AI providers.MIT