MindBridge es su centro de comando de IA: un servidor de Protocolo de Contexto de Modelo (MCP) creado para unificar, organizar y potenciar sus flujos de trabajo de LLM.
Olvídate de la dependencia de un proveedor. Olvídate de tener que lidiar con una docena de API.
MindBridge conecta sus aplicaciones a cualquier modelo, desde OpenAI y Anthropic hasta Ollama y DeepSeek, y les permite comunicarse entre sí como un equipo de consultores expertos.
¿Necesitas velocidad pura? Consigue un modelo económico.
¿Necesitas un razonamiento complejo? Dirígelo a un especialista.
¿Quieres una segunda opinión? MindBridge la tiene integrada.
Esto no es solo agregación de modelos. Es orquestación de modelos.
Qué hace | ¿Por qué deberías usarlo? |
Soporte para múltiples LLM | Cambie instantáneamente entre OpenAI, Anthropic, Google, DeepSeek, OpenRouter, Ollama (modelos locales) y API compatibles con OpenAI. |
Motor de razonamiento consciente | Enrutamiento inteligente a modelos creados para razonamiento profundo como Claude, GPT-4o, DeepSeek Reasoner, etc. |
Herramienta getSecondOpinion | Haga la misma pregunta a varios modelos para comparar las respuestas. |
Capa API compatible con OpenAI | Instale MindBridge en cualquier herramienta que espere puntos finales OpenAI (Azure, Together.ai, Groq, etc.). |
Detecta automáticamente a los proveedores | Solo agrega tus claves. MindBridge gestiona la configuración y el descubrimiento automáticamente. |
Flexible como el infierno | Configure todo a través de variables de entorno, configuración MCP o JSON: usted decide. |
Related MCP server: MCP AI Router
Cada LLM es bueno en algo. MindBridge los ayuda a trabajar juntos.
Perfecto para:
Constructores de agentes
Flujos de trabajo multimodelo
Motores de orquestación de IA
Tareas que requieren mucho razonamiento
Construyendo entornos de desarrollo de IA más inteligentes
Backends impulsados por LLM
¿Alguien está cansado de los jardines amurallados de los vendedores?
# Install globally
npm install -g @pinkpixel/mindbridge
# use with npx
npx @pinkpixel/mindbridgeClonar el repositorio:
git clone https://github.com/pinkpixel-dev/mindbridge.git
cd mindbridgeInstalar dependencias:
chmod +x install.sh
./install.shConfigurar variables de entorno:
cp .env.example .envEdite .env y agregue sus claves API para los proveedores que desee utilizar.
El servidor admite las siguientes variables de entorno:
OPENAI_API_KEY : Su clave API de OpenAI
ANTHROPIC_API_KEY : Su clave de API antrópica
DEEPSEEK_API_KEY : Su clave API de DeepSeek
GOOGLE_API_KEY : Su clave de API de Google AI
OPENROUTER_API_KEY : Su clave API de OpenRouter
OLLAMA_BASE_URL : URL de la instancia de Ollama (predeterminado: http://localhost:11434 )
OPENAI_COMPATIBLE_API_KEY : (Opcional) Clave API para servicios compatibles con OpenAI
OPENAI_COMPATIBLE_API_BASE_URL : URL base para servicios compatibles con OpenAI
OPENAI_COMPATIBLE_API_MODELS : Lista separada por comas de modelos disponibles
Para usar con IDE compatibles con MCP como Cursor o Windsurf, puede usar la siguiente configuración en su archivo 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"
]
}
}
}Reemplace las claves API con sus claves reales. Para la configuración compatible con OpenAI, puede eliminar el campo api_key si el servicio no requiere autenticación.
Modo de desarrollo con recarga automática:
npm run devModo de producción:
npm run build
npm startCuando se instala globalmente:
mindbridgeobtenerSegundaOpinión
{
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
}lista de proveedores
Enumera todos los proveedores configurados y sus modelos disponibles
No se requieren parámetros
listaReasoningModels
Enumera modelos optimizados para tareas de razonamiento
No se requieren parámetros
// 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 : Ejecutar ESLint
npm run format : Formatear código con Prettier
npm run clean : Limpiar artefactos de compilación
npm run build : Construye el proyecto
¡Bienvenidos los PR! Ayúdennos a hacer que los flujos de trabajo de IA sean menos tontos.
MIT: haz lo que quieras, pero no seas malvado.
Hecho con ❤️ por 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
