Combining Google Stitch with the GitHub Copilot Coding Agent

UI generation and background coding agents are two of the "AI" tools that really changed my way of working. Together, they close a gap that's been annoying me for a while: the coding agent still needs someone to describe what the UI should look like, and that someone is usually me, typing a wall of text into an issue and hoping for the best.

Google Stitch generates UI screens (HTML/CSS, Tailwind, Flutter, SwiftUI, whatever…) from a prompt or a sketch. The GitHub Copilot coding agent picks up an issue and produces a pull request in the background, without you sitting in the editor. In this post we look at how to connect the two through MCP, so the coding agent stops guessing at layout, spacing and colors, and starts reading an actual design spec.

Here's how to wire it up, and where it still needs a human in the loop.

My first approach: screenshots in the issue body

My first attempt was to design something in Stitch, paste a screenshot into a GitHub issue, and assign it to Copilot. It kind of works. The coding agent can look at the image, but it's reconstructing layout, colors and spacing from pixels, not from data. You'll get something that looks close, then spend your review cycle nudging padding and hex codes back into alignment. That's not the coding agent's fault — it's just working with less information than it needs.

The right approach: give the agent the design data, not a picture of it

Stitch doesn't just produce a picture. Alongside the generated screens it exposes the underlying HTML, design tokens and a design.md file describing the whole design system — colors, typography, spacing, component patterns. If the coding agent can pull that structured data itself, it stops guessing.

That's what the Stitch MCP server is for. Point the coding agent at it, and instead of an issue that says "make it look like the attached screenshot," you get an issue that says "build the dashboard screen from the Stitch project, screen ID X" — and the agent fetches the real spec.

Step 1: Design the screens in Stitch

Nothing unusual here — describe the flow in Stitch the way you normally would.

Stitch can generate several connected screens in one pass and keeps them visually consistent. Note the project ID and screen IDs — you'll reference them later.

Step 2: Register the Stitch MCP server on the repository

The coding agent runs headless in the cloud, and it doesn't support remote MCP servers that use OAuth. So skip the gcloud auth login dance for this scenario and use Stitch's official remote MCP server with an API key instead — it's a plain HTTP header, not an OAuth flow, and the cloud agent handles that fine.

Generate a key: in Stitch, open your profile menu → Stitch Settings → API Keys → Create Key.

Store it as a repository secret prefixed with COPILOT_MCP_ (this prefix is required for the coding agent to pick it up): go to Settings → Secrets and variables → Actions, add COPILOT_MCP_STITCH_API_KEY.

Then in the repository: Settings → Copilot → MCP servers, and add:

json

{
  "mcpServers": {
    "stitch": {
      "type": "http",
      "url": "https://stitch.googleapis.com/mcp",
      "headers": {
        "X-Goog-Api-Key": "$COPILOT_MCP_STITCH_API_KEY"
      },
      "tools": ["*"]
    }
  }
}

Save it. This same MCP configuration is also shared with Copilot code review, so your reviewer agent gets access to the same design context.

A couple of things worth knowing before you rely on this:

• The coding agent only supports MCP tools, not resources or prompts, so anything the Stitch server exposes as a resource won't show up.
• By default the agent doesn't get write-access MCP tools. Stitch's tools here are all reads (fetch screens, fetch code, fetch design tokens), so that's not a problem — but double-check the tool list if you add other design-related MCP servers later.

Step 3: Write the issue against the design, not around it

With the MCP server registered, an issue can now point straight at the Stitch project instead of re-explaining the design in prose:

Implement the dashboard screen from Stitch project 7-minutes fitness trainer, screen dashboard. Use the Stitch MCP tools to fetch the HTML and design tokens, then build it as a React + Tailwind component under src/components/Dashboard. Match spacing and color tokens exactly. Existing repo conventions apply — see CONTRIBUTING.md.

Assign it to Copilot. The agent fetches the screen HTML and design tokens through the MCP tools, translates that into your actual stack, and opens a draft pull request. Because the GitHub MCP server is also available by default, it can cross-reference the issue and push commits as it goes, same as any other coding agent task.

Step 4: Review like you would any other PR

The generated code won't be pixel-perfect — code generation from a design spec still isn't deterministic, and you'll see small deviations in spacing or font-weight here and there. Treat the Stitch screen as the source of truth and the PR as a first draft, not a final one. If your repo has the Playwright MCP server enabled (it's on by default alongside GitHub's), you can ask the agent to take a screenshot of the rendered component and compare it against the Stitch export as part of the same task — closes the loop without you doing it manually.

Wrapping up

The interesting part isn't that AI can generate a screen or that AI can write a pull request — both have been true for a while. It's that MCP lets the coding agent read the actual design data instead of a description of it, which is the difference between "close enough" and "matches the spec."

More information

• Stitch: stitch.withgoogle.com
• Stitch MCP setup docs: stitch.withgoogle.com/docs/mcp/setup
• GitHub Docs - Configure MCP servers for your repository: docs.github.com
• GitHub Docs - MCP and Copilot coding agent: docs.github.com