How do I use cn-llm-bridge?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cn-llm-bridge 分析这张图片中的文字" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

cn-llm-bridge

by maxliven

Overview Schema Related Servers Score Discussions

Python

Hybrid

cn-llm-bridge

Python 3.10+ License: MIT MCP

MCP Bridge：本地 Qwen 视觉 + faster-whisper 转写，以及 Kimi K3 深度合成。

这是什么？

cn-llm-bridge 是一组 MCP（Model Context Protocol）服务器，把国产大模型的能力接入 Claude Code。

graph LR
    Client[MCP Client / Claude Code] --> CB[cn_llm_bridge]
    Client --> KB[kimi_bridge]
    CB --> Qwen[Qwen3.7-Plus<br/>视觉理解]
    CB --> Whisper[faster-whisper<br/>本地转写]
    CB --> QwenASR[qwen3-asr-flash<br/>云端转写]
    KB --> Kimi[Kimi K3<br/>深度合成]

模块

模块	能力	本地/远程	适用场景
`cn_llm_bridge`	视觉理解 + 语音转写	混合（视觉远程，转写本地兜底）	截图分析、OCR、录音转文字
`kimi_bridge`	深度推理 + 跨模态合成	远程 API	长文本分析、多源综合、代码生成

主推理模型随你选——Claude 官方、DeepSeek 或任何 OpenAI 兼容模型都可以。cn-llm-bridge 只负责多模态扩展，不绑定主模型。
模型版本随厂商更新：所有模型 ID 通过环境变量配置，百炼或 Kimi 发新模型时改一行 .env 即可切换，无需改代码。

核心理念：Claude Code 只调度，不做出力活。 它负责 orchestration——读需求、派任务、审结果。真正跑推理的那一层，交给最合适的模型。

Related MCP server: Kimi MCP Server

快速开始

1. 安装

git clone https://github.com/maxliven/cn-llm-bridge.git
cd cn-llm-bridge
pip install -e .

2. 获取 API Key

阿里百炼（必填 — 视觉 + 云端转写）：bailian.console.aliyun.com
Kimi（可选 — 深度合成）：platform.moonshot.cn

3. 配置 Claude Code

在 ~/.claude/mcp.json 中添加：

{
  "mcpServers": {
    "cn-llm-bridge": {
      "command": "python",
      "args": ["-m", "cn_llm_bridge.server"],
      "env": {
        "QWEN_API_KEY": "sk-your-key-here",
        "BAILIAN_BASE_URL": "https://dashscope.aliyuncs.com/compatible-mode/v1"
      }
    },
    "kimi-bridge": {
      "command": "python",
      "args": ["-m", "kimi_bridge.server"],
      "env": {
        "KIMI_API_KEY": "sk-your-key-here",
        "KIMI_BASE_URL": "https://api.moonshot.cn/v1"
      }
    }
  }
}

重启 Claude Code，问它「你能看到什么 MCP 工具？」——会列出 vision_analyze、audio_transcribe、kimi_chat 等。

4. 开始用

在 Claude Code 中直接说人话：

「分析这张截图」→ 自动调用 vision_analyze
「把这段录音转成文字」→ 自动调用 audio_transcribe
「对比这三张设计稿的变化」→ 先逐张 vision_analyze，再 kimi_synthesize 综合

💡 切换模型版本：所有模型 ID 都支持环境变量覆盖。百炼发新模型时，改一行配置即可——无需改代码。见 .env.example。

可用工具

工具	用途	模型
`vision_analyze`	图片分析，返回结构化 JSON	Qwen3.7-Plus
`vision_chat`	多轮视觉对话	Qwen3.7-Plus
`audio_transcribe`	音频转文字	qwen3-asr-flash → faster-whisper（兜底）
`kimi_chat`	深度推理、长文本分析	Kimi K3
`kimi_synthesize`	多源综合、跨模态合成	Kimi K3
`tools_health` / `kimi_health`	检查模型状态	—

设计原则

原则一：Generator ≠ Evaluator

写作业和批作业的不能是同一个人。 同一个模型审查自己的输出时有严重确认偏误——生成时走错路，审查时大概率走同一条路，然后告诉你"没问题"。

Claude Code 只调度和审查，推理交给独立模型。两个模型的思考路径彼此独立，一个的盲点被另一个照亮。

原则二：结构化输出 >> 自由文本

让子模型返回 JSON，主模型只读关键字段。一个 summary: "登录按钮错位" 是 15 个 token，让主模型自己理解整张截图可能要 500 个。

vision_analyze 返回结构化 JSON（summary、details、text_found、objects），主模型只需读字段做决策。

原则三：参数按场景差异化

OCR 用高清，场景描述低分辨率就够。_infer_detail_level 根据 prompt 内容自动推断——你的提问里有「文字」「识别」「OCR」就自动切高清。

原则四：透传层格式约束

模型有时返回「带 markdown 包裹的 JSON」——直接解析会炸。_ensure_json 自动剥离、修复。格式错误最大的成本不是报错，是排查报错浪费的时间。

工程决策

复杂度自评估

