MindBridge는 LLM 워크플로를 통합, 구성하고 강화하도록 구축된 모델 컨텍스트 프로토콜(MCP) 서버인 AI 명령 허브입니다.
벤더 종속도, 수십 개의 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가 자동으로 설정 및 검색을 처리합니다. |
지옥처럼 유연하다 | 환경 변수, MCP 구성 또는 JSON을 통해 모든 것을 구성하세요. 결정권은 귀하에게 있습니다. |
Related MCP server: MCP AI Router
"모든 LLM은 각자 잘하는 분야가 있습니다. MindBridge는 이들을 함께 활용하게 해줍니다."
다음에 적합합니다:
에이전트 빌더
다중 모델 워크플로
AI 오케스트레이션 엔진
추론이 많은 작업
더욱 스마트한 AI 개발 환경 구축
LLM 기반 백엔드
공급업체로 둘러싸인 정원에 지친 사람이 있나요?
지엑스피1
저장소를 복제합니다.
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
}목록 공급자
구성된 모든 공급자와 사용 가능한 모델을 나열합니다.
매개변수가 필요하지 않습니다
listReasoningModels
추론 작업에 최적화된 모델을 나열합니다.
매개변수가 필요하지 않습니다
// 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 : 프로젝트 빌드
홍보 환영! 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
