Skip to main content
Glama
Sign In
Antigravity MCP Server

Antigravity MCP Server

by x51xxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

brainstorm

Read-only

Generate structured creative ideas using frameworks like SCAMPER, design thinking, or lateral thinking, then evaluate each idea's feasibility and impact.

Instructions

Generate creative ideas using structured frameworks with domain context and feasibility analysis.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>"
    },
    "name": "brainstorm"
  }
}

Input Schema

NameRequiredDescriptionDefault
cdNoWorking directory
modelNoOptional model override. Known: Gemini 4 Hydrogen (Low), Gemini 4 Hydrogen (Medium), Gemini 4 Hydrogen (High), Gemini 4 Hydrogen (XHigh), Gemini 4 Argon (Low), Gemini 4 Argon (Medium), Gemini 4 Argon (High), Gemini 4 Carbon (Low), Gemini 4 Carbon (Medium), Gemini 4 Carbon (High), Orchestrator (Argon), Orchestrator (Carbon), Gemini 3.8 Flash (Low), Gemini 3.8 Flash (Medium), Gemini 3.8 Flash (High), Claude Opus 5.5 (Low), Claude Opus 5.5 (Medium), Claude Opus 5.5 (High), Claude Sonnet 5.5 (Low), Claude Sonnet 5.5 (Medium), Claude Sonnet 5.5 (High), GPT-OSS 120B (Medium). If omitted, uses your Antigravity CLI default.
domainNoDomain: software, business, creative, research, product, marketing, etc.
effortNoReasoning effort (--effort). Supported levels depend on the model — see list-models. Use with a base model ID (e.g. gemini-4-hydrogen); not supported by Orchestrator.
promptYesBrainstorming challenge or question
ideaCountNoNumber of ideas (default: 12, range: 5-30)
constraintsNoLimitations: budget, time, technical, legal, etc.
methodologyNoFramework: divergent, convergent, scamper, design-thinking, lateral, auto (default)auto
existingContextNoBackground info or previous attempts
includeAnalysisNoInclude feasibility/impact analysis

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that output is framework-structured and includes feasibility analysis, but says nothing about delegation to a model backend, latency, cost, or how the returned ideas are formatted. Useful but thin beyond the annotations.

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?

A single front-loaded sentence with no filler; each phrase maps to an actual capability of the tool. It could be slightly sharper by naming the ideation-vs-alternatives boundary in the same breath, but nothing is wasted.

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

Completeness3/5

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

With 10 parameters, no output schema, and annotations covering only safety, the description carries the burden of explaining what comes back. It gestures at structured ideas plus feasibility analysis but doesn't describe the result shape or how methodology and ideaCount shape output, leaving a gap for a fairly configurable tool.

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 description coverage is 100%, including detailed model and effort documentation, so the schema does the heavy lifting and a 3 is the baseline. The description only echoes two parameters implicitly ('domain context' → domain, 'feasibility analysis' → includeAnalysis) without adding syntax or interaction guidance such as how methodology interacts with effort.

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

Purpose4/5

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

The description pairs a specific verb with a specific resource ('Generate creative ideas') and names the mechanism ('structured frameworks') plus two enrichment layers (domain context, feasibility analysis). An agent can tell this is an ideation tool rather than a Q&A or planning tool. It stops short of naming which sibling to prefer, so it doesn't fully earn a 5.

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

Usage Guidelines3/5

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

Usage is only implied: 'creative ideas' and 'brainstorming challenge' signal ideation tasks, and the methodology enum hints at divergent vs convergent modes. There is no explicit statement of when to pick this over ask-antigravity or plan-antigravity, and no when-not guidance or prerequisites.

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

Deploy Server

Other Tools