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., "@Cerebras Multi-Model MCP Server write a quick sort algorithm using cerebras_reasoning"
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.
Use multiple Cerebras models from Claude Desktop & Claude Code — with automatic model selection.
The official Cerebras MCP package only supports one model per session — you pick a model via an environment variable, and you're stuck with it until you restart. Want to use the fast 8B model for boilerplate and the 357B model for complex reasoning? You'd need two separate MCP server configs.
Related MCP server: Zen MCP Server
cerebras-multi-mcp exposes 5 tools — one for each Cerebras model plus an auto-selector — so you (or Claude) can pick the right model per task, in the same session, with zero restarts.
┌─────────────────────────────────────────────────┐
│ Claude Desktop / Code │
├─────────────────────────────────────────────────┤
│ │
│ cerebras_quick → llama3.1-8b (8B) │
│ cerebras_complex → gpt-oss-120b (120B) │
│ cerebras_reasoning → zai-glm-4.7 (357B) │
│ cerebras_instruct → qwen-3-235b (235B) │
│ cerebras_auto → picks the best one │
│ │
├─────────────────────────────────────────────────┤
│ Cerebras API ←→ OpenRouter Fallback │
└─────────────────────────────────────────────────┘Tool | Model | Params | Best For |
| llama3.1-8b | 8B | Simple edits, boilerplate, single functions. Fastest. |
| gpt-oss-120b | 120B | Multi-file features, CRUD APIs, complex components. |
| zai-glm-4.7 | 357B | Algorithms, architecture, advanced logic, deep reasoning. |
| qwen-3-235b | 235B | Precise instructions, documentation, typed interfaces, specs. |
| auto-selected | — | Analyzes your prompt and picks the best model automatically. |
cerebras_auto analyzes your prompt keywords and complexity:
Reasoning keywords (algorithm, optimize, recursive, big-o…) → 357B
Instruct keywords (document, jsdoc, schema, openapi…) → 235B
Complex keywords (crud, rest api, multi-file, database…) → 120B
Everything else or short prompts → 8B (fastest)
Node.js 18+
A Cerebras API key (free tier available)
(Optional) An OpenRouter API key for fallback
git clone https://github.com/khansabassem/cerebras-multi-mcp.git
cd cerebras-multi-mcp
npm installEdit your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the cerebras-multi entry:
{
"mcpServers": {
"cerebras-multi": {
"command": "node",
"args": ["<path-to>/cerebras-multi-mcp/src/index.js"],
"env": {
"CEREBRAS_API_KEY": "your-cerebras-api-key",
"OPENROUTER_API_KEY": "your-openrouter-api-key"
}
}
}
}Restart Claude Desktop to load the new server.
claude mcp add cerebras-multi \
-e CEREBRAS_API_KEY=your-cerebras-api-key \
-e OPENROUTER_API_KEY=your-openrouter-api-key \
-- node /path/to/cerebras-multi-mcp/src/index.jsOnce configured, you'll see 5 new tools in Claude. Each tool accepts:
Parameter | Required | Description |
| Yes | Absolute path to the file to create or modify |
| Yes | Detailed code generation instructions |
| No | Array of file paths to read as context |
| No | Sampling temperature (default: 0.1) |
| No | Maximum tokens in the response |
Quick boilerplate with the 8B model:
Tool: cerebras_quick
file_path: /project/src/server.js
prompt: Create an Express server with health check endpoint on port 3000Complex feature with the 120B model:
Tool: cerebras_complex
file_path: /project/src/auth/middleware.ts
prompt: Create JWT authentication middleware with refresh token rotation
context_files: ["/project/src/types/auth.ts", "/project/src/config/env.ts"]Algorithm design with the 357B model:
Tool: cerebras_reasoning
file_path: /project/src/utils/graph.ts
prompt: Implement Dijkstra's shortest path with a priority queue, supporting weighted directed graphsDocumentation with the 235B model:
Tool: cerebras_instruct
file_path: /project/src/types/api.ts
prompt: Generate TypeScript interfaces for a REST API with OpenAPI-compatible JSDoc annotationsLet the server decide:
Tool: cerebras_auto
file_path: /project/src/cache.ts
prompt: Build an LRU cache with O(1) get and put using a doubly linked listPer-call model selection — no restarts, no env var juggling
Auto-select mode — keyword analysis picks the right model for you
OpenRouter fallback — if Cerebras is unavailable, requests fall through to OpenRouter
Smart file handling — reads existing files for context when editing, creates directories as needed
Diff summaries — shows additions/removals when updating existing files
Code cleaning — strips markdown fences from model output automatically
Context files — pass related files for cross-file awareness
src/index.js — Single-file MCP server (~350 lines)
├── Config — Model definitions, keyword lists, language detection
├── File helpers — Safe read/write with path resolution
├── HTTP layer — Cerebras API + OpenRouter fallback
├── Auto-selector — Keyword-based model routing
├── Tool handler — Unified handler for all 5 tools
└── MCP server — ListTools + CallTool with schema factoryBuilt with @modelcontextprotocol/sdk using stdio transport.
Cerebras inference runs on purpose-built wafer-scale hardware, delivering up to 20x faster inference than traditional GPU setups. Combined with MCP, you get near-instant code generation directly inside Claude.
Bassem EL KHANSAA — @ask.bassem
MIT
Issues and PRs welcome. If you add a new model, just extend the MODELS object and add a tool entry in the ListToolsRequestSchema handler.
Auto-selects the best Cerebras model based on prompt complexity. Simple tasks use 8B, complex features use 120B, reasoning tasks use 357B, documentation tasks use 235B. Use this when unsure which model fits.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | REQUIRED: Detailed code generation instructions. Include method signatures, data structures, error handling requirements, and integration details. | |
| file_path | Yes | REQUIRED: Absolute path to the file to create or modify. | |
| max_tokens | No | OPTIONAL: Maximum tokens in the response. | |
| temperature | No | OPTIONAL: Sampling temperature (default 0.1). | |
| context_files | No | OPTIONAL: Array of file paths to read as context for the generation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the model selection logic (8B, 120B, 357B, 235B based on task type), which adds transparency. However, it does not mention potential side effects or output characteristics.
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 two sentences, front-loaded with the core auto-selection feature, and contains no redundant information.
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?
The description explains the purpose and selection logic well, but lacks information about return values or error handling. Given the moderate complexity (5 params, no output schema), it is adequate but not complete.
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 coverage is 100%, so the description adds minimal value beyond the schema. The description mentions 'code generation instructions' but does not provide additional meaning beyond the parameter descriptions.
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 auto-selects the best Cerebras model based on prompt complexity, and it distinguishes from sibling tools by explaining the selection strategy (simple->8B, complex->120B, etc.).
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 explicitly advises to use this tool when unsure which model fits, providing clear context. It does not explicitly list when not to use it, but the sibling tool names imply alternatives for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heavy-duty code generation using Cerebras gpt-oss-120b (120B params). Large model for multi-file features, CRUD APIs, complex components, and demanding code generation tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | REQUIRED: Detailed code generation instructions. Include method signatures, data structures, error handling requirements, and integration details. | |
| file_path | Yes | REQUIRED: Absolute path to the file to create or modify. | |
| max_tokens | No | OPTIONAL: Maximum tokens in the response. | |
| temperature | No | OPTIONAL: Sampling temperature (default 0.1). | |
| context_files | No | OPTIONAL: Array of file paths to read as context for the generation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavioral traits. It mentions the model size and intended use but does not disclose potential trade-offs like speed, cost, or limitations. Lacks detail on side effects or return behavior.
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 that communicate the essential purpose and scope. Could be slightly more structured but appropriate for the length.
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?
No output schema, so description should clarify return values or side effects. It implies output is written to file_path but doesn't explicitly state. Lacks completeness for a tool with 5 parameters and no annotations.
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 coverage is 100%, so parameters are documented. Description adds guidance for the prompt parameter but does not enhance understanding of other parameters beyond what the schema provides.
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?
Description clearly states it is for heavy-duty code generation using Cerebras gpt-oss-120b, with specific use cases like multi-file features, CRUD APIs, and complex components. However, it does not explicitly differentiate from siblings beyond implying heavier tasks.
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 explicit guidance on when to use this tool versus alternatives like cerebras_quick or cerebras_auto. The description implies it's for complex tasks but does not state when not to use it or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instruction-following code generation using Cerebras zai-glm-4.7 (355B params, reasoning_format:hidden). Instruction-tuned model for precise instruction following, documentation-heavy code, typed interfaces, and detailed specs.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | REQUIRED: Detailed code generation instructions. Include method signatures, data structures, error handling requirements, and integration details. | |
| file_path | Yes | REQUIRED: Absolute path to the file to create or modify. | |
| max_tokens | No | OPTIONAL: Maximum tokens in the response. | |
| temperature | No | OPTIONAL: Sampling temperature (default 0.1). | |
| context_files | No | OPTIONAL: Array of file paths to read as context for the generation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions model size and hidden reasoning format but fails to cover key behaviors like rate limits, error handling, file creation/modification behavior, or response format. This is minimal disclosure for a code generation tool.
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 sentences are concise and front-loaded with the core purpose. No unnecessary words. However, it could be slightly more structured by separating model info from usage guidance.
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 complexity of a code generation tool with 5 parameters and no output schema or annotations, the description is incomplete. It lacks details about output format, error states, file write behavior, and how context_files are used. This leaves significant gaps for the 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?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning to parameters beyond what the schema already provides. It focuses on the model's purpose rather than parameter details, so it does not improve or worsen parameter understanding.
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 'Instruction-following code generation' with a specific verb (generate code) and resource (using Cerebras model). It distinguishes from sibling tools by emphasizing 'precise instruction following, documentation-heavy code, typed interfaces, and detailed specs', setting it apart from cerebras_auto, cerebras_complex, etc.
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 for instruction-following and documentation-heavy code, but lacks explicit guidance on when to use this versus siblings. It does not specify when not to use it or provide clear alternatives, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast code generation using Cerebras gpt-oss-120b (120B params). Fast model for simple edits, boilerplate, single-function generation. Use for trivial tasks where speed matters most.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | REQUIRED: Detailed code generation instructions. Include method signatures, data structures, error handling requirements, and integration details. | |
| file_path | Yes | REQUIRED: Absolute path to the file to create or modify. | |
| max_tokens | No | OPTIONAL: Maximum tokens in the response. | |
| temperature | No | OPTIONAL: Sampling temperature (default 0.1). | |
| context_files | No | OPTIONAL: Array of file paths to read as context for the generation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions speed and model size but does not reveal that the tool likely writes to files (based on file_path parameter) or any side effects, permissions, or rate limits. Key behavioral information is missing.
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 extremely concise with three short sentences, front-loading the purpose and usage. No unnecessary words or 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 lack of output schema and 5 parameters, the description is brief. It does not explain the tool's action (e.g., whether it writes files directly or returns code) or what the output looks like. Basic contextual details are missing.
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 baseline is 3. The description adds no significant meaning beyond the schema; it merely restates the tool's speed. The schema already adequately describes the parameters.
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 is for fast code generation using a specific model, targeting simple edits, boilerplate, and single-function generation. It distinguishes from siblings by emphasizing trivial tasks where speed matters, though it does not explicitly contrast with other cerebras tools.
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 to use this tool for trivial tasks where speed is most important. It implies alternatives exist for more complex tasks but does not name them or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced reasoning code generation using Cerebras zai-glm-4.7 (355B params, reasoning_format:hidden). Most powerful model for algorithms, architecture decisions, advanced logic, and tasks requiring deep reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | REQUIRED: Detailed code generation instructions. Include method signatures, data structures, error handling requirements, and integration details. | |
| file_path | Yes | REQUIRED: Absolute path to the file to create or modify. | |
| max_tokens | No | OPTIONAL: Maximum tokens in the response. | |
| temperature | No | OPTIONAL: Sampling temperature (default 0.1). | |
| context_files | No | OPTIONAL: Array of file paths to read as context for the generation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses model name, parameters, reasoning format hidden. However, no annotations exist, and description fails to mention whether tool modifies state (file_path suggests write), potential costs, or rate limits. Moderate transparency.
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?
Single sentence with two clauses, zero waste, front-loaded with core purpose. Highly concise.
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?
No output schema, but schema covers parameters well. Description focuses on model capabilities; missing output format details, but overall sufficient for usage given sibling comparison and parameter schema.
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 coverage is 100% with detailed descriptions. Description adds no extra information about parameters, so baseline 3 is appropriate.
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?
Description explicitly states verb (generate code), resource (Cerebras zai-glm-4.7), and distinguishes from siblings by emphasizing 'most powerful for deep reasoning' vs other cerebras tools.
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?
Clearly states when to use: for algorithms, architecture decisions, advanced logic, deep reasoning. Implicitly contrasts with siblings, but no explicit when-not-to-use or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct use case: auto-selection, heavy code, instruction-following, fast generation, or deep reasoning. Descriptions clearly separate model sizes and tasks, eliminating ambiguity.
All tool names follow a consistent 'cerebras_<adjective>' pattern using snake_case. The descriptors (auto, complex, instruct, quick, reasoning) clearly indicate the tool's purpose.
With 5 tools, the server covers the main model variants without being excessive. The count is well-scoped for a model selection server, providing essential choices without redundancy.
The tool surface covers auto-selection, heavy tasks, instruction-tuned, fast, and reasoning use cases. One minor gap: no explicit 'chat' or 'vision' tool, but the domain appears focused on code generation, so the set is largely complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
One memory, every AI: Claude, ChatGPT, Perplexity, Gemini, Cursor, OpenClaw, Hermes, any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/khansabassem/cerebras-multi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
