The MindBridge MCP Server is an AI router for orchestrating multi-LLM workflows with these key capabilities:
Multi-LLM Support: Connect to OpenAI, Anthropic, Google, DeepSeek, OpenRouter, Ollama, and OpenAI-compatible APIs
Smart Routing: Direct tasks to models optimized for specific needs (speed, reasoning)
getSecondOpinion Tool: Compare responses from multiple models side-by-side with configurable parameters
OpenAI-Compatible API Layer: Seamlessly integrate with tools expecting OpenAI endpoints
Dynamic Configuration: Manage providers via environment variables, MCP config, or JSON
Developer Tools: List providers (listProviders) and reasoning-optimized models (listReasoningModels)
Auto-Detection: Automatically detect providers based on provided API keys
Ease of Setup: Start the server with npm, npx, or globally installed commands
Supports configuration through environment variables for API keys and provider settings.
Enables access to Google AI models like Gemini, with configurable parameters and integration with the overall model orchestration system.
Available as an npm package for easy installation and integration into existing projects.
Supports local models through Ollama, allowing integration with locally hosted LLMs alongside cloud-based options.
Provides access to OpenAI models like GPT-4o, with support for model switching and routing based on reasoning requirements.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MindBridge MCP Server get a second opinion on this code review from Claude and GPT-4o"
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.
MindBridge is your AI command hub — a Model Context Protocol (MCP) server built to unify, organize, and supercharge your LLM workflows.
Forget vendor lock-in. Forget juggling a dozen APIs.
MindBridge connects your apps to any model, from OpenAI and Anthropic to Ollama and DeepSeek — and lets them talk to each other like a team of expert consultants.
Need raw speed? Grab a cheap model.
Need complex reasoning? Route it to a specialist.
Want a second opinion? MindBridge has that built in.
This isn't just model aggregation. It's model orchestration.
What it does | Why you should use it |
Multi-LLM Support | Instantly switch between OpenAI, Anthropic, Google, DeepSeek, OpenRouter, Ollama (local models), and OpenAI-compatible APIs. |
Reasoning Engine Aware | Smart routing to models built for deep reasoning like Claude, GPT-4o, DeepSeek Reasoner, etc. |
getSecondOpinion Tool | Ask multiple models the same question to compare responses side-by-side. |
OpenAI-Compatible API Layer | Drop MindBridge into any tool expecting OpenAI endpoints (Azure, Together.ai, Groq, etc.). |
Auto-Detects Providers | Just add your keys. MindBridge handles setup & discovery automagically. |
Flexible as Hell | Configure everything via env vars, MCP config, or JSON — it's your call. |
Related MCP server: MCP AI Router
"Every LLM is good at something. MindBridge makes them work together."
Perfect for:
Agent builders
Multi-model workflows
AI orchestration engines
Reasoning-heavy tasks
Building smarter AI dev environments
LLM-powered backends
Anyone tired of vendor walled gardens
# Install globally
npm install -g @pinkpixel/mindbridge
# use with npx
npx @pinkpixel/mindbridgeTo install mindbridge-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @pinkpixel-dev/mindbridge-mcp --client claudeClone the repository:
git clone https://github.com/pinkpixel-dev/mindbridge.git
cd mindbridgeInstall dependencies:
chmod +x install.sh
./install.shConfigure environment variables:
cp .env.example .envEdit .env and add your API keys for the providers you want to use.
The server supports the following environment variables:
OPENAI_API_KEY: Your OpenAI API key
ANTHROPIC_API_KEY: Your Anthropic API key
DEEPSEEK_API_KEY: Your DeepSeek API key
GOOGLE_API_KEY: Your Google AI API key
OPENROUTER_API_KEY: Your OpenRouter API key
OLLAMA_BASE_URL: Ollama instance URL (default: http://localhost:11434)
OPENAI_COMPATIBLE_API_KEY: (Optional) API key for OpenAI-compatible services
OPENAI_COMPATIBLE_API_BASE_URL: Base URL for OpenAI-compatible services
OPENAI_COMPATIBLE_API_MODELS: Comma-separated list of available models
For use with MCP-compatible IDEs like Cursor or Windsurf, you can use the following configuration in your mcp.json file:
{
"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"
]
}
}
}Replace the API keys with your actual keys. For the OpenAI-compatible configuration, you can remove the api_key field if the service doesn't require authentication.
Development mode with auto-reload:
npm run devProduction mode:
npm run build
npm startWhen installed globally:
mindbridgegetSecondOpinion
{
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
}listProviders
Lists all configured providers and their available models
No parameters required
listReasoningModels
Lists models optimized for reasoning tasks
No parameters required
// 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: Run ESLint
npm run format: Format code with Prettier
npm run clean: Clean build artifacts
npm run build: Build the project
PRs welcome! Help us make AI workflows less dumb.
MIT — do whatever, just don't be evil.
Made with ❤️ by 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
