2.2 MCP Developer Tooling, Subagent Isolation & Plan-Act-Verify Loops

Rosku Bank’s developers are migrating 60 Python microservices to the new ADK architecture using Google Antigravity, Gemini CLI, and Claude Code on Google Cloud, and they hit three major roadblocks:

When writing SQL tools for BigQuery and AlloyDB, the coding assistants hallucinate column names because they cannot see the live cloud database schemas from inside the IDE or terminal!
A developer asks a single chat thread to search, read, and refactor all 60 files at once. By File 25, the context window fills with raw search logs (context rot), causing the assistant to forget the original goal and break earlier imports!
Developers use “one-shot prompting” (“Rewrite the whole billing module”), resulting in massive unreviewable diffs that fail 40 unit tests!

1. Key Concept Definitions: Live Tooling & Multi-Agent Refactoring

1. IDE & CLI MCP Integration

Connects Google Antigravity, Gemini CLI, and Claude Code to local/remote Model Context Protocol (MCP) servers so the agent queries live DB schemas, Cloud Logging traces, and Jira tickets directly.

2. Context Rot (Context Pollution)

The degradation in reasoning and instruction-following accuracy that occurs when a single conversation thread accumulates tens of thousands of tokens of raw search hits, file reads, and stack traces.

3. Subagent Task Decomposition

Cures context rot by delegating codebase exploration, module coding, and test verification to specialized Subagents that run in isolated context windows and return only concise summaries.

4. Spec -> Plan -> Act -> Verify Loop

Replaces risky one-shot prompting with a 4-phase engineering discipline: author a Specification, review and approve the Plan before coding, apply incremental edits (Act), and run automated tests (Verify).

2. Interactive Switcher: MCP Developer Tooling, Subagents & Plan-Act-Verify

Switch between the 3 Agentic Coding Workflows below and click the 3 stages in each view to see how MCP Tooling, Subagent Context Isolation, and Spec-Driven Plan-Act-Verify Loops operate across Antigravity, Gemini CLI, and Claude Code:

MCP STAGE 1: DECLARATIVE WORKSPACE CONFIGURATION

1. Registering Read-Only MCP Servers in the IDE & CLI

How It Works

Teams register approved MCP servers in their version-controlled workspace settings using environment-variable placeholders and least-privilege credentials.

Core Architecture Rule

Scope developer IDE/CLI MCP servers strictly to read-only metadata or non-production sandboxes so coding agents cannot mutate production tables!

3. Refactoring & Tooling Matrix: Naive Prompting vs. Spec-Driven & Subagent Workflows

Compare AI-assisted engineering methodologies across Google Antigravity, Gemini CLI, and Claude Code on Google Cloud:

Engineering Dimension	Naive One-Shot Prompting (Anti-Pattern)	Spec -> Plan -> Act -> Verify Loop (Best Practice)	Subagent Task Decomposition (Scale Pattern)
How It Operates	Developer asks the agent to rewrite an entire feature in one massive prompt without a plan.	Agent generates a written Spec & Plan first; human reviews it; agent edits incrementally and runs tests.	Root agent delegates search, coding, and testing to specialized subagents with isolated context windows.
Context Window Health	Severe Context Rot: Raw search hits, failed edits, and stack traces bloat the single thread.	Clean & Controlled: Scoped to the active milestone in the approved implementation plan.	Maximum Isolation: Verbose search and test logs stay inside ephemeral subagent contexts!
Live Cloud & Schema Awareness	Relies on static training data or manual copy-pasting of schemas/logs.	Queries MCP servers (BigQuery, AlloyDB, Cloud Docs) during the Plan phase to verify schemas.	Dedicated Explorer/Verifier subagents invoke read-only MCP tools to validate schemas and logs.
Primary Architectural Trigger	Avoid this pattern on complex multi-file features.	“Prevent architectural drift before coding,” “ensure every edit passes unit tests and linters.”	“Refactor 50+ files without context overflow,” “run parallel module updates across a monorepo.”

4. Real-World Deep Dive: Subagent Isolation, Confirmation Bias & MCP Security

Architect Question	How It Works Under the Hood in Production
“Why does a coding assistant start forgetting instructions or breaking imports on File 25 of a 50-file refactoring even if the model has a 200k–1M token context window?”	Attention Dilution & Context Rot: As a single conversation thread fills with 30,000+ tokens of raw `grep` matches, old file versions, and stack traces, intermediate noise competes with your core instructions. Spawning an Explorer Subagent (to return only a 15-line file map) and scoped Implementer Subagents gives each task a fresh, noise-free context window!
“Why shouldn’t the exact same coding agent thread both write a security-critical payment module and perform the final security audit on its own code?”	Self-Justification (Confirmation) Bias: When an LLM sees its own prior reasoning steps in the same context window, it tends to justify the assumptions it already made. Spawning an independent Reviewer/Verifier Subagent that receives only the written specification and the `git diff` eliminates confirmation bias!
“How should we share MCP server configurations (like BigQuery and Cloud Logging MCP servers) across 50 developers on a Git repo without committing credentials?”	Sanitized Workspace Config + Environment Placeholders: Commit the declarative MCP server configuration file to the repository using environment variable references (e.g., `$DEV_PROJECT_ID` or local ADC credentials) and scope developer IAM roles strictly to read-only metadata/logs in non-production!