Allows sending prompts to Google's Antigravity CLI (agy) for Gemini model consultations, including presets such as 3.8 Flash / Extended, persistent thread continuation, per-call model/effort overrides, and structured results.
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., "@MasterMind Lite Send this exact prompt to MasterMind: is this SQL schema normalized?"
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.
Ask Claude, Gemini, and Grok from a ChatGPT conversation through the provider CLIs you already use.
Claude
/
ChatGPT -> MasterMind Lite -> Gemini
\
Grok
|
v
ChatGPT synthesisChatGPT remains the coordinator. MasterMind Lite sends one payload to independent advisers in parallel and returns their answers separately. It does not vote, rank models, run an internal debate, or act as an autonomous agent.
Different models often catch different flaws, edge cases, and approaches. Comparing them improved my planning and reviews, but repeatedly opening three sites, rebuilding context, copying prompts, and pasting every answer back into ChatGPT became tedious. MasterMind Lite makes that small workflow one local tool call while leaving the final judgment with ChatGPT and the user.
Related MCP server: Zen MCP Server
ChatGPT calls one local MCP consultation tool.
MasterMind Lite asks selected providers concurrently with the same payload.
Claude uses Claude Code, Gemini uses Google's Antigravity CLI (agy), and Grok uses Grok CLI.
Full provider results return independently, including partial success when one provider fails.
Stable thread keys continue the corresponding native provider conversations.
Model changes safely restart only the affected provider conversation.
No API keys, prompt bodies, response bodies, or telemetry are stored by MasterMind Lite.
Say: “Send this exact prompt to MasterMind.”
mastermind_exact forwards the supplied text unchanged. Provider selection and model overrides are
metadata: they are never appended or prepended to the prompt. MasterMind Lite verifies the outgoing
UTF-8 payload with SHA-256 for every provider.
Say: “Initiate MasterMind and get feedback on this.”
ChatGPT—not MasterMind Lite—constructs a concise, self-contained briefing from the relevant chat
context. mastermind_feedback then sends that briefing unchanged to the independent advisers.
Ordinary consultations use these product presets automatically:
Adviser | Friendly preset | Current CLI resolution |
Claude | Opus 5 / Medium |
|
Gemini | 3.8 Flash / Extended |
|
Grok | Expert |
|
“Extended” and “Expert” are stable MasterMind Lite product names. The preset layer isolates users
from provider-specific identifiers. mmlite doctor and mmlite config show display both the
friendly preset and current resolved CLI settings.
When a user explicitly asks for another setting, ChatGPT passes a per-call override. Examples:
“Call MasterMind, but use Claude Opus 5 High.” uses Claude's Opus 5 / High preset only.
“Use Grok Simple this time.” uses Grok's Simple preset only.
A custom override can supply an explicit CLI model and/or effort.
The additional built-in mappings are Opus 5 / High → opus with high, and Grok Simple →
grok-4.6 with low reasoning effort.
No model choice is required for normal calls. If an override changes a provider's resolved model or
effort on a persistent thread, MasterMind Lite starts a fresh native session for that provider,
returns thread_state: "restarted", and leaves the other provider sessions untouched. Returning to
the default later may therefore restart that provider again.
Windows with Python 3.11 or newer (v0.1 is built and live-tested on Windows).
Claude Code CLI, authenticated with a supported Claude account.
Google Antigravity CLI (agy), authenticated with a supported Google account.
Grok CLI, authenticated with a supported xAI account.
ChatGPT/Codex Desktop with local STDIO MCP support for the conversational workflow.
Provider access varies by product, subscription, region, and CLI release. MasterMind Lite does not guarantee that every consumer plan includes every model.
git clone https://github.com/kukumaka/mastermind-lite.git
cd mastermind-lite
py -3.11 -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install .Authenticate the provider CLIs using their supported flows:
claude auth login
agy models
grok loginagy models also verifies that the authenticated Antigravity model catalog is reachable. Then run:
mmlite doctor
mmlite config showThe first command creates %USERPROFILE%\.aimastermind-lite\config.json. The simple schema-v3
defaults look like this:
{
"schema_version": 3,
"providers": {
"claude": {
"preset": "Opus 5 / Medium",
"timeout_seconds": 150,
"max_response_chars": 24000
},
"gemini": {
"preset": "3.8 Flash / Extended",
"timeout_seconds": 150,
"max_response_chars": 24000
},
"grok": {
"preset": "Expert",
"timeout_seconds": 150,
"max_response_chars": 24000
}
}
}Advanced users can replace one preset with explicit settings:
{
"preset": "Custom",
"model": "provider-model-id",
"effort": "high",
"timeout_seconds": 150,
"max_response_chars": 24000
}Invalid fields, presets, or effort values fail before any provider call. Configuration is reloaded
for every consultation. External CLI releases can rename models or flags; use doctor and the
provider model-list commands after upgrading a CLI.
mmlite consult --thread project-review --prompt "What should I reconsider?"
mmlite consult --thread project-review --prompt-file C:\path\to\prompt.txt
mmlite consult --thread project-review --provider grok --prompt "Retry the question."
mmlite thread --thread project-review
mmlite reset --thread project-reviewRepeat --provider to select more than one adviser. Provider selection supports targeted retries;
MasterMind Lite never automatically repeats an entire consultation.
Run the local STDIO server with:
mmlite-mcpOr register the installed executable directly using a generic path such as:
<repo>\.venv\Scripts\mmlite-mcp.exeIn the desktop MCP server configuration, ensure the outer tool timeout exceeds the provider timeout. The recommended values are 150 seconds per provider and 180 seconds for the MCP tool:
[mcp_servers.mastermind_lite]
command = 'C:\path\to\mastermind-lite\.venv\Scripts\mmlite-mcp.exe'
tool_timeout_sec = 180After adding the STDIO server, restart the desktop app and use /mcp to confirm these three tools:
mastermind_exact
mastermind_feedback
mastermind_reset_thread
Each provider has an independent timeout. If Claude and Gemini finish while Grok times out, both
completed answers return alongside Grok's structured error. Only the failed provider can be retried
with providers: ["grok"]; successful siblings are not silently called again.
Each result includes thread_state (new, continued, or restarted), a locally reliable
successful_turn_count, requested preset/model/effort, provider-reported settings when available,
duration, prompt hash, and truncation metadata. Counts remain null when old state cannot support a
reliable value.
Provider histories can drift because each CLI compacts and interprets context differently. Use a fresh thread or a self-contained feedback briefing when a clean comparison matters. Resetting a MasterMind thread forgets local mappings; it does not delete histories owned by provider CLIs.
Responses are limited to 24,000 characters per provider by default. A longer answer retains its
beginning and end and returns truncated: true with original and returned character counts.
Prompts are sent to every selected provider. Authentication remains managed by the provider CLIs, and users remain responsible for those providers' data terms and subscription quotas.
Runtime state is local under %USERPROFILE%\.aimastermind-lite; prompt and response bodies are
not persisted.
Known provider API-key environment variables are removed from child processes.
Claude receives an empty tool set and strict empty MCP configuration.
Antigravity exposes no complete no-tools switch; its isolation is weaker even though it runs headlessly with sandbox selection and disabled slash commands.
Grok's CLI-level tools and permissions are denied, but its installed documentation does not claim Windows OS sandbox enforcement.
External CLI changes can require adapter updates.
Multiple opinions can expose missed assumptions; they do not guarantee a better answer.
MasterMind Lite is intentionally not an autonomous agent framework or browser automation system.
Please report security issues using the process in SECURITY.md.
python -m pip install -e ".[dev]" build
pytest -q
python -m buildThe test suite installs an automatic guard that rejects attempts to launch claude, agy, or
grok, so automated tests do not intentionally consume provider quota. The GitHub Actions workflow
runs only this offline suite and package build.
See POST_V0_1.md for deliberately deferred ideas and CONTRIBUTING.md for the small contribution guide.
MIT. See LICENSE.
Send exactly the supplied prompt, unchanged, to Claude, Gemini, and Grok independently. Use this when the user says 'same prompt', 'exact prompt', 'exactly this', or equivalent. Do not rewrite, summarize, prepend, append, or provider-specialize prompt. On the first MasterMind call, create a short stable topic-based thread_key; reuse it on later calls in this chat unless the user asks for a fresh/reset thread. Do not ask the user to invent a key unless necessary. The result echoes thread_key and a SHA-256 hash. Defaults are used automatically. Only when the user explicitly requests a different setting, pass provider_overrides, for example {'claude': {'preset': 'Opus 5 / High'}} or {'grok': {'preset': 'Simple'}}. A custom override may instead contain model and/or effort. Overrides are metadata and must never be inserted into the prompt. Changing resolved model or effort restarts only that provider's native session.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| providers | No | ||
| thread_key | Yes | ||
| reset_thread | No | ||
| provider_overrides | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses real behavioral traits: the response echoes thread_key plus a SHA-256 hash, changing a resolved model or effort restarts only that provider's native session, and overrides are metadata that never enter the prompt. These are consequential, non-obvious side effects that structured fields do not convey.
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 core directive is front-loaded in the first sentence, and the remainder is largely non-redundant operational guidance. It is dense and slightly long, but nearly every sentence carries an actionable constraint (thread lifecycle, override rules, session restart).
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 an output schema present, return values need not be explained, yet the description still notes the thread_key/hash echo. It covers thread lifecycle, defaults, and override semantics thoroughly; only the providers selection parameter lacks direct explanation, a minor omission.
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%, so the description must carry semantics, and it largely does: prompt (exact, unmodified), thread_key (create a stable topic-based key on first call, reuse thereafter), and provider_overrides (with preset examples and the note that model/effort may be used). The 'providers' array and 'reset_thread' flag are only indirectly covered (via the named providers and the 'fresh/reset thread' phrasing), leaving a small gap.
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 states a precise verb and resource: it sends 'exactly the supplied prompt, unchanged' to three named providers independently, and the title reinforces the 'three advisers' framing. Nothing about its function is ambiguous, and it is trivially distinguishable from siblings like mastermind_reset_thread and mastermind_feedback.
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?
It gives explicit trigger phrases ('same prompt', 'exact prompt', 'exactly this') and a concrete negative directive ('Do not rewrite, summarize, prepend, append, or provider-specialize'). It also states when to pass provider_overrides ('Only when the user explicitly requests a different setting') versus relying on defaults, which is a clear use/not-use boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send one self-contained briefing, unchanged, to Claude, Gemini, and Grok independently. Before calling, read relevant current conversation context and write a neutral briefing that includes the complete prompt/artifact/plan being reviewed, decisions already made, and the exact question. Include only context that helps. Do not anchor advisers with one another's responses unless the user explicitly asks. The service does not construct or edit the briefing. Create a short stable topic-based thread_key on the first call and reuse it later in this chat. Defaults are used automatically. Only when the user explicitly requests a different setting, pass provider_overrides, for example {'claude': {'preset': 'Opus 5 / High'}} or {'grok': {'preset': 'Simple'}}. A custom override may instead contain model and/or effort. Overrides are metadata and must never be inserted into the prompt. Changing resolved model or effort restarts only that provider's native session.
| Name | Required | Description | Default |
|---|---|---|---|
| purpose | No | ||
| briefing | Yes | ||
| providers | No | ||
| thread_key | Yes | ||
| reset_thread | No | ||
| provider_overrides | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds non-obvious behaviors: the service does not construct or edit the briefing, defaults are used automatically, overriding model or effort restarts only that provider's native session, and overrides are metadata never inserted into the prompt. This is substantial added context beyond the annotations, though rate limits and failure modes are unstated.
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?
Front-loads the core action and thread_key guidance, but several sentences restate or overlap (e.g. briefing content guidance spans multiple sentences, and 'Defaults are used automatically' plus the override paragraph could be tightened). Long but mostly earned; some redundancy around override semantics.
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 tool is a 6-parameter, open-world, non-idempotent fan-out with an output schema, so the description must cover creation, thread reuse, override scoping, and session restart semantics. It covers these well, though it leaves purpose, providers, and reset_thread unexplained and does not describe concurrency or failure behavior across providers.
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 0%, so the description must compensate. It defines briefing (self-contained, complete prompt/artifact/plan, exact question), thread_key (short, stable, topic-based, reuse in chat), provider_overrides (only when explicitly requested, format example, may contain model/effort, metadata only), and the restart behavior of model/effort changes. It does not explain purpose, providers, or reset_thread 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?
States a specific verb+resource: sends one self-contained briefing to Claude, Gemini, and Grok independently, and explicitly says the service does not construct or edit the briefing. Distinguishes itself from mastermind_exact and mastermind_reset_thread by describing the multi-advisor fan-out and the thread_key reuse pattern.
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?
Gives explicit when-to-use rules: read current conversation context before calling, include the complete prompt/artifact/plan and decisions already made, do not anchor advisers with one another's responses unless the user asks. Also names reset_thread via the sibling mastermind_reset_thread indirectly and states thread_key must be created on first call and reused.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forget the local Claude, Gemini, and Grok session mappings for thread_key. Use when the user asks to start fresh; a later consultation creates three new native conversations.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description goes beyond that by explaining the consequence: mappings are forgotten and a later consultation spawns three new native conversations. It does not mention auth requirements or rate limits, but the behavioral consequence is well disclosed.
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 tight sentences, front-loaded with the action and its consequence, followed immediately by the usage condition. No filler.
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 tool is simple (one param, output schema present) and the description covers the core behavior and post-reset outcome. It lacks only explanation of the thread_key identifier, which is a minor gap for a single-param tool with an output 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?
Only one parameter exists and schema coverage is 0%, so there is no schema documentation to lean on. The description uses thread_key but never explains what a thread key is or how it is obtained. With one parameter, baseline 4 would apply only if the description compensated, which it does not.
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 ('forget') and the exact resource affected: local Claude, Gemini, and Grok session mappings for thread_key. It clearly distinguishes itself from siblings like mastermind_exact and mastermind_feedback, though 'reset' in the title vs 'forget' in the description is slightly loose.
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 says 'Use when the user asks to start fresh,' giving a clear trigger. It does not name alternatives or when-not-to-use conditions, so it stops short of a 5.
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.
v0.1.0mastermind_exactmastermind_feedbackmastermind_reset_threadScored across 3 tools
reset_thread is clearly distinct, but exact and feedback both fan out unchanged content to the same three providers, so their boundary depends on intended usage rather than different mechanics. The descriptions provide useful cues, so misselection is possible but not severe.
All names share the mastermind_ prefix and snake_case, which is readable. However, only reset_thread follows a verb_noun pattern; exact and feedback are noun/adjective labels, making the overall convention mixed.
Three tools form a minimal but focused surface for a Lite multi-model consultation server. Each tool has a role, though the set is slightly thin for full thread lifecycle management.
Core operations are covered: send exact prompts, send briefing-style feedback, and reset thread mappings. Minor gaps exist, such as no way to list or inspect existing thread_key mappings, but agents can work around this.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
