Enables AI agents to interact with OpenAI's language models through their API, supporting conversation history, model switching, and extended reasoning capabilities for compatible models.
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., "@Polybrain MCP Server ask GPT-4o to explain quantum computing basics"
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.
An MCP (Model Context Protocol) server for connecting AI agents to multiple LLM models. Supports conversation history, model switching, and seamless Claude Code integration.
Multi-model support (OpenAI, OpenRouter, custom endpoints)
Conversation history management
Switch models mid-conversation
Extended thinking/reasoning support (configurable by provider)
Pure MCP protocol (silent by default)
Automatic server management
Related MCP server: LLM Bridge MCP
npm install -g polybrain
# or
pnpm add -g polybrainOption A: YAML (recommended)
Create ~/.polybrain.yaml:
models:
- id: "gpt-4o"
modelName: "gpt-4o"
baseUrl: "https://api.openai.com/v1"
apiKey: "${OPENAI_API_KEY}"
provider: "openai"
- id: "gpt-5.1"
modelName: "openai/gpt-5.1"
baseUrl: "https://openrouter.io/api/v1"
apiKey: "${OPENROUTER_KEY}"
provider: "openrouter"Set env vars:
export OPENAI_API_KEY="sk-..."
export OPENROUTER_KEY="sk-or-..."Option B: Environment variables
export POLYBRAIN_BASE_URL="https://api.openai.com/v1"
export POLYBRAIN_API_KEY="sk-..."
export POLYBRAIN_MODEL_NAME="gpt-4o"Run the following command to add Polybrain to Claude Code:
claude mcp add -s user -t stdio polybrain -- polybrainOpen ~/.codex/config.toml and add:
[mcpServers.polybrain]
command = "polybrain"You can now ask your coding agent to consult specific models. For example:
"Ask deepseek what's the best way to install python on mac"
Or:
"What models are available from polybrain?"
POLYBRAIN_BASE_URL - LLM API base URL
POLYBRAIN_API_KEY - API key
POLYBRAIN_MODEL_NAME - Model name
POLYBRAIN_HTTP_PORT - Server port (default: 32701)
POLYBRAIN_LOG_LEVEL - Log level (default: info)
POLYBRAIN_DEBUG - Enable debug logging to stderr
POLYBRAIN_CONFIG_PATH - Custom config file path
httpPort: 32701 # Optional
truncateLimit: 500 # Optional
logLevel: info # Optional
models: # Required
- id: "model-id" # Internal ID
modelName: "actual-model-name" # API model name
baseUrl: "https://api.url/v1" # API endpoint
apiKey: "key or ${ENV_VAR}" # API key
provider: "openai" # Optional: provider type for reasoning supportThe provider field enables provider-specific features like extended thinking/reasoning. If not specified, reasoning parameters will not be passed to the API (safe default).
Provider | Reasoning Support | Valid Values |
OpenAI | YES |
|
OpenRouter | VARIES |
|
Examples:
Use provider: "openai" for OpenAI API models (GPT-4, o-series)
Use provider: "openrouter" for OpenRouter proxy service (supports 400+ models)
Omit provider field if your endpoint doesn't support reasoning parameters
Example with reasoning:
models:
- id: "gpt-o1"
modelName: "o1"
baseUrl: "https://api.openai.com/v1"
apiKey: "${OPENAI_API_KEY}"
provider: "openai" # Enables reasoning support
- id: "gpt-5.1"
modelName: "openai/gpt-5.1"
baseUrl: "https://openrouter.io/api/v1"
apiKey: "${OPENROUTER_KEY}"
provider: "openrouter" # Enables reasoning supportTo use reasoning, set reasoning: true in the chat tool call. If the model and provider support it, you'll receive both the response and reasoning content.
pnpm installpnpm buildpnpm lint
pnpm formatpnpm type-checkpnpm devsrc/
├── bin/polybrain.ts # CLI entry point
├── launcher.ts # Server launcher & management
├── http-server.ts # HTTP server
├── index.ts # Main server logic
├── mcp-tools.ts # MCP tool definitions
├── conversation-manager.ts
├── openai-client.ts
├── config.ts
├── logger.ts
└── types.tsEnable debug logs to stderr:
{
"mcpServers": {
"polybrain": {
"command": "polybrain",
"env": {
"POLYBRAIN_DEBUG": "true"
}
}
}
}After changing configuration in ~/.polybrain.yaml, restart the HTTP backend server:
polybrain --restartThis kills the background HTTP server. The next time you use polybrain, it will automatically start a fresh server with the updated configuration.
MIT
Send a message to an available LLM for help, second opinions, or brainstorming; start new conversations, continue existing ones, or switch models mid-chat. In the first message you shall provide as much context as possible, since the model has no idea of the problem.
Example workflow:
chat(message: "hello", modelId: "gpt-5-mini") → conversationId: "abc1"
chat(message: "follow-up", conversationId: "abc1") → conversationId: "abc1" (continues)
chat(message: "same question", conversationId: "abc1", modelId: "deepseek-r1") → conversationId: "xyz9" (cloned with new model)
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The question or request to send—be clear and specific. | |
| conversationId | No | ID of the conversation to continue; omit to start a new one. Use the conversationId from prior responses to keep discussing the same topic. | |
| modelId | No | ID of model to use (call list_models); omitted = default model. To switch models, pass a different modelId with your conversationId — you'll get a new conversationId with the conversation cloned to the new model. | |
| reasoning | No | Set true to have the model show its reasoning steps, useful for complex problems. |
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 effectively describes key behaviors: the need to provide context in first messages, conversation persistence via conversationId, model switching capabilities, and cloning behavior when changing models. It doesn't cover rate limits or error handling, but provides substantial 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 appropriately sized and front-loaded with the core purpose, followed by a helpful example workflow. Every sentence adds value, though the example is somewhat lengthy. The structure effectively communicates both the 'what' and 'how' without unnecessary repetition.
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 the tool's moderate complexity (4 parameters, conversation management, model switching) and no annotations or output schema, the description provides substantial context about behavior, usage patterns, and workflow. It could benefit from mentioning response format or error cases, but covers the essential operational aspects well for a chat tool.
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 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema—it mentions providing context in the first message and shows parameter usage in the example workflow, but doesn't significantly enhance understanding of individual parameters beyond what the schema already documents.
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 tool's purpose with specific verbs ('send a message to an available LLM') and resources ('LLM model'), and distinguishes it from sibling tools by focusing on interactive chat rather than listing models or accessing history. It explicitly mentions the core functions: getting help, second opinions, brainstorming, and managing conversations.
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 explicit guidance on when to use this tool vs alternatives: it mentions starting new conversations, continuing existing ones, or switching models mid-chat, and references sibling tools like 'list_models' for model selection. The example workflow demonstrates practical scenarios and transitions between different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See what you've already discussed with a specific model. Useful for understanding context before continuing a conversation, reviewing advice you got, or checking previous responses. Long conversations are automatically shortened to save context.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | The ID of the conversation you want to review. Get this from the response of the chat tool when you first talk to a model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a read-only operation (implied by 'see', 'review', 'check'), it requires a specific conversation ID, and it mentions automatic shortening of long conversations to save context. This covers the essential behavior without contradictions, though it could add more about response format or limitations.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by usage contexts and a behavioral note about automatic shortening. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
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 the tool's moderate complexity (single parameter, read-only operation), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, and a key behavioral trait (automatic shortening). However, it lacks details on output format (e.g., what the review returns) and potential error cases, which would enhance completeness for an agent.
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 input schema has 100% description coverage, with the single parameter 'conversationId' well-documented in the schema. The description doesn't add any additional parameter semantics beyond what's in the schema (e.g., it doesn't explain format examples or validation rules). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 tool's purpose with specific verbs ('see', 'review', 'check') and resources ('what you've already discussed', 'conversation with a specific model'). It distinguishes from sibling tools like 'chat' (which initiates conversations) and 'list_models' (which lists available models) by focusing on reviewing past conversations rather than creating new ones or listing options.
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 clear context for when to use this tool ('useful for understanding context before continuing a conversation, reviewing advice you got, or checking previous responses'), which helps differentiate it from the 'chat' tool for new conversations. However, it doesn't explicitly state when NOT to use it or mention alternatives like checking conversation history through other means, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all the models you can chat with. Each model has different strengths and expertise. Call this first to see which model is best for your question, or to find a specific model ID to use in the chat tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It effectively describes the tool's behavior: retrieving all chat models, noting they have different strengths/expertise, and that the output can inform model selection. It doesn't mention rate limits or error handling, but covers core functionality well.
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?
Two concise sentences front-loaded with the core purpose, followed by usage guidance. Every sentence adds value: the first defines the tool, the second explains when and why to use it, with zero waste.
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 0 parameters, no annotations, and no output schema, the description provides sufficient context for a simple list operation. It explains the tool's role in the workflow and hints at output content (model IDs, strengths). A 5 would require more detail on output structure, but it's complete enough for basic 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds context about the tool's purpose without redundant parameter details, exceeding the baseline of 3 for this scenario.
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 ('Get') and resource ('all the models you can chat with'), specifying it retrieves available chat models. It distinguishes from sibling tools by focusing on model listing rather than chatting or accessing history.
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?
Explicitly states when to use: 'Call this first to see which model is best for your question, or to find a specific model ID to use in the chat tool.' It provides clear alternatives (using the chat tool with a model ID) and timing guidance.
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.
chatconversation_historylist_modelsEach tool has a distinct, non-overlapping purpose: 'chat' handles message sending and conversation management, 'conversation_history' retrieves past discussions, and 'list_models' provides available model options. There is no ambiguity or confusion between their functions.
Two tools follow a clear verb_noun pattern ('list_models', 'conversation_history'), while 'chat' uses a simple noun. This minor deviation is readable and doesn't hinder understanding, but it breaks full consistency.
With 3 tools, the count is reasonable for a chat/LLM interaction server, covering core operations like messaging, history viewing, and model listing. It might benefit from additional tools (e.g., for conversation deletion), but it's well-scoped for its purpose.
The tools provide essential CRUD-like coverage for chat interactions: create/continue conversations, read history, and list models. A minor gap exists in operations like deleting conversations or managing conversation metadata, but agents can work around this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Create and manage AI agents that collaborate and solve problems through natural language interacti…
Chat where AI agents are first-class members, with their own identity and permissions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielwpz/polybrain-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
