Google Stitch MCP — AI Design via Model Context Protocol

What it is

Stitch MCP is a remote Model Context Protocol (MCP) endpoint used by the “Stitch extension for Gemini CLI”. It enables an MCP-capable client to interact with Stitch—Google’s UI/UX design and code-generation product—through tool calls instead of manual clicking in a web UI.

TokRepo curates this workflow as an “MCP design integration” pattern: you configure an MCP server URL, provide authentication, then use your AI tool’s built-in MCP features to discover and call Stitch tools. The result is that a conversational assistant can plan and execute design-related steps (list projects, inspect screens, download assets, generate screens from prompts) as structured operations.

This matters because design workflows often need repeatable steps that are hard to keep consistent across a team. With MCP, you can turn those steps into an auditable tool sequence: your assistant issues explicit tool calls, and you can review inputs/outputs. In other words, it is not just “chat about design” — it is “design operations as tools.”

From a systems perspective, the Stitch extension is also a reference implementation for “MCP over HTTP with headers.” It shows how an AI tool can connect to a remote server URL and pass credentials via request headers, then treat the server’s capabilities as a set of tools. If you are building your own MCP integrations, this workflow is a useful template: auth, transport, discovery, then a set of narrowly-scoped operations.

How it saves time or tokens

Without MCP, teams typically do one of two things:

1. Copy/paste screenshots, long HTML snippets, or design descriptions into chat prompts and hope the model infers the right structure.
2. Use the design UI manually, then ask the model to help afterward (naming, copywriting, refactoring code) with limited connection to the design artifacts.

MCP changes the economics. If your assistant can call tools, it does not need you to paste large artifacts repeatedly. Instead, the assistant can fetch exactly what it needs (project list, screen metadata, an exported asset) at the moment it needs it. That typically reduces token waste and reduces the number of “retry” prompts caused by incomplete context.

There is also a workflow quality benefit: structured tool calls are less ambiguous than free-form chat. When you say “download the assets for screen X,” a tool call can produce a deterministic output (files, IDs, metadata). That makes downstream tasks—like generating code, writing documentation, or producing a changelog—more reliable because the assistant is grounded in the actual artifacts.

Finally, MCP makes onboarding easier. Instead of documenting a long set of click-path instructions in an internal wiki, you can document one configuration and a small set of “starter commands” (list tools, describe tools, list projects). New team members can validate their setup quickly and learn the surface area by exploration rather than by memorizing UI steps.

MCP also helps you avoid “prompt inflation.” When teams struggle to get consistent results from chat-only design prompts, the natural response is to add more instructions: more constraints, more examples, more formatting rules, more context. Tool-driven workflows shift that complexity into structured parameters. Your prompt can stay focused on intent (what you want), while the tool schema carries the details (IDs, asset formats, output types).

If you care about governance, tool calls are easier to review than free-form chat. You can log: which project was accessed, which screen was retrieved, which assets were downloaded, and which prompts were used to generate new screens. This is valuable when you need to explain how an output was produced or reproduce a design decision later.

In day-to-day work, the most common “wins” look like this:

• A developer asks for a draft screen layout for a feature, then the assistant generates a starting point and exports assets for implementation.
• A designer wants quick variations of a landing page section (hero, pricing table, signup flow), and the assistant iterates using short prompts rather than repeated manual edits.
• A team treats Stitch as a design “backend”: assets and screen metadata become inputs into a broader automation (documentation, changelog notes, implementation tickets).

These scenarios benefit from structured operations. You can keep the human review step (does the design make sense?) while automating the mechanical parts (fetching the right project, downloading the right assets, keeping everything organized under run folders).

How to use

1. Install the Stitch extension for Gemini CLI (or otherwise configure your MCP client to talk to the Stitch MCP server).
2. Set up authentication (API key is the simplest path; ADC is available for environments that need Google Cloud credentials).
3. Start your client and run tool discovery (/mcp list and /mcp desc) to verify Stitch tools are available.

If you are doing this for a team, add two operational rules:

• Do not check secrets into config files. Store API keys in environment variables or your secret manager and inject them into headers.
• Standardize one auth method per environment. Mixing API key and ADC across machines makes debugging harder.

You should also treat tool discovery as a mandatory preflight. MCP servers evolve. The safest way to automate is to (a) list tools, (b) read tool descriptions, and (c) run a minimal end-to-end call before you script a bigger workflow.

If your environment requires Google Cloud credentials, the upstream repository describes an ADC-based path using gcloud and a project configuration step. The key operational idea is the same: keep credentials out of repo files and make auth explicit. Whether you choose API key auth or ADC, validate with a small call first (for example, list projects) before running any workflow that creates or modifies design assets.

Example

# Install the Stitch extension for Gemini CLI (auto-update)
gemini extensions install https://github.com/gemini-cli-extensions/stitch --auto-update

# In Gemini CLI, list MCP tools and descriptions
/mcp list
/mcp desc

{
  "mcpServers": {
    "stitch": {
      "url": "https://stitch.googleapis.com/mcp",
      "headers": {
        "X-Goog-Api-Key": "YOUR-API-KEY"
      }
    }
  }
}

When you move beyond experimentation, keep your automation small and composable. For example: a command that lists projects, a command that retrieves screens for a chosen project, and a command that downloads assets. Compose these steps rather than trying to “do everything in one prompt,” because tool-driven workflows are easier to debug when each step has a clear input/output.

Here is a safe “first automation” pattern many teams use:

1. Discovery: list tools and read descriptions.
2. Read-only validation: list projects and fetch metadata for one project.
3. Asset retrieval: download a single screen asset and store it under a run folder.
4. Only then: attempt generation or edits, one change at a time.

This staged approach matters because design operations can have side effects. By forcing a read-only warmup, you reduce the chance of a misconfigured client generating unwanted assets or modifying the wrong project.

If you are collaborating across roles, keep the workflow explicit: engineers handle configuration and secret management, designers review outputs and decide what to keep. The assistant sits in the middle, executing repeatable tool steps and documenting results.

That clarity prevents confusion.

Related on TokRepo

• AI tools for design — Other design-focused workflows and tooling patterns.
• MCP GitHub integration — Another MCP configuration pattern (server URL, auth, tool discovery).

Common pitfalls

• Mixing auth methods without documentation. Decide whether your environment uses API keys or ADC and write it down.
• Leaking secrets. Never commit API keys into dotfiles that are checked into repos; prefer environment variables or secret managers.
• Skipping tool discovery. Always list and describe tools first; do not guess tool names or parameters.
• Over-automating too early. Start with a minimal, safe workflow and scale up after you have evidence of reliability.
• No audit trail. Save tool call inputs/outputs with your agent run so you can reproduce decisions and debug changes.

Design-specific pitfalls are also common:

• No naming conventions: if the assistant creates screens with inconsistent names, your project becomes hard to manage. Provide a naming rule in your prompt or workflow.
• Unclear “definition of done”: decide whether the goal is a usable design variant, exported assets, or code-ready output. Different goals imply different tool sequences.
• Assuming generated output is production-ready: treat generated screens as drafts. Review, iterate, and keep a human-in-the-loop step where it matters.