llm-vision-mcp

by me9rez

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes (OCR, UI description, error diagnosis, diagram interpretation, chart analysis, code extraction), but 'analyze_image' is a generic catch-all that could overlap with any of the specialized tools, creating potential misselection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (analyze_image, extract_text, describe_ui, diagnose_error, understand_diagram, analyze_chart), with only 'code_from_screenshot' being a slight deviation but still fitting the overall style.
Tool Count5/5
7 tools is a well-scoped count for a vision analysis server, covering common image tasks without unnecessary bloat or thinness.
Completeness4/5
The tool set covers general analysis, OCR, UI, errors, diagrams, charts, and code extraction, which is comprehensive for typical vision workflows. Minor gaps like image transformation or object detection exist but are not core to the server's implied purpose.
Average 3.2/5 across 7 of 7 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool analyzes an image file on disk, but doesn't mention whether it's read-only, what it returns, or any side effects. This is insufficient for an agent to predict the tool's behavior.
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 extremely concise and front-loaded, conveying the core purpose in a single phrase. However, it includes redundant bilingual text (same meaning in Chinese and English), which is minor bloat. Still, it's structured and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and the description is too terse to complete the picture. It doesn't explain what the output looks like, how prompt affects behavior, or any limitations. For a tool with 2 params and simple purpose, this is still inadequate.
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?
The input schema covers 100% of parameters with descriptions (image_path and prompt). The tool description itself adds no additional parameter semantics, but the baseline of 3 applies since the schema provides adequate information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('analyze') and resource ('image file on disk'), but 'analyze' is vague and doesn't differentiate from sibling tools like extract_text, describe_ui, or analyze_chart. It lacks a clear definition of what kind of analysis is performed.
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 usage guidance is provided. The description doesn't indicate when to use this tool versus alternatives, nor does it mention any prerequisites or edge cases. Users are left to infer the tool's role from its name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions analyzing trends and insights, but does not describe the return format, limitations, or any operational details such as file accessibility requirements.
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 bilingual phrase that concisely conveys the core purpose. It is front-loaded, direct, and contains no filler, earning maximum efficiency.
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?
For a one-parameter tool, the description provides the essential purpose but omits expected output format, potential error cases, or differentiation from similar tools like understand_diagram. It is minimally viable but lacks richer context.
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?
The input schema already fully describes the sole parameter image_path with an absolute path. The tool description adds no further parameter semantics, so it meets the baseline for high schema coverage.
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 analyzes chart images for trends and insights, using a specific verb ('analyze') and resource ('chart image'). While it is specific to charts and thus distinguishable from siblings like analyze_image, it does not explicitly name alternatives for differentiation.
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 is provided on when to use this tool versus alternatives. The description simply states what it does, with no mention of conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It only says 'extract code' and gives no details about what the tool returns, whether the file is modified, limitations, or behavior on non-code images.
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 exceptionally concise and front-loaded, with every word contributing to the meaning. The bilingual phrasing is efficient and does not add unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, yet the description does not explain what the output looks like or how it handles edge cases. Given the sibling 'extract_text', more context about usage boundaries and return format is needed to fully guide an agent.
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?
The schema covers the single parameter with a clear description, and schema description coverage is 100%. The tool description does not add extra meaning beyond the schema, but the baseline of 3 is appropriate when the schema does the heavy lifting.
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 identifies the verb (extract), resource (screenshot file), and what is produced (code). This distinguishes it from generic image analysis tools and even from 'extract_text', since the focus is specifically on code extraction.
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?
There is no explicit guidance on when to use this tool versus siblings like 'extract_text' or 'analyze_image'. The description only implies its use for screenshots containing code, but offers no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It only says 'describe a UI screenshot file', which implies a read-only operation but does not explicitly disclose that it is read-only, nor does it mention output format, error handling, or any side effects. The addition of 'on disk' is a minor behavioral detail, but overall it lacks sufficient 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?
The description is extremely concise, consisting of only one short bilingual sentence. It is front-loaded with the verb 'describe' and the resource, and every word contributes to the purpose without any unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description should do more to explain the return value or behavior. It does not differentiate from sibling tools that might also handle images, and it omits any indication of what the description looks like (e.g., language, detail level). This makes it incomplete for an agent to confidently invoke.
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?
The schema description fully covers the single parameter 'image_path' with an absolute path explanation. The tool description adds no further meaning about the parameter, so with high schema coverage, a baseline score of 3 is appropriate.
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's purpose with a specific verb ('describe') and resource ('UI screenshot file'), and mentions 'on disk' to indicate local file access. It is distinct from siblings like extract_text or diagnose_error, but does not explicitly contrast with analyze_image, so it falls short of a 5.
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 by specifying a UI screenshot file, but provides no explicit guidance on when to use this tool over alternatives like analyze_image or understand_diagram. There are no exclusions or alternative mentions, making the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It identifies the operation as extraction (read-only) but does not mention the output format, potential limitations, or whether the original file is modified. This is a significant gap for a tool with no output schema.
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 bilingual sentence, front-loaded with the purpose, and contains no extraneous information. It is extremely concise while conveying the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description should explain the return value or result of the OCR operation, but it does not. It also lacks details about supported image formats or error conditions, making it incomplete for a tool without schema-based output documentation.
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?
The input schema already provides full coverage (100%) for the single parameter image_path, including its type and description. The tool description adds no additional semantic detail beyond what the schema provides, so the baseline score of 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 tool performs OCR to extract text from an image file on disk, using a specific verb ('extract'/'OCR') and resource ('text from image file'). It distinguishes itself from sibling tools like analyze_image or describe_ui by naming the exact function.
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 the tool is for extracting text via OCR but provides no explicit guidance on when to choose it over alternatives, nor any exclusions. The usage context is inferred from the name and description rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'diagnose' without explaining whether the tool is read-only, what it returns, whether it accesses the file system for any side effects, or any prerequisites. This is a significant gap for a tool that presumably analyzes an image.
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 exceptionally concise, consisting of two short phrases (Chinese and English) that immediately convey the tool's purpose. Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description gives no hint about what a 'diagnosis' returns or what capabilities/limitations the tool has. The bilingual phrasing also introduces ambiguity (error image vs. screenshot), leaving the agent under-informed for a tool that could vary widely in behavior.
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% for the single parameter 'image_path', whose description already provides the absolute-path requirement. The tool description adds no parameter-specific nuance, so the 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 clearly states a specific verb ('diagnose') and resource ('error screenshot file'), distinguishing it from sibling tools like analyze_image, extract_text, and describe_ui. The Chinese text reinforces this by specifying '错误图片文件' (error image file), though it slightly differs from the English 'screenshot'.
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 implies use for error screenshot files, providing clear context for when to invoke it. However, it does not explicitly name alternatives or state when not to use it, missing an opportunity to differentiate from the sibling image-analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic action and resource type, but does not mention output format, limitations, or what 'interpret' entails (e.g., does it return a summary, a JSON structure, or something else?). This leaves significant ambiguity for the agent.
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, front-loaded sentence with no unnecessary words. It is concise and bilingual, with no fluff or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one well-documented parameter) and lack of annotations or output schema, the description still feels incomplete because it does not explain what the agent should expect as a result, any prerequisites, or edge cases. The description is too minimal to fully guide the agent.
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?
The schema already describes image_path as 'Absolute path to the image file.' The tool description adds value by specifying that the image should be a diagram (flowchart/architecture), giving context about what kind of image is expected. This goes beyond the schema description, so a score above baseline is warranted.
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's function with a specific verb 'interpret' and a specific resource 'diagram image file'. It names diagram types (flowcharts, architecture diagrams) which distinguishes it from sibling tools like analyze_image (general images) and analyze_chart (charts).
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?
Usage context is implied: use this when you have a diagram to interpret. However, there is no explicit guidance on when to use this instead of sibling tools like analyze_image or extract_text, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![llm-vision-mcp MCP server](https://glama.ai/mcp/servers/me9rez/llm-vision-mcp/badges/card.svg)](https://glama.ai/mcp/servers/me9rez/llm-vision-mcp)

Score Badge

Copy to your README.md:

[![llm-vision-mcp MCP server](https://glama.ai/mcp/servers/me9rez/llm-vision-mcp/badges/score.svg)](https://glama.ai/mcp/servers/me9rez/llm-vision-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/me9rez/llm-vision-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server