vision-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The vision_ tools are mostly distinct: qa asks questions, describe gives faithful descriptions, detect returns bounding boxes, and ocr extracts text. The image_ tools are clearly separated by operation. There is slight overlap between vision_qa and vision_describe, but the parameter and return descriptions make their use cases reasonably distinguishable.
Naming Consistency4/5
Tool names follow a clear two-prefix convention: vision_* for understanding tasks and image_* for manipulation/annotation tasks. Minor deviations exist—vision_qa and vision_ocr are noun-like rather than verb-like, and image_get_metadata uses get while other image tools do not—but overall the naming is readable and predictable.
Tool Count5/5
Twelve tools is a well-sized surface for a vision MCP server: four vision analysis tools and eight image processing/annotation tools. Each tool covers a distinct operation without bloat.
Completeness4/5
The tool set covers the core vision workflow well: understand, describe, detect, OCR, transform, and annotate images. Minor gaps like explicit format conversion or color/quality adjustments exist, but they are not critical for typical visual QA and image inspection use cases.
Average 4/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 2.0.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only signal readOnly=false and destructive=false, so the description adds useful behavioral context: positive angles mean clockwise, output is always a base64 PNG, and output_path is an optional save location. It clarifies the side-effect boundary without contradicting any annotation.
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 compact and front-loaded with the core action, followed by a short parameter list and a return-value line. It is slightly repetitive of the schema, but remains scannable and free of unnecessary prose.
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 straightforward rotation tool, the description plus full schema coverage and annotations cover required parameters, angle convention, optional output, and return format. Minor gaps such as error handling or alternative-tool routing do not significantly hinder correct invocation.
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 baseline is 3. The description mostly repeats what the schema already says about angle direction and output_path behavior, only adding example angles (90/180/270/45). It does not introduce meaningful new parameter semantics.
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 opens with '旋转图片指定角度' (rotate an image by a specified angle), clearly identifying the action, resource, and key parameter. It is sufficiently distinct from sibling operations like resize, crop, and flip, though it does not explicitly reference any sibling tool.
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?
The description details parameters and return behavior but provides no guidance on when to choose rotation over sibling tools such as image_flip or image_crop. In a context with multiple image transformation siblings, the absence of explicit routing or exclusions leaves selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds little beyond restating the input/output flow and the max_dimension scaling behavior (which is also in the schema), and it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with purpose and use case, but it duplicates the parameter list and return value that are already covered by the schema and output schema. Those duplicated sentences do not earn their place, reducing overall conciseness.
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?
Combined with the fully descriptive schema and available annotations, the description is complete enough for an agent to invoke the tool correctly. It adds useful application context, and the output schema handles return-value details. The only minor gap is the lack of explicit guidance on when to prefer a sibling 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?
The input schema covers 100% of the parameter semantics with detailed descriptions for images, question, and max_dimension. The description's parameter list merely repeats the schema information without adding new meaning, so it provides no extra value beyond the structured schema.
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 identifies the operation as visual question answering ('对图片进行视觉问答') with the specific inputs images and question. It also provides an application context (checking Web/PPT pages), which implicitly distinguishes it from generic describe or OCR vision tools, though it does not explicitly name sibling tools.
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?
It gives a concrete use case: '适用于检查Web页面、PPT页面等是否符合特定要求或样式', indicating when this tool is appropriate. However, it does not explicitly state when not to use it or suggest alternative tools for other scenarios, so it lacks complete exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false; the description adds useful behavioral context by stating the return value is a base64 PNG plus metadata and that output_path optionally saves to a file. It does not contradict the annotations. It stops short of disclosing overwrite behavior for existing output files, but the annotation coverage lowers the burden.
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 well structured: a one-sentence purpose, a compact parameter list, and a return-value summary. Every line carries necessary information for a 7-parameter tool, and nothing is redundant or padded.
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 a complete input schema, an output schema, and annotations, the description is sufficiently complete: it covers input sources, coordinate options, optional file output, and return format. It could have mentioned out-of-bounds behavior or coordinate validation details, but these are not essential for correct invocation.
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 every parameter, including defaults and constraints such as normalized behavior and width/height bounds. The description's parameter list largely restates this information without adding meaningful new semantics for the parameters.
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 opens with a specific action and resource: '裁剪图片的指定区域，返回裁剪后的子图' (crop a specified region of an image and return the cropped subimage). This clearly distinguishes it from siblings like resize, rotate, flip, and concat, though it does not explicitly name any alternative.
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 is reasonably implied by the tool name and the phrase '裁剪图片的指定区域' — an agent can infer it should be used when a sub-region of an image is needed. However, the description gives no explicit when-to-use guidance, no exclusions, and no pointers to alternative tools such as image_resize or image_rotate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses useful non-obvious behavior: Chinese font priority via VISION_MCP_FONT_PATH with system fallback, normalized vs pixel coordinates, and the guarantee that a base64 PNG is always returned. The annotations are all false/no-op, so the description carries the behavioral burden and handles it well, though it does not discuss output-file overwriting or other side effects.
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 compact, front-loads purpose and usage, and organizes parameter details into a scannable block. It is not bloated, though it repeats some schema content like default colors and font sizes, which keeps it from being truly exceptional.
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?
The description covers input image, text list shape, coordinate mode, optional output path, and return format, giving an agent enough to invoke the tool correctly. Minor edge details such as coordinate origin or overwrite behavior are not stated, but the schema and output behavior cover the essential requirements.
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 the baseline is 3, but the description adds one meaningful extra behavior: output_path does not suppress the base64 return. It otherwise summarizes the text fields and defaults clearly, adding modest value beyond the schema.
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 states a clear action-resource pair ('在图片上绘制文字') and explains the use case of adding annotations or comments. It is easily distinguishable from siblings like image_draw_box and image_rotate, though it does not explicitly name an alternative tool.
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 gives a clear intended-use context ('适用于在图片上添加注释、说明文字等'), which tells an agent when this tool is appropriate. It does not mention exclusions or explicitly route to alternatives, so it falls short of full when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: it promises "不推测或脑补" (no hallucination) and discloses the automatic resizing behavior before sending to the VLM via max_dimension. This gives agents a realistic expectation of 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 reasonably front-loaded with the core purpose and remains compact. The parameter list and return-value note are helpful, though the opening sentences slightly overlap in meaning ("详细、真实地解读" vs. "忠实描述"). It is still efficient and free of irrelevant content.
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?
For a read-only image-description tool, the description, combined with fully documented input parameters, strong annotations, and an output schema, covers everything an agent needs to invoke it correctly. It includes accepted input forms, detail-level options, resize behavior, and the nature of the returned description.
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 detailed descriptions, including accepted URL/path formats, enum values, defaults, and constraints. The description mostly restates this information, adding minimal new meaning, 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 opens with a specific action—"详细、真实地解读图片中的内容"—and clarifies the exact scope: describe all visible content without speculation. This clearly distinguishes it from siblings like vision_qa, vision_detect, and vision_ocr, which answer questions, detect objects, or extract text.
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 when to use the tool—whenever a faithful, comprehensive image description is needed—but it does not explicitly state when to prefer alternatives or mention exclusions. There is no direct routing to vision_qa, vision_detect, or vision_ocr, so the guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, non-destructive, idempotent, openWorld). The description adds meaningful behavioral context beyond annotations: automatic resizing before sending to the VLM, the option to disable it via max_dimension=0, and normalized coordinate conventions for bounding boxes. No contradictions with 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 well-structured with an opening summary, parameter list, and return format example. It is somewhat longer than strictly necessary because some parameter details repeat the schema, but every section is readable and the core purpose is front-loaded.
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 annotations covering safety, a 100%-covered schema, and an output schema present, the description still adds valuable context around normalization, scaling behavior, and detection semantics. The tool is fully specified for an agent to select and invoke correctly.
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 three parameters. The description adds useful examples for target descriptions and clarifies the URL vs local path behavior, but it largely duplicates schema information rather than introducing substantial new meaning.
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 states a specific verb ('检测'), a clear resource (images), and a well-defined outcome (normalized bounding boxes). The phrase '返回所有检测到的目标的位置信息' makes it distinct from sibling tools like vision_qa or vision_ocr, even without naming them.
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 intended usage is implied through the description and parameter guidance, and the tool's purpose is clear enough to infer when to call it. However, there is no explicit statement of when to choose this tool over vision_qa, vision_describe, or vision_ocr, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds useful return behavior: the flipped image is returned as base64 PNG along with metadata, and output_path only controls optional saving. It also clarifies that the result is still returned even when output_path is set. No contradiction with annotations.
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 leads with a one-sentence purpose, then presents parameters in a clean list and a short return note. Every sentence is functional and there is no filler.
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?
For a simple, deterministic image transform, the description plus full schema and annotations covers accepted input forms, direction values, optional output path, and return format. An output schema exists, so return details need not be elaborated further.
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%, with all three parameters fully documented in the schema. The description repeats those parameter meanings but adds no new semantics beyond the schema.
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?
States a specific operation: horizontally or vertically mirror-flip an image, explicitly mapping horizontal and vertical directions. This clearly distinguishes it from sibling image tools like rotate, crop, resize, and concat.
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?
No explicit when-to-use or when-not-to-use guidance is provided, nor are alternatives named. However, the operation is self-descriptive enough that an agent can infer to use this tool when the request is to mirror an image horizontally or vertically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: images are automatically resized before being sent to the VLM, controlled by max_dimension, and the output is a structured JSON with text_blocks and full_text. No contradiction with annotations exists.
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 compact and front-loaded with the core purpose. It then presents parameters clearly and gives a concise JSON output example. Every section earns its place with no filler or repetition.
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?
The description covers the required parameter, the optional parameter, preprocessing behavior, and the exact return shape. Combined with the safety profile from annotations and the presence of an output schema, an agent has everything needed to invoke this tool correctly.
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%, and the parameter notes in the description essentially restate what the schema already provides. No additional nuance or format detail is added for images or max_dimension, 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 states a clear verb and resource: extract all text from images, and enumerates content types such as titles, body, labels, and button text. This makes it unambiguous as an OCR tool and distinguishes it from sibling tools like vision_describe, vision_qa, and vision_detect.
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 use case is implied—use this when you need all visible text from an image—but it never explicitly contrasts it with vision_describe or vision_qa, nor states when not to use it. The agent must infer the routing from the tool name and general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavior beyond the annotations: the return format is base64 PNG plus metadata, output_path is optional but saving does not change the return behavior, and coordinates can be normalized or pixel-based. This is useful context. It does not explicitly state whether the original image file is modified, but annotations and the output_path design suggest a non-destructive draw-and-return 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 well-structured: a one-line purpose, a short use-case sentence, a compact parameter list, and a return description. There is some redundancy with the input schema, but it is not excessive and the information is easy to scan.
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?
The description covers purpose, use cases, all parameters including normalized and output_path behavior, and the return format. With a full input schema and an output schema present, nothing critical is missing for an agent to select and invoke this tool correctly.
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 and their meanings. The description's parameter list mostly repeats this information without adding deeper semantics, such as examples of coordinate formats or color syntax beyond what the schema provides. 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 a specific action ('绘制方框标记') on a specific resource ('图片'), and adds that text labels can be included. It also gives concrete use cases ('标注检测结果、标记图片中的特定区域'), which distinguish it from siblings like image_draw_text or vision_detect.
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 gives clear context for when to use the tool: annotating detection results and marking specific image regions. It does not explicitly mention alternatives or when not to use it, but the use-case framing is enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive. The description adds that it returns a defined set of metadata fields and accepts either a local path or URL. This is useful additional behavioral context beyond the 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 short and front-loaded, with the metadata payload listed clearly. The separate '参数' bullet is slightly redundant with the input schema but not bloated.
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?
For a one-parameter, read-only metadata getter with annotations and an output schema, nothing essential is missing. The description covers purpose, accepted input format, and the returned metadata categories.
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%: the sole parameter's description already explains the URL-vs-local-path distinction. The tool description repeats '图片路径或URL' but adds no new meaning, so the baseline 3 for full schema coverage 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 states a specific action — get image metadata — and enumerates exact returned fields (width, height, format, channels, color space, DPI, alpha channel, EXIF orientation). This clearly separates it from sibling vision/image-manipulation tools.
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?
It establishes clear context: use when you need image metadata such as dimensions, format, or EXIF orientation. It does not explicitly name alternatives or exclusion conditions, so it misses the top score, but the context is specific enough for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已声明非只读、幂等、非破坏性；描述在此基础上补充了关键行为：支持两种尺寸指定方式、fit模式、返回base64 PNG、output_path可选但总会返回。未说明对URL的下载/格式错误处理，但整体透明性高于最低要求。
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?
开头一句话点明用途，随后用两种模式+参数列表+返回值的紧凑结构呈现，每部分都有信息量，没有冗长背景或重复误导。参数表的补充说明使描述自洽。
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?
对于6参数、1枚举、有输出schema的工具，描述覆盖了所有参数、模式和返回格式，足够完整；主要缺口是width/height与scale同时提供时的优先级/报错规则，以及文件写入的覆盖行为，但这类边界信息可由schema约束推断。
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覆盖率为100%，基线为3；描述额外赋予了实际语义：scale举例（0.5缩小一半）、width/height可只传一个并保持宽高比、output_path设置后仍返回base64。这些超过schema字段本身的信息帮助agent正确构造参数。
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?
描述以明确的动词和资源开头：“缩放图片到指定尺寸”，并列出三种操作模式，清楚表明这是图像缩放工具。结合兄弟工具（crop/rotate/flip等），它足够独特，agent可无歧义地选择。
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?
描述提供了何时进行缩放的清晰上下文（指定width/height或scale），但没有明确说明何时不应使用、参数冲突如何解决，或与crop/rotate等替代工具的选择标准。使用场景只能从“缩放图片”中推断。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond annotations: it documents three layout modes, clarifies that cols only applies to grid, explains the optional output_path behavior, and states that the result is a base64 PNG with metadata. This goes beyond what readOnlyHint/idempotentHint/destructiveHint provide.
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 well-structured with a one-line summary, a compact layout list, and a parameter list. No sentence is wasted, and the key behavior appears first.
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?
For a 6-parameter tool with an output schema and annotations, the description is complete: it covers layouts, parameters, defaults, the optional file save, and the return format. It pairs well with the schema and annotations, so an agent can invoke it correctly without guessing.
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 the schema already documents all six parameters. The description still adds value by summarizing each parameter and highlighting the grid-only nature of cols, plus the persistence-side effect of output_path. This is more than baseline.
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 opens with a specific verb and resource: '将多张图片拼接为一张' (concatenate multiple images into one). It then enumerates the three supported layouts, making the tool's scope unmistakable and distinct from sibling image operations like resize, crop, rotate, and flip.
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 establishes clear usage context: this tool is for combining multiple images into a single image, with layout choices. It does not explicitly name alternatives or state 'use this instead of X', but the sibling tools are sufficiently different that the provided context makes the selection obvious.
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:

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

Score Badge

Copy to your README.md:

[![vision-mcp MCP server](https://glama.ai/mcp/servers/karond-is-me/vision-mcp/badges/score.svg)](https://glama.ai/mcp/servers/karond-is-me/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/karond-is-me/vision-mcp'

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