Skip to main content
Glama
snow930

Vision-Multi MCP Server

by snow930
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Vision-Multi MCP Server

多模型 / 多 API 供应商的视觉识图 MCP 服务器。一个 analyze_image 工具，可手动切换不同模型与 API 后端，并内置故障自动切换：主后端失败（401/403/429）时自动回退到可用后端，且把切换结果持久化，重启后依然生效。

  • 协议：MCP（Model Context Protocol），stdio transport

  • 语言：Node.js（>= 18）

  • 适用客户端：Reasonix、Claude Code 等支持 MCP 的客户端

功能特性

  • 多后端识图：analyze_image 一次注册，可切换多个模型/API 供应商（provider 参数）

  • 故障自动切换：未手动指定 provider 时，主后端连续失败达阈值（默认 1 次）自动切换到回退成功的后端

  • 状态持久化：切换结果写入状态文件（默认 <REASONIX_HOME>/mcp-state/vision-multi-state.json），重启后依然生效

  • 手动覆盖：provider / model 参数随时手动指定，不受自动切换影响

  • 只读声明：两个工具均声明 annotations.readOnlyHint: true，可在 Plan 模式与严格只读子代理中使用

  • 密钥安全：所有后端密钥仅经环境变量注入，代码与配置示例中不含真实密钥

Related MCP server: simple-vision-mcp

工具

analyze_image —— 分析图片

参数

类型

必填

说明

image

string

是

本地图片路径或 http(s) 图片 URL

prompt

string

否

问题（默认：请详细描述这张图片的内容）

provider

string

否

后端 id（用 list_providers 查看），不传用默认后端

model

string

否

模型名，覆盖该后端的默认模型

list_providers —— 查看当前可用后端

返回各后端的 id / 名称 / 模型 / 接口地址（不含密钥），切换前先查询。

安装

git clone https://github.com/snow930/reasonix-vision-multi.git
cd reasonix-vision-multi
npm install

配置

后端来源有两种，可共存：

  1. 默认后端 dashscope：环境变量 DASHSCOPE_API_KEY / DASHSCOPE_BASE_URL / VISION_MODEL

  2. 附加后端：环境变量 VISION_PROVIDERS（JSON 数组，可配任意多个 OpenAI 兼容端点）

环境变量

变量

必填

说明

DASHSCOPE_API_KEY

是（至少一个后端）

默认后端 API key

DASHSCOPE_BASE_URL

否

默认后端接口地址（默认 https://dashscope.aliyuncs.com/compatible-mode/v1）

VISION_MODEL

否

默认后端模型（默认 qwen3.7-flash）

VISION_DEFAULT_PROVIDER

否

默认后端 id（不传时按 apiKey 已配置的第一个后端）

VISION_PROVIDERS

否

附加后端 JSON 数组（见下）

VISION_FAIL_THRESHOLD

否

连续失败多少次后自动切换默认后端（默认 1）

VISION_STATE_FILE

否

状态文件路径（默认 <REASONIX_HOME>/mcp-state/vision-multi-state.json）

VISION_PROVIDERS 示例（密钥请用你自己的）

[
  {
    "id": "modelscope",
    "name": "ModelScope 通义千问VL",
    "baseUrl": "https://api-inference.modelscope.cn/v1",
    "apiKey": "sk-xxx",
    "model": "Qwen/Qwen3-VL-8B-Instruct"
  },
  {
    "id": "siliconflow",
    "name": "硅基流动",
    "baseUrl": "https://api.siliconflow.cn/v1",
    "apiKey": "sk-xxx",
    "model": "Qwen/Qwen2.5-VL-72B-Instruct"
  }
]

客户端注册示例

Reasonix 全局配置 config.toml（[[plugins]]）：

[[plugins]]
name    = "vision-multi"
command = "node"
args    = ["/path/to/reasonix-vision-multi/index.js"]
env     = {
  DASHSCOPE_API_KEY        = "sk-xxx",
  VISION_MODEL             = "qwen3.7-flash",
  VISION_DEFAULT_PROVIDER  = "dashscope",
  VISION_PROVIDERS         = "[{\"id\":\"modelscope\",\"name\":\"ModelScope\",\"baseUrl\":\"https://api-inference.modelscope.cn/v1\",\"apiKey\":\"sk-xxx\",\"model\":\"Qwen/Qwen3-VL-8B-Instruct\"}]"
}

