MCP server that spawns Antigravity sub-agents for delegated tasks via cascade APIs
Two tools with detailed descriptions and reasonable parameter schemas. submit_agent has comprehensive guidance on when/how to use it (pattern-aligned). However, both tools lack explicit output schema documentation, parameter descriptions are sometimes generic, and error handling guidance is minimal. Schema completeness is moderate, Zod validators present but return types undocumented. No tool annotations (readOnlyHint/destructiveHint). Naming is clear (verb_noun pattern). Average tool quality ~62, typical for community servers.
Collect results from submit_agent calls. Blocks until ALL tasks finish, then returns all results together. Call this AFTER submitting all tasks via submit_agent. Pass the taskIds you received. Note: Sometimes agents may not finish within the timeout period. In such cases, the result will be returned as is, and you may need to manually check the status of the task in the Antigravity IDE.
Spawn an autonomous agent in Antigravity IDE. Returns a taskId INSTANTLY (does NOT wait for completion). The agent runs as a new Cascade conversation with full codebase access — it can read files, grep, run terminal commands, and edit files. It operates fully autonomously without asking questions. Each agent consumes significant resources (new conversation + model tokens), so only delegate tasks that provide real value. ALWAYS use this 2-step pattern: Step 1: Call submit_agent N times (each returns a taskId in ~1 second) Step 2: Call get_agent_results([taskId1, taskId2, ...]) to wait for ALL results at once All N agents run in parallel. Write self-contained prompts — the agent has ZERO prior context. WHEN TO USE (high-value tasks): ✅ Implement a scoped feature or bug fix (write code, run tests) ✅ Research/summarize a module, architecture, or large codebase area ✅ Run a build/test suite and report results ✅ Generate boilerplate, migrations, or repetitive code ✅ Perform multi-step analysis that requires reasoning WHEN NOT TO USE (do it yourself — faster & cheaper): ❌ Read or view files ❌ Simple grep/search operations ❌ Single-file edits that take < 30 seconds ❌ Tasks that just collect information without transforming it Models: gemini-high (default), gemini-low, gemini-flash, claude-opus, claude-sonnet, gpt-120b.
Output schemas not documented. Neither tool specifies what fields are returned or their types. LLMs cannot plan downstream calls or extract data reliably.
submit_agent parameter 'taskName' lacks description of its purpose and format. Parameter descriptions should explain what each controls.
get_agent_results lacks error handling guidance. If a task times out or fails, the description does not tell the LLM what to do next (retry, check manually, etc.).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). submit_agent is destructive (spawns agents, consumes resources); get_agent_results is read-only. Annotations help LLMs reason about side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Numeric parameters (timeout, maxReplies) lack min/max constraints in descriptions. LLMs may pass absurd values (timeout=999999, maxReplies=-1).