vision_analyze 让模型自己评估任务复杂度（simple / medium / complex），自动控制 details 字段长度。过滤掉 80% 的低信息密度输出。

自适应 max_tokens

任务类型	max_tokens	示例
搜索/列举/格式化	300–500	列出页面按钮
分类/匹配/检查	500–800	判断截图有无报错
分析/总结/提取	800–1200	总结扫描件要点
生成/写作/翻译	1200–2000	基于数据写分析

单次重试

遇到 5xx 等 1.5 秒重试一次——就一次。过度重试是用更多请求撞同一堵墙。

项目结构

cn-llm-bridge/
├── README.md
├── LICENSE
├── pyproject.toml
├── .env.example
├── .gitignore
├── cn_llm_bridge/          # cn-llm-bridge MCP server
│   ├── __init__.py
│   └── server.py
├── kimi_bridge/            # kimi-bridge MCP server
│   ├── __init__.py
│   └── server.py
└── tests/                  # pytest 测试（CI 自动运行）

依赖

Python ≥ 3.10
mcp — MCP 协议 SDK
httpx — 异步 HTTP 客户端
faster-whisper — 本地音频转写（可选，CPU 就能跑）

常见问题

需要 GPU 吗？ 不需要。faster-whisper 用 INT8 量化，CPU 足够。视觉和深度合成都走云端 API。

支持哪些音频格式？ m4a、mp3、wav、ogg、flac 等。云端转写是主路径，本地 faster-whisper 是兜底。

和直接用 Claude 官方多模态有什么区别？ Claude 官方多模态是最好的选择——如果你能稳定使用。cn-llm-bridge 解决的是另一个问题：模型多样性 + 稳定可控。

License

AI 能力不是越强越好，是越「对」越好。

Ecosystem

cc-skill-router — Skill routing system for Claude Code. Register cn-llm-bridge tools as skills for automatic routing.

🌐 Part of the maxliven AI tooling ecosystem: cc-skill-router · cn-llm-bridge

Available Tools

4 tools

audio_transcribeA

Read-onlyIdempotent

本地音频转写。使用 faster-whisper small 模型（CPU-only，INT8 量化）将音频文件转为文字。支持 m4a/mp3/wav/ogg/flac 等常见格式。返回分段文本和全文。

ParametersJSON Schema

Name	Required	Description
`task`	No	transcribe（原语言输出，默认）或 translate（翻译为英文）
`language`	No	语言代码（如 'zh' 中文, 'en' 英文），不指定则自动检测
`file_path`	Yes	音频文件的绝对路径，如 D:\recordings\interview.m4a

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable contextual details: it uses faster-whisper small model with CPU-only INT8 quantization, and it returns segmented text and full text. This gives the agent a richer understanding of performance and output characteristics 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of three focused sentences. It front-loads the core purpose, then adds model details, supported formats, and output type, with no unnecessary words. Every sentence adds meaningful info.

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?

Moderate complexity tool with no output schema, but the description explains what is returned (segmented text and full text). It covers supported formats and the CPU-only constraint. It doesn't mention error handling, file size limits, or prerequisites, but for a read-only transcription tool, these are less critical. Overall, it's sufficiently complete for an agent to select and invoke it.

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 (file_path, task, language). The description does not add additional parameter semantics—it only mentions supported formats and output, which are not directly tied to parameter usage. Thus, 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's function: '本地音频转写' (local audio transcription) using a specific model. It distinguishes from sibling tools (vision_analyze, vision_chat, tools_health) by focusing on audio-to-text conversion, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context that this is for transcribing local audio files, listing supported formats and model constraints. It doesn't explicitly mention alternatives or when-not-to-use, but the sibling tools are visually/health-oriented, so the usage context is clear enough without exclusions.

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

tools_healthA

Read-onlyIdempotent

检查所有模型 API 的可用状态。返回各模型是否就绪。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the specific behavior of checking all model APIs and returning readiness, but does not go beyond that to mention potential side effects, requirements, or response details.

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 succinct sentence that fully conveys the tool's purpose and return value. No wasted words.

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 health check tool with no output schema, the description is sufficient. It states what it does and what it returns. Slight room to mention interpretation of results (e.g., what 'ready' means) but not necessary given the annotations.

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 no parameters, so there is nothing for the description to explain. The baseline for zero parameters is 4, and the description does not need to add parameter-level detail.

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 checks the availability status of all model APIs and returns readiness. The verb 'check' plus resource 'all model APIs' is specific and distinguishes it from siblings like vision_analyze, vision_chat, and audio_transcribe.

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: this is a health check tool, so it would be used to verify model availability before other operations. However, the description does not explicitly state when to use it or provide exclusions or alternative guidance.

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

vision_analyzeA

Read-onlyIdempotent

分析图像内容。支持 URL 或 base64 编码的图像。返回结构化 JSON（含摘要、文字、物体列表）。适合一次性图像分析。

ParametersJSON Schema

