DeepSeek Vision MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct visual task: custom analysis, faithful description, OCR, comparison, semantic localization, upload, listing, and deletion. The overlaps between analyze and describe are minor and clearly differentiated by purpose and usage notes.
Naming Consistency3/5
Most tools follow a vision_<verb> pattern (analyze, describe, compare, locate, upload), but vision_files_list and vision_files_delete reverse the noun-verb order, and vision_ocr is an abbreviation noun. The shared prefix provides some consistency, but the mixed conventions prevent a higher score.
Tool Count5/5
Eight tools is a well-scoped number for a vision MCP server, covering both image analysis and file lifecycle management without unnecessary bloat. Each tool serves a clear purpose.
Completeness5/5
The tool surface covers the major vision tasks (analysis, description, OCR, comparison, localization) and includes full file management via upload, list, and delete. There are no obvious dead ends; images are immutable so update/delete semantics are appropriately handled.
Average 3.4/5 across 8 of 8 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 must disclose behavioral traits, but it only adds the stylistic promise of 'faithfully and concisely' — this is not a meaningful behavioral disclosure (e.g., side effects, permissions, rate limits, or whether the image is transmitted/stored). The description essentially restates the tool's name without additional context, so it fails to carry the burden that annotations would normally cover.
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, tightly worded sentence that immediately names the action and object. It is front-loaded and avoids verbosity. However, the brevity comes at the cost of omitting essential usage details, so while it is concise, the structural simplicity is not an asset given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, one required, and no output schema or annotations. The description does not explain any parameters, expected input format, return value, or edge cases. For an image-processing tool with sibling tools that likely share similar inputs, the complete lack of parameter documentation makes this definition inadequate for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (image, detail, max_tokens) are described in the schema's description field. The tool description also provides zero information about what these parameters mean, how they affect behavior, or what format 'image' should take (e.g., URL, file path, base64). The agent has no way to correctly fill in these fields based on the description alone.
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 verb ('describe') and resource ('visible content of an image'), and the qualifiers 'faithfully and concisely' hint at a neutral, summary-oriented output that differentiates it from siblings like vision_ocr (text extraction) or vision_analyze (deeper analysis). However, it does not explicitly name any sibling or exclusion, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the listed siblings (vision_analyze, vision_ocr, etc.), no prerequisites, no context about input requirements, and no mention of alternatives. An agent must infer entirely from the name and one-line description, which is insufficient for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No information about side effects, permissions, or what happens to the file; no annotations to supplement.
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?
One concise sentence with no unnecessary words, effectively conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks any context about return values, error handling, or consequences; given the simple operation, more detail is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The file_id parameter is not described beyond its name and type; no explanation of how to obtain it or its format.
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 action (delete) and the resource (uploaded DeepSeek Files API image), distinguishing it from sibling tools that analyze, describe, OCR, compare, locate, upload, or list files.
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 vs alternatives; it only states what it does, not when to use it or any conditions.
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 full behavioral burden. It mentions constraints on local paths and a hint about detail levels, but does not disclose side effects (e.g., read-only nature), rate limits, authentication requirements, or the exact return format. For an analysis tool, these omissions leave a significant transparency gap.
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 concise and well-structured: a one-line purpose, a clear bullet list of image sources, and a short practical hint on detail levels. It is front-loaded and avoids unnecessary verbosity, earning a high score.
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?
With five parameters, no output schema, and no annotations, the description omits essential context: there is no explanation of what the tool returns, no detail on json_mode, and no guidance on max_tokens limits. It also does not mention potential error conditions or prerequisites, leaving the tool under-documented for an AI 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?
Despite 0% schema description coverage, the description adds meaningful context for the images parameter by listing allowed source formats, and for detail by explaining low vs. original usage. However, it leaves json_mode and max_tokens unexplained, and prompt is self-explanatory. It only partially compensates for the lack of schema descriptions.
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: 'Analyze one or more images with a custom prompt.' It clearly distinguishes this from preset siblings like vision_describe and vision_ocr by emphasizing the custom prompt, making the tool's purpose obvious.
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 provides practical guidance on image source types and detail levels (low for coarse, original for fine detail), which helps with parameter selection. However, it does not explicitly state when to choose this tool over alternatives like vision_describe or vision_ocr, leaving the usage context implied.
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?
There are no annotations, and the description does not disclose behavior beyond the action. It does not indicate whether the tool is read-only, what it returns, or any side effects. The minimal description leaves the tool's behavior largely opaque.
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, clear sentence that is concise and to the point. It effectively communicates the core purpose without unnecessary words, though it lacks structured details about usage.
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 covers the basic purpose but omits important context such as parameter meanings, expected output, and when to use it relative to other tools. It is not comprehensive enough for a user to fully understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters. It only mentions comparing images but does not clarify the roles of 'detail', 'question', or 'max_tokens'. The schema provides no descriptions, so the description adds no meaning beyond the raw parameter names and types.
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 action (compare) and the resource (2+ images), and specifies the order is important. It distinguishes from sibling tools by its focus on comparison, which is evident from the verb and resource.
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 does not explicitly state when to use this tool over alternatives like vision_analyze or vision_describe. While the name implies comparison, there is no guidance on specific scenarios or exclusions.
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 key behavioral traits: coordinates are model-estimated, must be validated before destructive actions, and the tool is not deterministic. This is substantial transparency especially given no annotations are present.
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 concise, consisting of two sentences that efficiently cover purpose, behavior, and usage context. It is well-structured with no superfluous content.
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 no output schema, it does not need to explain returns. It provides sufficient context about when to use (agent grounding), what to expect (estimated coordinates), and constraints (validation needed, non-deterministic).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (image, target, detail) with no descriptions, and the tool description does not explain any of them. It provides zero parameter semantics, failing to compensate for the schema's lack of coverage.
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 purpose: 'semantic localization of a visible target.' It uses a specific verb (localization) and resource (visible target), and distinguishes itself by noting it is not a deterministic object detector.
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?
It implies usage for agent grounding and cautions against relying on it for deterministic detection, but does not explicitly state when to use it over sibling tools or when to avoid it beyond the 'not deterministic' hint.
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?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It discloses the ordering (newest first) and scope (user_data image files), but does not mention pagination, error behavior, or what happens if limit is exceeded. For a simple list operation, this is adequate but not rich.
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, tightly worded sentence that front-loads the action and resource. It is efficient and contains no filler, making it easy to scan.
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 simple list tool, the description covers the core action and ordering, but it omits details about the 'limit' parameter and the response format. Since there is no output schema, providing a hint about what the response contains would improve completeness. The description is sufficient for basic use but lacks some practical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'limit', with 0% description coverage. The description does not explain what 'limit' does or its default behavior. Since schema coverage is low, the description should compensate, but it does not mention the parameter at all. The meaning of 'limit' is somewhat intuitive, but it is not documented.
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 verb 'List' and the resource 'uploaded DeepSeek user_data image files', plus the ordering 'newest first'. This distinguishes it from sibling tools like vision_upload or vision_files_delete, which perform different actions. The purpose is unambiguous.
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 this tool is for retrieving a listing of files, which is contextually clear given the siblings. However, it does not explicitly state when to use this over alternatives or mention any exclusions (e.g., 'use this when you need to see available files before analyzing'). It provides solid context but no direct guidance on tool selection.
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?
There are no annotations, so the description carries the full burden. It discloses the core behaviors: visible text is extracted, the result is returned as transcription text, and detail is recommended to be 'original'. This is a read-only OCR operation and the description conveys that, though it does not explain token or input limits.
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 two short sentences, front-loaded with the main purpose and followed by a useful parameter preference. It has no filler or repetition; every sentence contributes.
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 simple OCR tool with three parameters and no output schema, the description provides the core needed context: input type, output form, and a recommended detail setting. Some gaps remain around how the image value should be supplied and how max_tokens affects the result, but the agent can safely select and invoke 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?
The schema has 0% property-description coverage, so the description must compensate. It adds some meaning for the 'detail' parameter with the recommendation 'Prefer detail="original"' and clarifies the image is a screenshot/document, but it does not explain 'max_tokens', and the exact meaning of the detail enum is left to 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?
The description opens with a clear verb and resource: 'Read visible text from a screenshot/document image' and immediately goes on to say the output is the transcription. It unmistakably identifies this as an OCR tool, distinguishing it from siblings like vision_analyze or vision_describe.
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 use is implied by 'Read visible text' and 'transcription,' but the description does not explicitly say when to use this tool versus the sibling vision tools, nor does it state any exclusion conditions. The only prescriptive guidance, 'Prefer detail="original"', is about parameter choice rather than tool selection.
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?
With no annotations provided, the description carries the full behavioral burden, and it does disclose meaningful traits: the destination API, the reusable nature of the file_id, the allowed-roots constraint, and the exact expiry semantics including permanent-storage behavior. However, it omits operational details like file size limits, accepted MIME types, and idempotency/overwrite behavior that would be useful for a data-ingesting operation with zero annotation coverage.
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?
Three terse lines with zero fluff: purpose+return value first, followed by the path constraint and parameter documentation. Every sentence earns its place, and the most critical information 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?
For a small 2-parameter tool with no nested objects and no output schema, the description covers the essentials: what it does, what it returns (reusable file_id), key constraints, and full parameter semantics. The only gaps are operational expectations like rate limits, upload size caps, and whether uploads are idempotent, which slightly limits an agent's ability to anticipate failures.
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 0%, so the description must compensate — and it does. The expires_seconds parameter receives an explicit valid range (3600..2592000), the meaning of null (permanent storage), and a default, all of which go beyond the bare schema types. The local_path constraint (inside allowed roots) is also documented. Only minor details like path format or file extensions are missing.
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 verb+resource ('Upload a local image to DeepSeek Files API') and names the return value (reusable file_id), which clearly distinguishes this from siblings like vision_analyze, vision_ocr, and vision_files_delete. An agent could correctly select this tool over the siblings based on the first sentence alone.
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?
Provides clear contextual constraints for when this tool is appropriate: the path restriction (must be inside DEEPSEEK_VISION_ALLOWED_ROOTS) and the valid expiry window (3600..2592000s or null). While it never explicitly names an alternative tool for when-not-to-use, the scope of when to use it is well-bounded, and the reusable file_id comment implies the upload-then-analyze workflow.
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:

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

Score Badge

Copy to your README.md:

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

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