Stitch MCP Server with DeepSeek Harness

At a glance

Server

Google Stitch MCP (Stitch docs → MCP → Setup & Authentication)

Endpoint

https://stitch.googleapis.com/mcp

Transport

Remote MCP over streamable HTTP

Authentication

X-Goog-Api-Key header with a key created in Stitch settings; the setup page also documents a Google Cloud SDK OAuth path

Install needed

None for the hosted server

Tool surface

Projects, screens, generation and editing, and design systems (per the setup page's tool reference)

Independent helper

@_davideast/stitch-mcp — a separate Apache-2.0 CLI that proxies Stitch tools, labelled experimental and unaffiliated with Google by its own author

DSH fit

Direct — streamable-HTTP row with the API key header

Last checked

2026-10-13

Step 1 — Create a Stitch API key

In Stitch, open your profile menu, go to Stitch settings, and create an API key under the API key section of the setup docs. Copy it once and keep it out of version control: the key itself is the whole security story for this endpoint.

Step 2 — Add the DSH row

# cordis.patch.yml — passed with: dsh web --patch ./cordis.patch.yml
- insert:
    - id: mcp-stitch
      name: '@deepseek-ai/dsh-mcp-client'
      config:
        serverName: stitch
        transport: streamable-http
        url: https://stitch.googleapis.com/mcp
        headers:
          X-Goog-Api-Key: YOUR_STITCH_API_KEY

Keep the header name exactly as the setup page writes it. The patch row id and serverName must be unique among live clients, because the tool namespace is built from the server name: mcp__stitch__<tool>.

To keep the row, merge it into $DSH_HOME/profiles/<name>/cordis.patch.yml or the machine-wide $DSH_HOME/cordis.patch.yml rather than passing a patch file every time.

Step 3 — Raise the per-call timeout before you generate

The MCP client config carries a per-call timeout (toolCallTimeoutMs) alongside reconnection settings. The tools that create or edit screens are the slow ones: a third-party write-up of the tool list states that Google's own tool descriptions warn generation and edit calls “can take a few minutes”. When a client timeout ends the wait, the job on the server side does not stop — so the agent can report a failure on work that is still running, retry, and spend a second generation. Set a timeout you are comfortable waiting out before you ask for a screen.

The timeout guidance is a reported risk, not something we measured: we did not run a generation against a Stitch account.

Verify with a read-only call

1. dsh --profile web --dump-config and confirm the mcp-stitch row is in the booted tree.
2. Prompt: “Use the stitch tools to list my projects and return the result as-is. Do not generate or modify anything.”
3. Reserve generation prompts for work you intend to spend quota on. The first prompt after boot may need to wait for asynchronous tool discovery.

Troubleshooting

The tool list is empty after boot

Discovery is asynchronous, so give it a moment and reload. Also confirm the row id and serverName do not collide with another server, and that the YAML indentation survived your editor.

“Authentication failed” from the server

Regenerate the key in Stitch settings and re-check the header name. One third-party guide reports Stitch API tokens expiring after 90 days as of mid-2026; we did not confirm an expiry policy on Stitch's own setup page, so verify that before designing around it.

“Permission denied” on the OAuth path

A third-party note ties this to a project that lacks billing, the required role, or the Stitch API enabled. If you took the API-key path in step 1, this does not apply to you.

A generation call reported failure but the screen appeared later

That is the timeout behaviour described in step 3. Raise the per-call timeout and avoid blind retries, which can consume two generations for one screen.

You expected an export tool

The reported tool list has no export-to-framework function: it covers projects, screens, generation, editing and design systems. The agent reads the screen and writes your React or Flutter code itself, so output quality tracks the agent more than the server.