Stitch MCP beside Sume MCP: design a screen, then film the launch

Google Stitch's MCP setup lists an X-Goog-Api-Key header or OAuth. Sume's hosted MCP takes OAuth or a bearer key. How to run both in one coding agent.

5 min readSume
All posts

Stitch and Sume are two separate remote MCP servers, and one coding agent can hold both: Stitch to design the screens, Sume to turn the finished design into a launch video. Stitch's MCP setup page lists an X-Goog-Api-Key header or OAuth for authentication; Sume's hosted server at https://mcp.sume.com/mcp accepts OAuth or an API key. Keep the credentials apart, because neither one is valid on the other server.

This post uses Stitch's MCP setup page for its auth options and Sume's MCP OAuth and API keys and MCP quickstart for the rest, all read on 2026-10-03. The Stitch page loads thinly for automated readers, so check its own tool list in your client before relying on any tool name.

Two servers, two credentials

Both servers are configured as separate entries in your client's MCP config, each with its own URL and its own auth. A Stitch key goes in the X-Goog-Api-Key header of the Stitch entry. A Sume key goes in Authorization: Bearer or x-api-key on the Sume entry. Sume's docs are explicit that an MCP OAuth token is not a Sume API key, and that you should not store OAuth tokens in config or paste them into prompts.

Auth options on each server (read 2026-10-03)
ServerEndpoint sourceHeader or flowNotes
StitchIts MCP setup pageX-Goog-Api-Key, or OAuthTool names are listed on the vendor page
Sumehttps://mcp.sume.com/mcpAuthorization: Bearer or x-api-key, or OAuthOAuth default is mcp:read; Write is opt-in

Where each server stops

Stitch is a design tool; Sume does media. The seam is a file or a URL. Export or screenshot the finished screens, host them at a public HTTPS address, and hand those URLs to Sume. Hosted MCP cannot read files from your laptop, and on remote MCP the upload URL from assets_upload_url comes back redacted, so a local PNG should sit at a public HTTPS URL first.

From there the Sume side is the usual sequence: generate_image or generate_video with the screens as references, then jobs_wait in slices up to 55 seconds, then jobs_result. Paid tools need mcp:write or an API key, an idempotency_key, and ideally a dry_run=true pass first.

Keep design access separate from spend

The simplest split is by session. Connect Sume over OAuth with Write off while the agent is still designing; it can read the catalog, balance and jobs but cannot submit paid work. When the design is approved, reconnect with Write on, or hand the video step to a separate session that has it. A read-only token sees read-only tools, and a paid call returns insufficient_scope instead of spending.

If the same agent must do both, put a spend ceiling in its instructions: call generation_admission_preview or dry_run first, pass max_spend_usd, and stop on the first 402. The server only enforces max_spend_usd when you send it, so the instruction is the control.

A checklist for the combined setup

Run tools_list on each server and confirm neither exposes a tool name the other also uses, because a collision makes the agent guess. Call Sume's mcp_health and confirm the auth source. Write both servers' URLs into the project config and keep both keys in environment variables, never in the repo.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume