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., "@kontra mode on. Should we use Rust or Go for our backend?"
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 best ideas are forged under challenge. People know this: we argue, we push back, and what survives is sharper. An AI chat skips that step. It thinks on its own and tends to agree with you. Kontra puts the challenge back in. The moment you prompt, one or more AI debaters take the other side and argue it out with your assistant, so the answer you get has already been tested.
It runs as an MCP server. You bring your own API keys.
You turn on kontra mode and ask a question.
Your assistant writes its position and sends it to the debaters.
Each debater replies in character with a stance and either "keep going" or "settled".
After each round your assistant recaps where each side stands, answers the challenge, and runs another round, until the debate settles.
Your assistant replies with a short, structured rundown: the positions and their strongest arguments, where the debate lands, and a recommendation.
The debate runs for as many rounds as it needs. A round limit stops it from running forever.
Related MCP server: brainstorm-mcp
No Node, no config files, no terminal.
Download kontra.mcpb from the latest release.
Open Claude Desktop, go to Settings, then Extensions.
Drag kontra.mcpb into the window (or double-click the file).
Paste your API key into the box when asked, and turn it on.
Claude Desktop bundles everything and stores your key in your operating system's secure storage.
Kontra is a standard MCP server, so it works in any MCP client. You need Node 18 or newer. Add this server entry to the client's MCP config, then restart the client:
{
"mcpServers": {
"kontra": {
"command": "npx",
"args": ["-y", "mcp-kontra"],
"env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
}
}
}Where each client keeps that config:
Client | Config |
Claude Code |
|
Cursor |
|
Claude Desktop (manual) | Settings, then Developer, then Edit Config |
Windsurf, Cline, and others | that client's MCP settings file |
Some clients (such as VS Code's built-in MCP support) use a servers key instead of mcpServers. The command, args, and env are the same.
You start with one debater: a ruthless contrarian on Claude Opus 4.8.
Kontra never takes a key through the chat. It reads keys only from environment variables, set one of two ways:
One-click install: type the key into the secure form. It is stored by your operating system, not in a file.
Other clients: put the key in the env block of the server entry above.
A few notes:
You only need a key for the providers your debaters actually use. By default that is just Anthropic (Claude), so you are asked for one key, not three.
If a key is missing, Kontra tells your assistant which single key to add, and your assistant asks you for it in the chat.
Do not commit a config file that contains a real key.
After adding or changing a key, restart the client.
Say "kontra mode on" and ask a question. To change the debate, just ask in plain words, and your setup is saved until you change it. You can set the personas, the number of debaters (up to 5), each debater's provider and model, and the round limit (up to 12).
Real prompts, from quick gut-checks to bigger calls. Use the default challenger, or set up your own panel.
kontra mode on. Planning to fix the slow dashboard with a 60-second cache. Before I build it, what am I missing?
kontra mode on. Going to mark this flaky test as skipped so CI stops blocking the team. Talk me out of it.
kontra mode on. A customer about to churn asked for 20% off to stay, and I want to say yes. Argue the other side.
kontra mode on. Have a skeptical CFO and a growth-minded sales lead argue it out: should we offer net-60 terms to land a big deal?
kontra mode on. About to sign a 12-month lease at 40% of my take-home. Push back before I commit.
kontra mode on. Here's the message I drafted to a friend who keeps cancelling on me. What will I wish I'd changed?
Pick any debater's provider. Set the matching key (in the one-click form, or as an env var).
Provider | API key | Example models |
anthropic |
| claude-opus-4-8 (default), claude-sonnet-4-6 |
openai |
| gpt-5.5 (default), gpt-5.4-mini |
| gemini-3.5-flash (default), gemini-2.5-pro |
Any model the provider offers works. If you name one that does not exist, Kontra tells you so you can fix it.
debate_status: shows your saved debaters, models, round limit, and which keys are set.
configure_debate: changes and saves the setup.
challenge: runs one round of debate.
Your assistant calls these for you. You just talk to it.
Kontra saves your setup to ~/.kontra/config.json. Point it somewhere else with the KONTRA_CONFIG environment variable.
git clone https://github.com/a1ex-bb/kontra.git
cd kontra
npm install
npm run build # compile TypeScript to dist/
npm run bundle # build kontra.mcpb for one-click installTry the tools in a browser with the MCP Inspector. Set the key for whichever providers you want to exercise. Anthropic alone is enough for the default debater; add the others only if you configure debaters on them:
ANTHROPIC_API_KEY=sk-ant-... npm run inspect
# add OPENAI_API_KEY=... and/or GEMINI_API_KEY=... too if your debaters use themMIT
Present your position to the saved debaters and run a discussion before you answer. When the user has activated kontra mode (e.g. said "kontra mode on"), ALWAYS run this loop before answering substantive questions. The loop: (1) call with your position; (2) answer the debaters' questions directly, respond to their specific points, ask questions back where their objections are ambiguous, then call again with the FULL transcript (debater replies under their names, your own turns as speaker 'host'); (3) keep going for as many rounds as the debate needs. The 'status' field is 'settled' once every debater has nothing new to add (or the round cap is hit), or 'error' if every debater failed; never synthesize while it is 'continue'. If the result is an onboarding message about a missing API key, relay it to the user and stop; do not retry until they confirm the key is set. To change the debaters or round limit, use configure_debate (it saves). Follow the 'instruction' field in the result for how to format your final reply.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | the user's question, restated | |
| position | Yes | the host's current argument or answer | |
| transcript | No | prior rounds in order; debater replies under their names, your turns as 'host' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the loop steps, status field meanings ('settled', 'error', 'continue'), error handling for missing API key, and the 'instruction' field. No contradictions found.
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 dense but well-structured, with the loop steps clearly enumerated. It is slightly long but every sentence adds value. Front-loaded with purpose and usage condition.
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 no output schema, the description explains return value fields (status, instruction) and covers edge cases like missing API key and round caps. It is fully comprehensive for the tool's complexity.
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 covers 100% of parameters with descriptions. The description adds context: 'topic' is the user's question restated, 'position' is the host's argument, 'transcript' includes prior rounds with speaker names. This adds value beyond schema.
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: 'Present your position to the saved debaters and run a discussion before you answer.' It distinguishes from sibling tools by specifying that configure_debate is used for changing debaters or round limits.
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: 'When the user has activated kontra mode ... ALWAYS run this loop before answering substantive questions.' It also provides alternatives (configure_debate for configuration) and stopping conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set and SAVE the debate setup. The settings persist across sessions until changed. Use this whenever the user wants to change who debates (their personalities, how many up to 5, which provider and model each uses) or the round limit (up to 12). Providers: anthropic, openai, google. Pass only the fields you want to change.
| Name | Required | Description | Default |
|---|---|---|---|
| debaters | No | replace the full set of debaters | |
| max_rounds | No | safety cap on rounds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses persistence across sessions and partial update design. However, it does not mention that the debaters array completely replaces the existing set (schema says 'replace the full set'), nor potential side effects or validation 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?
Three sentences, no fluff. Front-loaded with purpose and persistence. Every sentence adds useful information without 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 no output schema and no annotations, the description covers purpose, persistence, usage context, provider list, limits, and partial updates. It misses mention of confirmation or return behavior, but is largely complete for a configuration 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 coverage is 100%, baseline 3. The description adds value by explaining 'personalities', 'up to 5' debaters, 'round limit (up to 12)', and listing supported providers ('anthropic, openai, google'). It also clarifies partial updates.
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 'Set and SAVE the debate setup', specifying the verb and resource. It distinguishes itself from siblings 'challenge' and 'debate_status' by focusing on configuration.
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 tells when to use the tool ('whenever the user wants to change who debates or the round limit') and advises partial updates ('Pass only the fields you want to change'). It lacks explicit when-not-to-use or alternatives, but context with siblings implies that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the saved debate setup (debaters, providers, models, round limit) and whether each provider's API key is set. Call this to confirm setup or when the user asks who is in the debate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that it displays saved configuration and API key status. It implies a read-only operation without side effects. Would benefit from explicitly stating it doesn't modify anything.
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-load the key information: what is shown (first sentence) and when to use it (second sentence). No unnecessary details.
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 covers the output content (debaters, providers, models, API keys) and usage context. No output schema exists, so the description serves as the sole documentation for what the agent can expect. Could be enhanced with more detail on output structure.
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?
With zero parameters, the schema trivially covers everything. The description adds value by explaining what information the tool returns, meeting the baseline for 0-param 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 it shows the saved debate setup including specific components like debaters, providers, models, and API key status. It distinguishes from siblings 'challenge' (likely starting a debate) and 'configure_debate' (changing settings) by focusing on status display.
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 tells the agent to call this to confirm setup or when the user asks about debaters. Provides clear context for use, though no exclusion criteria given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: 'challenge' runs the debate loop, 'configure_debate' modifies the setup, and 'debate_status' displays configuration and key status. No overlap in functionality.
All tool names use a consistent lowercase_with_underscores pattern. The names clearly indicate their action and scope.
Three tools perfectly scope the server's purpose: one for running debates, one for configuration, and one for status. This minimal set avoids bloat while covering the core functions.
The server covers the main debate workflow (run, configure, check status). A minor gap is the lack of a tool to stop a running debate or reset configuration, but these are not essential for the primary use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Multiple AIs peer-review and debate your question, then return one fact-checked answer.
Multi-model AI debates: GPT-4o, Claude, Gemini & 200+ models discuss, then synthesize insight.
Track competitors from your AI assistant: change feed, page snapshots, labels and alerts.
Generate AI images, videos, music, SFX & speech in any AI assistant. Results appear inline in chat.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/a1ex-bb/kontra'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
