MindBridge 是您的 AI 指挥中心——一个模型上下文协议 (MCP) 服务器，旨在统一、组织和增强您的 LLM 工作流程。
忘记供应商锁定。忘记处理十几个 API。
MindBridge 将您的应用程序连接到任何模型，从 OpenAI 和 Anthropic 到 Ollama 和 DeepSeek，并让它们像专家顾问团队一样相互交谈。
需要极致速度？那就买个便宜的型号吧。
需要复杂的推理？请联系专家。
想要听取第二意见？MindBridge 内置了此功能。
这不仅仅是模型聚合，更是模型编排。
它的作用 | 为什么要使用它 |
多LLM支持 | 立即在 OpenAI、Anthropic、Google、DeepSeek、OpenRouter、Ollama（本地模型）和 OpenAI 兼容 API 之间切换。 |
推理引擎感知 | 智能路由到为深度推理而构建的模型，如 Claude、GPT-4o、DeepSeek Reasoner 等。 |
getSecondOpinion 工具 | 向多个模型询问相同的问题，以并排比较答案。 |
OpenAI兼容API层 | 将 MindBridge 放入任何需要 OpenAI 端点的工具中（Azure、Together.ai、Groq 等）。 |
自动检测提供商 | 只需添加您的密钥。MindBridge 会自动处理设置和发现。 |
极其灵活 | 通过环境变量、MCP 配置或 JSON 配置一切 — — 由您决定。 |
Related MCP server: MCP AI Router
“每个法学硕士都有自己擅长的领域。MindBridge 让他们能够协同工作。”
适合：
代理建造者
多模型工作流程
AI编排引擎
推理密集型任务
构建更智能的AI开发环境
LLM 支持的后端
厌倦了供应商围墙花园的人
# Install globally
npm install -g @pinkpixel/mindbridge
# use with npx
npx @pinkpixel/mindbridge克隆存储库：
git clone https://github.com/pinkpixel-dev/mindbridge.git
cd mindbridge安装依赖项：
chmod +x install.sh
./install.sh配置环境变量：
cp .env.example .env编辑.env并为您想要使用的提供商添加 API 密钥。
服务器支持以下环境变量：
OPENAI_API_KEY ：您的 OpenAI API 密钥
ANTHROPIC_API_KEY ：您的 Anthropic API 密钥
DEEPSEEK_API_KEY ：您的 DeepSeek API 密钥
GOOGLE_API_KEY ：您的 Google AI API 密钥
OPENROUTER_API_KEY ：您的 OpenRouter API 密钥
OLLAMA_BASE_URL ：Ollama 实例 URL（默认值： http://localhost:11434 ）
OPENAI_COMPATIBLE_API_KEY ：（可选）OpenAI 兼容服务的 API 密钥
OPENAI_COMPATIBLE_API_BASE_URL ：OpenAI 兼容服务的基本 URL
OPENAI_COMPATIBLE_API_MODELS ：可用模型的逗号分隔列表
为了与 Cursor 或 Windsurf 等 MCP 兼容 IDE 一起使用，您可以在mcp.json文件中使用以下配置：
{
"mcpServers": {
"mindbridge": {
"command": "npx",
"args": [
"-y",
"@pinkpixel/mindbridge"
],
"env": {
"OPENAI_API_KEY": "OPENAI_API_KEY_HERE",
"ANTHROPIC_API_KEY": "ANTHROPIC_API_KEY_HERE",
"GOOGLE_API_KEY": "GOOGLE_API_KEY_HERE",
"DEEPSEEK_API_KEY": "DEEPSEEK_API_KEY_HERE",
"OPENROUTER_API_KEY": "OPENROUTER_API_KEY_HERE"
},
"provider_config": {
"openai": {
"default_model": "gpt-4o"
},
"anthropic": {
"default_model": "claude-3-5-sonnet-20241022"
},
"google": {
"default_model": "gemini-2.0-flash"
},
"deepseek": {
"default_model": "deepseek-chat"
},
"openrouter": {
"default_model": "openai/gpt-4o"
},
"ollama": {
"base_url": "http://localhost:11434",
"default_model": "llama3"
},
"openai_compatible": {
"api_key": "API_KEY_HERE_OR_REMOVE_IF_NOT_NEEDED",
"base_url": "FULL_API_URL_HERE",
"available_models": ["MODEL1", "MODEL2"],
"default_model": "MODEL1"
}
},
"default_params": {
"temperature": 0.7,
"reasoning_effort": "medium"
},
"alwaysAllow": [
"getSecondOpinion",
"listProviders",
"listReasoningModels"
]
}
}
}将 API 密钥替换为您的实际密钥。对于与 OpenAI 兼容的配置，如果服务不需要身份验证，则可以删除api_key字段。
具有自动重新加载的开发模式：
npm run dev生产方式：
npm run build
npm start全局安装时：
mindbridge获取第二意见
{
provider: string; // LLM provider name
model: string; // Model identifier
prompt: string; // Your question or prompt
systemPrompt?: string; // Optional system instructions
temperature?: number; // Response randomness (0-1)
maxTokens?: number; // Maximum response length
reasoning_effort?: 'low' | 'medium' | 'high'; // For reasoning models
}列出提供商
列出所有已配置的提供程序及其可用模型
无需参数
推理模型列表
列出针对推理任务优化的模型
无需参数
// Get an opinion from GPT-4o
{
"provider": "openai",
"model": "gpt-4o",
"prompt": "What are the key considerations for database sharding?",
"temperature": 0.7,
"maxTokens": 1000
}
// Get a reasoned response from OpenAI's o1 model
{
"provider": "openai",
"model": "o1",
"prompt": "Explain the mathematical principles behind database indexing",
"reasoning_effort": "high",
"maxTokens": 4000
}
// Get a reasoned response from DeepSeek
{
"provider": "deepseek",
"model": "deepseek-reasoner",
"prompt": "What are the tradeoffs between microservices and monoliths?",
"reasoning_effort": "high",
"maxTokens": 2000
}
// Use an OpenAI-compatible provider
{
"provider": "openaiCompatible",
"model": "YOUR_MODEL_NAME",
"prompt": "Explain the concept of eventual consistency in distributed systems",
"temperature": 0.5,
"maxTokens": 1500
}npm run lint ：运行 ESLint
npm run format ：使用 Prettier 格式化代码
npm run clean ：清理构建工件
npm run build ：构建项目
欢迎 PR！帮助我们让 AI 工作流程更高效。
MIT——做任何事都行，但不要作恶。
由Pink Pixel用❤️制作
Get responses from various LLM providers
| Name | Required | Description | Default |
|---|---|---|---|
| frequency_penalty | No | ||
| maxTokens | No | ||
| model | Yes | ||
| presence_penalty | No | ||
| prompt | Yes | ||
| provider | Yes | ||
| reasoning_effort | No | ||
| stop_sequences | No | ||
| stream | No | ||
| systemPrompt | No | ||
| temperature | No | ||
| top_k | No | ||
| top_p | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states 'Get responses from various LLM providers' without mentioning any behavioral traits such as whether this is a read-only operation, potential costs, rate limits, authentication needs, error handling, or what the output looks like. For a tool with 13 parameters and no output schema, this leaves critical operational context unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded and directly states the core function. While it lacks detail, it's not verbose or poorly structured—it's appropriately concise for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (13 parameters, no annotations, no output schema), the description is severely incomplete. It doesn't explain what the tool returns, how to interpret parameters, behavioral constraints, or differentiation from siblings. For a multi-provider LLM query tool with rich parameterization, this minimal description fails to provide necessary context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 13 parameters have descriptions in the schema. The tool description provides no information about any parameters—it doesn't mention the required parameters (prompt, provider, model) or optional ones like temperature or maxTokens. With such low coverage and no compensation in the description, an agent has no semantic guidance beyond raw schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get responses from various LLM providers' states a general purpose but lacks specificity about what kind of responses or how it differs from siblings. It mentions 'various LLM providers' which hints at multi-provider capability, but doesn't clearly distinguish from listProviders (which likely lists providers) or listReasoningModels (which likely lists models). The verb 'Get responses' is somewhat vague compared to more precise alternatives like 'Generate completions' or 'Query LLMs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (listProviders, listReasoningModels). The description doesn't mention prerequisites, alternatives, or specific contexts for usage. It's implied this is for generating LLM responses, but without explicit boundaries or comparisons to other tools, an agent might struggle to choose appropriately between querying and listing functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured LLM providers and their available models
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior (listing providers and models) but doesn't mention important traits like whether this requires authentication, rate limits, pagination behavior, or what format the output takes. The description is accurate but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema, the description provides the core purpose but lacks information about output format, authentication requirements, or error conditions. While adequate for basic understanding, it doesn't fully prepare an agent for operational use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the empty parameter set. The description appropriately doesn't add parameter information beyond what's already covered, maintaining the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all configured LLM providers and their available models') with precise verb+resource combination. It distinguishes from sibling tools like 'getSecondOpinion' and 'listReasoningModels' by focusing on provider configuration rather than reasoning models or second opinions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need to see configured providers and models) but doesn't explicitly state when to use this tool versus alternatives like 'listReasoningModels'. No explicit exclusions or prerequisites are mentioned, leaving usage guidance at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available models that support reasoning capabilities
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves - no information about pagination, rate limits, authentication needs, return format, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no output schema, the description provides the basic purpose but lacks important context. Without annotations or output schema, the description should ideally mention what information is returned about each model, but it doesn't. It's minimally adequate but leaves the agent guessing about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. This meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available models that support reasoning capabilities'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'listProviders' or 'getSecondOpinion', but the focus on 'reasoning capabilities' provides some distinction. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'listProviders' or 'getSecondOpinion'. There's no mention of prerequisites, context, or exclusions. The agent must infer usage based solely on the tool name and description without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0getSecondOpinionlistProviderslistReasoningModelsEach tool has a clearly distinct purpose: getSecondOpinion retrieves LLM responses, listProviders shows configured providers and models, and listReasoningModels specifically lists models with reasoning capabilities. There is no overlap in functionality, making tool selection unambiguous.
The naming is mostly consistent with a verb_noun pattern (getSecondOpinion, listProviders, listReasoningModels), but getSecondOpinion uses camelCase while the others use a more descriptive phrase-based style. This minor deviation slightly affects consistency.
With only 3 tools, the server feels thin for a domain involving LLM interactions, as it lacks operations like configuring providers, managing models, or performing other common tasks. However, the tools cover basic listing and querying functions, making it borderline appropriate.
The toolset is significantly incomplete for an LLM interaction server. It lacks core operations such as adding or removing providers, configuring models, or performing advanced queries beyond getSecondOpinion. This will likely cause agent failures when trying to manage or customize the LLM setup.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI model routing on your own vendor keys: pick the best model per prompt, or route and run it.
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
Enterprise AI Control Plane: governance, guardrails, spend tracking, compliance & smart routing.
run any ai model. compose agents, stack knowledge, connect tools. one api, pay per run.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pinkpixel-dev/mindbridge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
