list_screens returns empty after generate_screen_from_text until project is opened in browser

Stitch
,
1

Screens generated via the Stitch MCP generate_screen_from_text are not queryable through list_screens or get_screen until the project is manually opened in a browser. This breaks automated MCP workflows.

Reproduction:
1. create_project → success
2. generate_screen_from_text → completes without error
3. list_screens → returns {} (empty)
4. get_project → returns valid data including thumbnailScreenshot.downloadUrl (screen exists server-side)
5. Retry list_screens after 25+ seconds → still empty
6. Open project in browser (Stitch - Design with AI)
7. list_screens → screen appears immediately

Observations:
- The screen is generated — get_project exposes its thumbnail. But list_screens cannot see it.
- Time does not resolve it — retried over 25 seconds, no change.
- Unauthenticated curl to the project URL does not help either.
- A single authenticated browser visit instantly makes the screen available via MCP.

Impact:
Any automated pipeline following generate → list → get → download requires manual browser intervention per screen. This breaks end-to-end MCP automation for AI coding tools (Claude Code, Cursor, Gemini CLI, etc.).

Environment: Claude Code CLI, macOS, official Stitch MCP server, GEMINI_3_FLASH, device type MOBILE.

2

Hi @ThisIsSadeghi thank you for bringing this to our attention. We sincerely apologize for the inconvenience. This confirms a state synchronization latency between the Stitch generative backend and the MCP API layer, specifically where the list_screens index remains stale until an authenticated browser session triggers a final commit. We have logged this as a high-priority bug affecting automated MCP workflows

1 Like
3

Hello @Nilesha_U_J, Thanks for the clarification. How will I be notified once this issue is resolved?

4

Hey @ThisIsSadeghi thanks for your input! We’ll include an update in our next release and I’ll post back here as soon as it’s available.