Name	Required	Description
`detail`	No	细节级别，默认 auto（会根据 prompt 自动推断）
`prompt`	Yes	对图像的提问或描述指令，如「描述这张图」
`image_url`	No	图像的公开 URL（与 image_data 二选一）
`image_data`	No	base64 编码的图像数据（兼容带 data:image/xxx;base64, 前缀，与 image_url 二选一）

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds that it accepts URL or base64 images and returns structured JSON with summary, text, and object list, which is useful behavioral context beyond 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 is compact at three short sentences. Each sentence provides distinct information: what it does, input support, output format, and when to use it, with no wasted words.

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 the tool's core inputs and outputs, and annotations supply safety context. While no output schema exists, the return format is summarized. It lacks some edge-case details but is sufficient for a simple, low-risk 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 all four parameters with 100% description coverage. The tool description repeats that URL and base64 are supported (image_url/image_data) but adds no extra semantic detail beyond what the schema provides, so the baseline 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 the tool's function: analyzing image content. It specifies the resource (images) and action (analyze), and distinguishes itself from sibling tools like vision_chat and audio_transcribe by noting its structured JSON output and one-time analysis nature.

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 notes that it is suitable for one-time image analysis, giving clear usage context. It does not explicitly exclude multi-turn conversations or name alternative tools, but the one-time framing implies a boundary against vision_chat.

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

vision_chatA

Read-onlyIdempotent

多模态对话。支持含图片的多轮对话，自动简洁回复。如果需要一次性结构化分析（JSON 格式输出），请用 vision_analyze。

ParametersJSON Schema

Name	Required	Description	Default
`messages`	Yes	对话消息列表。content 支持纯文本字符串或图文数组

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent hints. The description adds that replies are automatically concise and supports multi-turn with images, giving useful behavioral context beyond 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?

Two concise sentences: first states the core purpose, second differentiates from the sibling. No wasted words.

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 single-parameter tool with strong annotations and schema, the description covers purpose, distinguishes from sibling, and notes reply style. It could mention response format, but absence of an output schema makes this acceptable.

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 only parameter 'messages' is fully documented in the schema (100% coverage). The description does not add further parameter-level detail, so the baseline 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?

Description clearly states it is a multimodal conversation tool supporting multi-turn chat with images. It explicitly distinguishes from the sibling vision_analyze by directing users to that tool for structured JSON analysis.

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 explicit guidance by naming vision_analyze as the alternative for structured analysis, implying vision_chat is for conversational use. The context is clear, though it does not list exhaustive when-not-to-use scenarios.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv1.0.0Aug 1, 2026
- First observedaudio_transcribe
- First observedtools_health
- First observedvision_analyze
- First observedvision_chat

Install Server

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

TDQS

A4/5.0

Disambiguation4/5

vision_analyze and vision_chat both handle images, but they are clearly differentiated by purpose: one for one-time structured analysis, the other for multi-turn conversation. audio_transcribe and tools_health serve distinct functions, leaving minimal ambiguity.

Naming Consistency3/5

The naming pattern is inconsistent across tools: vision_analyze and vision_chat share a vision_ prefix, audio_transcribe uses audio_, and tools_health uses tools_. While each is readable, there is no uniform verb-noun convention across the set.

Tool Count4/5

With 4 tools, the server is well-scoped for a multimodal bridge covering vision analysis, vision chat, audio transcription, and health checks. The count feels appropriate and not excessive for the apparent purpose.

Completeness4/5

The tool set covers key multimodal operations: image analysis, image conversation, audio transcription, and system health. Minor gaps exist, such as a text-only chat tool, but the core functionality for a vision/audio bridge is present.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Writingmate MCPOAuth
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1
toolweaveOAuth
io.github.andreysparish
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
App Automation AI & Machine Learning Agent Orchestration
2
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72

Related MCP Servers

mimo-mcp
AI & Machine Learning Speech Processing Image & Video Processing
Frank-ay
A
license
B
quality
B
maintenance
Enables Claude Code and Codex to directly invoke Xiaomi MiMo's full-modal capabilities including multimodal dialogue, image/video understanding, TTS, voice cloning, and ASR through MCP tools.
Updated 2 months ago (2026-06-28 12:10 UTC)
11
30
MIT
Kimi MCP Server
Developer Tools Code Analysis
MichaelCecil
A
license
Not graded
quality
D
maintenance
An MCP bridge that enables Claude Code to consult the Kimi AI model in a structured challenge-loop for code review, debugging, and architecture evaluation.
Updated 5 months ago (2026-04-11 03:52 UTC)
37
2
MIT
ccg-mcp
AI & Machine Learning Code Execution
Erenshkigal111
A
license
Not graded
quality
C
maintenance
Enables Claude Code Desktop to call OpenAI Codex/GPT-5 and Gemini APIs via stdio MCP, without requiring local CLI tools.
Updated 2 months ago (2026-06-28 08:40 UTC)
MIT
Doubao Vision MCP Server
AI & Machine Learning Image & Video Processing
dehuadong
F
license
A
quality
B
maintenance
MCP server integrating Doubao vision models, enabling Claude Code to recognize images from local files or URLs with customizable prompts.
Updated 2 months ago (2026-07-07 02:40 UTC)
1
1
-

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/maxliven/cn-llm-bridge'

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