Provides access to Google's Gemini models (e.g., gemini-3.1-pro with 2M context, gemini-3.8-flash, gemini-2.5-flash-image for image generation) for chat completions.
Provides access to Meta's Llama models (e.g., llama-3.3-70b) for chat completions.
Provides access to OpenAI models (e.g., gpt-4o-mini, gpt-oss-120b) for chat completions.
Click on "Deploy 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., "@WarungCyber MCP Server ask claude-sonnet-4-6 to write a regex for email validation"
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.
The official Model Context Protocol (MCP) server for WarungCyber AI Gateway (api.warungcyber.net).
Connect Claude Desktop, Cursor IDE, VS Code (Continue), Cline, Roo Code, Windsurf, and autonomous agents directly to 19 SOTA AI Models (Claude 4.6 Thinking, DeepSeek R1 Reasoning, Qwen 2.5 Coder, and 100% Uncensored Venice Dolphin 24B) with pay-as-you-go retail pricing starting from $1.00 USD (Rp 16,000) via instant QRIS / E-Wallet payments.
19 SOTA AI Models Available:
π Anthropic: claude-sonnet-4-6 (Thinking), claude-sonnet-3-7, claude-opus-4-6-thinking, claude-3-haiku
π§ DeepSeek: deepseek-reasoner (R1 Chain-of-Thought), deepseek-chat (V3 Code & Chat)
π» Alibaba / Qwen: qwen-2.5-coder-32b, qwen-2.5-72b
π Uncensored (Zero Refusal): venice-uncensored (Dolphin Mistral 24B β No moralizing guardrails, designed for pentest, security research & unrestricted writing)
π Google: gemini-3.1-pro (2M Context Window), gemini-3.8-flash, gemini-3.7-flash, gemini-2.5-flash-image (Image Generation)
π’ OpenAI & Meta: gpt-4o-mini, llama-3.3-70b, gpt-oss-120b, atria-dawn-preview
Sub-20ms Co-Location: Hosted on Tencent Cloud Jakarta Datacenter for ultra-low latency.
Non-Expiring Balance: Pay only for consumed tokens; balance never expires.
Standard OpenAI Format: Base URL https://api.warungcyber.net/v1.
Related MCP server: Vox MCP
Add the following configuration to your claude_desktop_config.json:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"warungcyber": {
"command": "npx",
"args": ["-y", "warungcyber-mcp"],
"env": {
"WARUNGCYBER_API_KEY": "sk-wc-YOUR_API_KEY_HERE"
}
}
}
}Don't have an API key? Get one instantly from https://api.warungcyber.net starting at $1.00 USD (Rp 16,000).
warungcyber_list_modelsLists all 19 available models with live pricing (USD & IDR), context window sizes, inference latencies, and category badges.
Arguments:
category (optional): "ALL" | "CODING" | "REASONING" | "UNCENSORED" | "VISION" | "CHEAP"
format (optional): "markdown" | "json"
warungcyber_check_balanceInspect live remaining balance (USD & IDR), total tokens consumed, active account status, and server latency.
Arguments:
apiKey (string): Your WarungCyber API Key (sk-wc-...).
warungcyber_chat_completionExecute an AI reasoning, coding, or text generation task through any model in the WarungCyber fleet.
Arguments:
model (string): e.g. "claude-sonnet-4-6", "deepseek-reasoner", "venice-uncensored", "qwen-2.5-coder-32b"
prompt (string): Task or query instruction
systemPrompt (optional string): Custom system behavior
temperature (optional number): Sampling temperature (0.0 to 2.0)
maxTokens (optional number): Maximum tokens to generate
warungcyber_get_setup_guideGenerates instant copy-paste configuration files for Cursor IDE, VS Code Continue, Cline, Roo Code, Python, and Node.js SDKs.
Arguments:
client: "cursor" | "continue" | "cline" | "chatbox" | "python" | "node" | "claude_desktop"
apiKey (optional string): Your API key to auto-fill into configs
# Run standalone stdio server
npx -y warungcyber-mcp
# Or install globally
npm install -g warungcyber-mcp
warungcyber-mcpDirect Gateway Traffic: All API calls are securely routed over HTTPS with TLS 1.3 to https://api.warungcyber.net/v1.
Zero Logging of Sensitive Prompts: Complies with zero-retention policies for enterprise and pentesting research.
πͺ Official Storefront & Top-Up: https://api.warungcyber.net
π API Documentation: https://api.warungcyber.net/#docs
π¬ Live Customer Support: Available 24/7 on website.
π¦ MCP Registry Listing: https://glama.ai/mcp/servers
MIT Β© 2026 WarungCyber (api.warungcyber.net)
Send a chat completion prompt to a selected WarungCyber AI model via external HTTP API call. Consumes account token balance based on prompt and completion length. Requires an active WarungCyber API key (sk-wc-...). Returns generated text and token usage metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Target AI model identifier to execute | |
| apiKey | No | WarungCyber API key (starts with sk-wc-). Uses WARUNGCYBER_API_KEY environment variable if omitted. | |
| prompt | Yes | The user prompt, task instruction, or code snippet to complete | |
| maxTokens | No | Maximum completion tokens to generate (default: 2048) | |
| temperature | No | Sampling temperature between 0.0 and 2.0 (default: 0.7) | |
| systemPrompt | No | Optional system instruction or persona definition |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: it makes an external HTTP call, consumes account token balance proportional to prompt and completion length, requires an sk-wc- prefixed API key, and returns generated text plus usage metrics. It stops short of error/failure behavior, rate limits, or what happens on insufficient balance.
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?
Three compact sentences with zero filler, front-loaded with the core action before cost, auth, and return-value details. Every sentence carries distinct 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?
With no output schema, the description usefully states that generated text and token usage metrics are returned. It covers cost and authentication, which is what an agent most needs before invoking a billable call, though failure modes and billing-exhaustion behavior are left unaddressed.
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 schema already documents model, apiKey, prompt, maxTokens, temperature, and systemPrompt. The description adds no parameter-level detail beyond what the schema provides, which is the expected baseline.
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 gives a specific verb and resource ('Send a chat completion prompt to a selected WarungCyber AI model') and scopes it as an external HTTP call. The action is unambiguous and clearly distinct from list_models, check_balance, and get_setup_guide, though no sibling is named explicitly, so full sibling differentiation credit is withheld.
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?
Usage context is implied rather than stated: the agent learns an active API key is required and that balance is consumed, which frames when the tool is usable. However, there is no explicit when-to-use/when-not-to-use guidance and no routing to alternatives such as check_balance before spending tokens.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve remaining account balance (USD/IDR), cumulative token consumption, and active account status for a WarungCyber API key via an external gateway API call. Read-only operation.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | WarungCyber API key (starts with sk-wc-) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses two traits beyond the schema: 'Read-only operation' (safe, non-mutating) and 'via an external gateway API call' (implies a remote network dependency and possible latency/failure). It does not describe rate limits, auth failure behavior, or caching, leaving real 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?
A single front-loaded sentence with no filler; the returned fields and read-only nature are stated compactly while every clause adds 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?
With no output schema, the description correctly enumerates what comes back (balance, cumulative token consumption, account status), which is the key missing structured info. It is slightly thin on error/edge behavior for an external gateway call, but otherwise complete for a one-parameter read 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?
Only one parameter exists and schema description coverage is 100% (the schema already documents the sk-wc- prefix format). The description adds context that this is a WarungCyber API key, but nothing about format or handling beyond what the schema states; baseline 3 applies.
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 gives a specific verb (Retrieve) and resource (remaining account balance), and enumerates the returned data: balance in USD/IDR, cumulative token consumption, and active account status. That scope is plainly distinct from list_models, get_setup_guide, and chat_completion, so an agent can identify it without opening the schema.
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?
There is no guidance on when to call this versus the siblings, no stated prerequisites beyond the apiKey parameter, and no mention of failure conditions (e.g. invalid or expired key). Use is only implied by the verb 'Retrieve'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate formatted Markdown setup guides and copy-paste configuration snippets for integrating WarungCyber into Cursor IDE, VS Code Continue, Cline, Chatbox, or Python and Node.js SDKs. Embeds the provided API key (or placeholder if omitted) directly into the code sample. Read-only operation.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | WarungCyber API key to embed in the configuration snippet | |
| client | Yes | Target client application or development environment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and mostly succeeds: it discloses that the operation is read-only and, importantly, that the supplied API key is embedded directly into the output code sample (or a placeholder is used when omitted). It does not mention auth requirements or rate limits, so a small gap remains.
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?
Three tight sentences, front-loaded with the action and outputs, then the key-embedding rule and the read-only status. No filler or redundancy.
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 2-parameter generator with no output schema, the description adequately conveys what is returned (Markdown guides and snippets). The one gap is that it lists five client targets but omits 'claude_desktop,' which is a valid enum value, leaving an agent unaware that target is supported.
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, but the description adds a rule the schema omits: apiKey is embedded 'or placeholder if omitted,' clarifying that the parameter is optional in effect. The client parameter is only echoed, not extended beyond the enum.
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?
States a specific verb and resource ('Generate formatted Markdown setup guides and copy-paste configuration snippets') and enumerates the concrete targets (Cursor, Continue, Cline, Chatbox, Python/Node SDKs). The purpose is unmistakably distinct from siblings like list_models or chat_completion, though it never explicitly contrasts itself with them.
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 phrase 'for integrating WarungCyber into...' implies the when-to-use context (onboarding/setup), but there is no explicit guidance on when to prefer this over other tools, no prerequisites, and no stated exclusions. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available AI models from the WarungCyber AI Gateway, including context window limits, token pricing (USD and IDR), and capability categories. Read-only operation.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format for the model list (default: markdown) | |
| category | No | Filter models by capability category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and directly states 'Read-only operation,' which is the key safety trait an agent needs. It also discloses the returned data categories, though it does not address authentication requirements or rate limits.
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, front-loaded with the core action and followed by a brief content summary and safety note. Every clause earns its place with no redundancy.
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, parameter-light list tool with no output schema and no annotations, the description covers the essential purpose, scope, returned data, and read-only nature. It is adequately complete, though it could optionally mention the format parameter or when to prefer this over directly calling chat_completion.
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 schema already documents both the format and category parameters. The description references 'capability categories' which loosely maps to the category filter, but adds no syntax or format details beyond what the schema provides, so the baseline of 3 applies.
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 uses the specific verb 'List' with the resource 'available AI models from the WarungCyber AI Gateway.' It also enumerates the returned data types (context window limits, token pricing, capability categories), making it clearly distinct from siblings like check_balance, get_setup_guide, and chat_completion.
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 by stating what the tool returns, but it does not explicitly say when to use it versus alternatives or when not to use it. No alternatives are named, so the agent must infer that this is the tool for discovering available models.
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.
v1.0.2warungcyber_chat_completion6 fields changedInput schema / properties / apiKey / descriptionPrevious value: -"WarungCyber API key (format: sk-wc-...). If omitted, uses WARUNGCYBER_API_KEY environment variable."New value: +"WarungCyber API key (starts with sk-wc-). Uses WARUNGCYBER_API_KEY environment variable if omitted."Input schema / properties / maxTokens / descriptionPrevious value: -"Maximum number of tokens to generate in the completion (default: 2048)."New value: +"Maximum completion tokens to generate (default: 2048)"Input schema / properties / model / descriptionPrevious value: -"The target AI model identifier. Choose 'claude-sonnet-4-6' or 'deepseek-reasoner' for coding/reasoning, 'venice-uncensored' for unrestricted security tasks, or 'gemini-3.1-pro' for massive context."New value: +"Target AI model identifier to execute"Input schema / properties / prompt / descriptionPrevious value: -"The user prompt, task instruction, code snippet to refactor, or query to execute."New value: +"The user prompt, task instruction, or code snippet to complete"Input schema / properties / systemPrompt / descriptionPrevious value: -"Optional system instruction or persona definition to guide the model's tone and output format."New value: +"Optional system instruction or persona definition"Input schema / properties / temperature / descriptionPrevious value: -"Sampling temperature between 0.0 (deterministic) and 2.0 (creative). Default is 0.7."New value: +"Sampling temperature between 0.0 and 2.0 (default: 0.7)"warungcyber_check_balance1 field changedInput schema / properties / apiKey / descriptionPrevious value: -"Your WarungCyber API key (e.g. sk-wc-...)"New value: +"WarungCyber API key (starts with sk-wc-)"warungcyber_get_setup_guide2 fields changedInput schema / properties / apiKey / descriptionPrevious value: -"Your WarungCyber API key to embed in snippet"New value: +"WarungCyber API key to embed in the configuration snippet"Input schema / properties / client / descriptionPrevious value: -"Target client or tool"New value: +"Target client application or development environment"warungcyber_list_models3 fields changedInput schema / properties / category / descriptionPrevious value: -"Filter models by capability"New value: +"Filter models by capability category"Input schema / properties / format / descriptionPrevious value: -"Output formatting (default: markdown)"New value: +"Output format for the model list (default: markdown)"Input schema / properties / format / enumPrevious value: -[
- "json",
- "markdown"
-]New value: +[
+ "markdown",
+ "json"
+]v1.0.1warungcyber_chat_completion11 fields changedInput schema / properties / apiKey / descriptionPrevious value: -"WarungCyber API key (optional if WARUNGCYBER_API_KEY env set)"New value: +"WarungCyber API key (format: sk-wc-...). If omitted, uses WARUNGCYBER_API_KEY environment variable."Input schema / properties / maxTokens / descriptionPrevious value: -"Maximum completion tokens"New value: +"Maximum number of tokens to generate in the completion (default: 2048)."Input schema / properties / maxTokens / maximumAdded value: +32000Input schema / properties / maxTokens / minimumAdded value: +1Input schema / properties / maxTokens / typePrevious value: -"number"New value: +"integer"Input schema / properties / model / descriptionPrevious value: -"Model ID (e.g. claude-sonnet-4-6, deepseek-reasoner, qwen-2.5-coder-32b, venice-uncensored, gemini-3.1-pro)"New value: +"The target AI model identifier. Choose 'claude-sonnet-4-6' or 'deepseek-reasoner' for coding/reasoning, 'venice-uncensored' for unrestricted security tasks, or 'gemini-3.1-pro' for massive context."Input schema / properties / model / enumAdded value: +[
+ "claude-sonnet-4-6",
+ "claude-sonnet-3-7",
+ "claude-opus-4-6-thinking",
+ "claude-3-haiku",
+ "deepseek-reasoner",
+ "deepseek-chat",
+ "qwen-2.5-coder-32b",
+ "qwen-2.5-72b",
+ "venice-uncensored",
+ "gemini-3.1-pro",
+ "gemini-3.8-flash",
+ "gemini-3.7-flash",
+ "gemini-3.6-flash",
+ "gemma-4-31b-it",
+ "gpt-4o-mini",
+ "llama-3.3-70b",
+ "gpt-oss-120b",
+ "atria-dawn-preview",
+ "gemini-2.5-flash-image"
+]Input schema / properties / prompt / descriptionPrevious value: -"User prompt or instruction"New value: +"The user prompt, task instruction, code snippet to refactor, or query to execute."Input schema / properties / prompt / minLengthAdded value: +1Input schema / properties / systemPrompt / descriptionPrevious value: -"Optional system instruction"New value: +"Optional system instruction or persona definition to guide the model's tone and output format."Input schema / properties / temperature / descriptionPrevious value: -"Sampling temperature (default: 0.7)"New value: +"Sampling temperature between 0.0 (deterministic) and 2.0 (creative). Default is 0.7."v1.0.0warungcyber_chat_completionwarungcyber_check_balancewarungcyber_get_setup_guidewarungcyber_list_modelsScored across 4 tools
Each tool has a clearly distinct purpose: listing models, checking account balance, generating setup guides, and performing chat completions. There is no overlap in functionality, so an agent can easily select the right tool.
Three tools follow a consistent warungcyber_verb_noun pattern (list_models, check_balance, get_setup_guide), but chat_completion deviates by using a noun phrase instead of a verb. The shared prefix and mostly consistent structure keep it readable.
Four tools is a well-scoped set for an AI gateway integration server, covering discovery, account status, setup, and core AI usage. Each tool earns its place without redundancy.
The surface covers the core lifecycle for using the WarungCyber gateway: discovering models, checking balance, integrating, and chatting. Minor gaps like streaming chat or embeddings exist but are not essential for the stated purpose.
Talk to your public-facing AI from any MCP client β Claude, ChatGPT, Cursor, Cline, Windsurf.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
