Skip to main content
Glama

q_brainstorm_start

Start a background multi-agent brainstorm that returns a job_id immediately. Each agent offers 3-5 distinct ideas with trade-offs and minimal test plans; fetch results via q_await.

Instructions

Start a q-brainstorm run in the background. Returns {"job_id": str} immediately. Each agent contributes 3-5 distinct ideas with rationale, trade-offs, and the cheapest test that would give signal; no synthesis. Retrieve results by calling q_await with the returned job_id.

Between the start and the await, the caller is expected to list its own ideas — this is the structural anti-bias gate.

research, when supplied, seeds round 1 with a q_research digest as EVIDENCE: agents are told to ground their ideas in it, recombine it, or extend past it. Pass the raw digest markdown (verbatim from q_research) -- never your own summary of it, and never your own ideas; those stay behind the anti-bias gate. Distinct from prior_ideas, whose do-not-repeat framing marks content to diverge AWAY from.

prior_ideas, when supplied, seeds a divergence round: the agents are told the listed ideas are already on the table and must not be repeated -- used by the --extended flow to push past round 1. Composes with research (evidence stays evidence; ideas stay do-not-repeat).

grounding, with prior_ideas, runs a validation-guide pass over the listed ideas instead of diverging past them -- used by q-skystorm Stage 2.

Optionally assign a cognitive stance per agent via roles, a list of 'stance:agent' strings (stances: skeptic, architect, security, maintainer, analyst, neutral, visionary, pioneer). Unassigned agents use their default stance.

gemini_model, when supplied, runs the gemini seat on that agy model for this invocation only (an id exactly as printed by agy models, e.g. 'claude-opus-4-6-thinking').

Expected wall-clock to completion: 30s-4min depending on the agents and topic complexity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdYes
hostNo
rolesNo
topicYes
agentsNo
skip_ghNo
verboseNo
researchNo
groundingNo
no_contextNo
prior_ideasNo
gemini_modelNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers comprehensively. It discloses the async nature (runs in background, returns job_id immediately), the output format, the expected timing (30s-4min), and the behavioral constraints (agents contribute 3-5 ideas, no synthesis, anti-bias gate). It also explains the semantic difference between research and prior_ideas. No behavioral aspect is left opaque.

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-organized into focused paragraphs. It front-loads the core behavior and return type, then explains each optional parameter and composition. Each paragraph earns its place, but the length is near the upper bound of acceptable. It is structured rather than rambling, so it scores a 4.

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

Completeness4/5

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

Given the complexity (12 params, no schema coverage, no annotations, and an output schema), the description covers the essential workflow and the most impactful parameters. It explains the anti-bias gate, the difference between research and prior_ideas, and the grounding pass. Missing: descriptions of verbose, skip_gh, no_context, host, and a few error-handling details, but those are minor. It is nearly complete for a working understanding.

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

Parameters3/5

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

Schema coverage is 0%, so the description must explain parameters. It does explain the significant ones: research, prior_ideas, grounding, roles, gemini_model. However, it omits explanations for agents, skip_gh, verbose, no_context, host, and even cwd/topic are only implicit. For a tool with 12 parameters, the description adds value but leaves several parameters undocumented, forcing the agent to infer from names alone.

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 uses a specific verb and resource ('Start a q-brainstorm run'), states the async behavior, and names the sibling tools it complements (q_await, q_research). It clearly distinguishes this from q_plan_start, q_validate_start, etc., and explains the composition with q_research and q_await. An agent can immediately understand what this tool does and how it fits.

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?

The description provides explicit when-to-use guidance: 'Between the start and the await, the caller is expected to list its own ideas — this is the structural anti-bias gate.' It also names alternatives and conditions: 'Distinct from prior_ideas, whose do-not-repeat framing...' and mentions specific flows like '--extended' and 'q-skystorm Stage 2' that select the grounding mode. This is unambiguous.

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

Install Server

Other Tools

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/sdewell/code-quorum'

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