Claude Code 项目 .mcp.json：

{
  "mcpServers": {
    "vision-multi": {
      "command": "node",
      "args": ["/path/to/reasonix-vision-multi/index.js"],
      "env": {
        "DASHSCOPE_API_KEY": "sk-xxx"
      }
    }
  }
}

修改配置后需重启会话 / 重新注册 MCP server 生效。

自检

# 先设置测试图片路径与至少一个后端的 key
VISION_TEST_IMAGE=/path/to/test.png DASHSCOPE_API_KEY=sk-xxx npm test
# 或直接与 MCP 客户端连接后调用 list_providers / analyze_image

e2e-test.js 会依次验证 initialize / tools/list / list_providers / analyze_image（默认后端真实调用）。

许可证

MIT

Available Tools

2 tools
analyze_image分析图片A
Read-only

使用视觉大模型分析图片内容。传入本地图片文件路径或 http(s) 图片 URL，可附带问题。可用 provider 参数手动切换识别后端（用 list_providers 查看），可用 model 参数覆盖该后端的默认模型。

ParametersJSON Schema
NameRequiredDescriptionDefault
imageYes本地图片文件路径或 http(s) 图片 URL
modelNo模型名，覆盖所选后端的默认模型
promptNo要模型回答的问题，默认：请详细描述这张图片的内容
providerNo后端 id（如 dashscope / modelscope），不传用默认后端

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=true and destructiveHint=false already covering safety, the description adds useful behavioral details: supported input forms (local path/URL), optional prompt, and provider/model overrides. It does not describe the response format or error behavior, but annotations cover the safety profile.

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 sentences, front-loaded with the core purpose and then compactly covering the optional parameters. No redundant or extraneous information.

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 read-only analysis tool with a complete parameter schema and safety annotations, the description covers the main usage aspects: input source, optional question, and provider/model configuration. It references list_providers for backend selection. A brief note on the output format would improve it, but it is sufficiently complete for an agent to invoke it 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?

All four parameters are fully described in the schema (100% coverage), and the description largely restates the schema's descriptions (e.g., image path/URL, provider switch, model override). It adds a minor reference to list_providers for discovering backend IDs, but no significant new semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes image content using a vision model, specifying the verb and resource. It is clearly distinct from the sibling tool list_providers, which only lists backends.

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 provides clear usage context: pass a local path or URL, optionally with a question, and the ability to switch provider/model. It references list_providers for backend discovery, but does not explicitly state when not to use the tool or enumerate alternatives beyond that.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_providers列出可用识别后端A
Read-only

列出当前配置的所有视觉识别后端（id / 名称 / 模型 / 接口地址），不含密钥。用于手动切换前查看可选后端。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by stating the tool does not return secrets, which is useful for an agent to know before invoking. It does not describe the exact return format, but that is partially covered by the field list.

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?

A single, well-structured sentence that front-loads the action and output, then explains the use case. Every component adds value with zero waste.

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 list operation with no parameters and read-only annotations, the description fully covers what the tool does, what it returns, and when to use it. No additional context is needed.

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 tool has zero parameters, so the baseline is 4. The description adds meaning by explaining what the output contains (id/name/model/endpoint) and what it excludes (secrets), which is helpful beyond the empty 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 clearly states the tool lists all currently configured visual recognition backends with specific fields (id/name/model/endpoint) and explicitly notes it does not include secrets. This distinguishes it from the sibling analyze_image, which is an image-processing 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 use case: view available backends before manually switching. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for a simple listing tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: list_providers shows available backend configurations, while analyze_image performs image analysis. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow the consistent verb_noun pattern: list_providers and analyze_image. This is a predictable and uniform naming convention.

Tool Count4/5

With only 2 tools, the set is minimal but well-suited to the server's focused purpose of image analysis with configurable providers. Each tool serves a distinct and necessary function, so the count feels appropriate rather than thin.

Completeness4/5

The core workflow is covered: list available providers and analyze an image, with the ability to select a provider or model. A minor gap is the lack of provider management operations, but these are typically handled by configuration files rather than MCP tools.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/snow930/reasonix-vision-multi'

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