Skip to main content
Glama

brainstorm

Read-only

Orchestrate multi-round debates between AI models to critique and refine ideas, then synthesize a final conclusion.

Instructions

Run a multi-round brainstorming debate between multiple AI models. IMPORTANT: Before calling this tool, you MUST ask the user to choose a mode:

  1. API mode — Calls configured providers. These are either HTTP APIs billed per token (OpenAI, Gemini, DeepSeek, ...) or locally installed agent CLIs such as 'claude' and 'codex', which run on the user's existing subscription at no API cost. Call list_providers to see which of each are available.

  2. Hosted mode — No API keys needed. You execute prompts using sub-agents with models available in your environment (opus/sonnet/haiku, GPT, Gemini, etc.). Same model can be used multiple times — each run produces different perspectives.

Present these two options to the user with a one-liner explanation, then proceed based on their choice.

For API mode: set mode='api'. When participate=true (default), YOU also participate as a debater alongside external models via brainstorm_respond. For Hosted mode: set mode='hosted'. Ask the user which models to use, then spawn sub-agents for each model, collect responses, and call brainstorm_collect.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoExecution mode. Must be provided — if not, the tool will return options for the user to choose. 'api' — MCP server calls model APIs directly using configured API keys. 'hosted' — No API keys needed. Returns prompts for the HOST to execute using sub-agents with models available in the environment (opus/sonnet/haiku, GPT, Gemini, etc.).
styleNoDebate style. 'freeform' (default): open brainstorming. 'redteam': adversarial — models find flaws, risks, and weaknesses. 'socratic': probing questions that expose assumptions and push for deeper understanding.freeform
topicYesThe topic, question, or prompt to brainstorm about
modelsNoOptional: specific models to use as 'provider:model' (e.g. 'openai:gpt-4o', or 'claude:sonnet' / 'codex:default' for subscription-backed CLI providers). If not provided, all configured providers are used with their default models.
roundsNoNumber of debate rounds (default: 3)
contextNoOptional context to ground the debate — code snippets, PR diffs, error logs, architecture docs, etc. Models will see this alongside the topic.
participateNoWhether Claude should actively participate as a debater in each round (default: true). Set to false for a non-interactive debate between external models only.
synthesizerNoOptional: model for final synthesis as 'provider:model'. Defaults to the first model.
systemPromptNoOptional system prompt to guide the brainstorming style or constraints

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed5 schema fields changedv1.6.0
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Optional context to ground the debate — code snippets, PR diffs, error logs, architecture docs, etc. Models will see this alongside the topic.",
      +  "type": "string"
      +}
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "Execution mode. Must be provided — if not, the tool will return options for the user to choose.\n'api' — MCP server calls model APIs directly using configured API keys.\n'hosted' — No API keys needed. Returns prompts for the HOST to execute using sub-agents with models available in the environment (opus/sonnet/haiku, GPT, Gemini, etc.).",
      +  "enum": [
      +    "api",
      +    "hosted"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / models / description
      Previous value: -"Optional: specific models to use as 'provider:model' (e.g. 'openai:gpt-4o'). If not provided, all configured providers are used with their default models."New value: +"Optional: specific models to use as 'provider:model' (e.g. 'openai:gpt-4o', or 'claude:sonnet' / 'codex:default' for subscription-backed CLI providers). If not provided, all configured providers are used with their default models."
    • addedInput schema / properties / participate
      Added value: +{
      +  "default": true,
      +  "description": "Whether Claude should actively participate as a debater in each round (default: true). Set to false for a non-interactive debate between external models only.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / style
      Added value: +{
      +  "default": "freeform",
      +  "description": "Debate style. 'freeform' (default): open brainstorming. 'redteam': adversarial — models find flaws, risks, and weaknesses. 'socratic': probing questions that expose assumptions and push for deeper understanding.",
      +  "enum": [
      +    "freeform",
      +    "redteam",
      +    "socratic"
      +  ],
      +  "type": "string"
      +}
  2. First observedv1.0.1

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses detailed side effects beyond annotations: API mode calls external APIs with billing implications, hosted mode spawns sub-agents with environment models, and participation behavior via brainstorm_respond when participate=true. It also notes that if mode is omitted, the tool returns options. This is far richer than the readOnlyHint alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear sections, bolding, and lists. Every sentence conveys required operational details—nothing is redundant. While it could arguably be trimmed, the complexity of the tool's dual modes justifies the length. It is not flabby; it is dense and purposeful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no output schema, and complex branching (API vs hosted), the description covers prerequisites, alternatives, and step-by-step invocation guidance. It explains the full flow including how to use sibling tools (list_providers, brainstorm_respond, brainstorm_collect) and the host's role. It does not describe return values, but that is acceptable since no output schema is provided and the focus is on executing the tool properly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for all parameters, so the baseline is 3. The description adds extra meaning by explaining how mode interacts with user choice, prompts the use of list_providers, and clarifies the participate flag's role (via brainstorm_respond in API mode). It also clarifies the models format ('provider:model') implicitly through examples in the schema description. This elevates it above the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a multi-round brainstorming debate between multiple AI models. It specifies the verb (run), the resource (debate), and distinguishes itself from sibling tools like brainstorm_quick (presented as a quick version) and brainstorm_respond/collect (which are sub-components).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs the agent to ask the user to choose a mode before calling, explains both modes with one-liners, and directs the agent to use list_providers for available providers. It also tells what to do in hosted mode (ask which models to use, spawn sub-agents) and clarifies when to set mode='api' vs 'hosted'. Clear guidance on when to use and how to proceed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/spranab/brainstorm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server