MindBridge は AI コマンド ハブであり、LLM ワークフローを統合、整理、強化するために構築されたモデル コンテキスト プロトコル (MCP) サーバーです。
ベンダーロックインは忘れてください。12 個の API を操る必要も忘れてください。
MindBridge は、OpenAI や Anthropic から Ollama や DeepSeek まで、あらゆるモデルにアプリを接続し、専門コンサルタントのチームのように相互に対話できるようにします。
素早いスピードが必要ですか？安価なモデルをお選びください。
複雑な推論が必要ですか？専門家にお任せください。
セカンドオピニオンが必要ですか? MindBridge にはそれが組み込まれています。
これは単なるモデルの集約ではありません。モデルのオーケストレーションです。
何をするのか | なぜ使うべきか |
マルチLLMサポート | OpenAI、Anthropic、Google、DeepSeek、OpenRouter、Ollama (ローカル モデル)、OpenAI 互換 API 間を瞬時に切り替えます。 |
推論エンジン対応 | Claude、GPT-4o、DeepSeek Reasoner などの深層推論用に構築されたモデルへのスマート ルーティング。 |
getSecondOpinionツール | 複数のモデルに同じ質問をして、回答を並べて比較します。 |
OpenAI互換APIレイヤー | OpenAI エンドポイント (Azure、Together.ai、Groq など) を想定した任意のツールに MindBridge を組み込みます。 |
プロバイダーを自動検出 | キーを追加するだけです。MindBridge がセットアップと検出を自動的に処理します。 |
非常に柔軟 | すべてを env vars、MCP config、または JSON 経由で構成します。 |
Related MCP server: MCP AI Router
「すべての LLM は何か得意としています。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
