google-labs-code/stitch-sdk
Summary
stitch-sdk is a TypeScript SDK that wraps Google's Stitch MCP (Model Context Protocol) server, letting you programmatically generate UI screens from text prompts, then extract their HTML and screenshots via download URLs. It provides a high-level fluent API (Project/Screen classes), a low-level tool client for direct MCP tool calls, and a Vercel AI SDK integration so LLMs can autonomously call Stitch tools in agentic workflows.
Great for
building AI-powered UI generation pipelines — specifically people who want to programmatically create, iterate, and export web UI designs using LLM prompts, or wire Stitch into agentic workflows via Vercel AI SDK or custom MCP orchestration
Easy wins
- +Add TypeScript type exports for DeviceType, CreativeRange, and VariantAspect enums — they're documented in the README as string literals but not exported as proper union types from the package
- +The `getHtml()` fallback returns an empty string on missing data (verified in sdk.test.ts) but doesn't log a warning — add a console.warn or throw a more descriptive StitchError with a specific code like MISSING_DATA
- +Write integration test fixtures: the e2e-test.ts and smoke-test.ts exist but are opaque without seeing them — contributing mock-based integration tests for StitchProxy (the MCP proxy server) appears completely untested in the visible test files
- +Improve the StitchProxy class documentation — it appears in the API reference table but has zero test coverage visible in the test directory and no example beyond the 4-line README snippet
Red flags
- !Only 1 unique commit and 1 active contributor despite showing 5 contributors and 1,309 stars — this pattern (high stars, minimal commit history) often indicates a recently open-sourced internal tool that may not have an active external contribution workflow yet
- !The .github/workflows directory contains several 'fleet-*' workflow files (fleet-analyze, fleet-dispatch, fleet-label, fleet-merge) alongside a jules-merge-conflicts workflow — these appear to be Google-internal automation tools that may silently affect PRs from external contributors in unexpected ways
- !All generated source files in packages/sdk/generated/src/ are auto-generated and committed to the repo — contributing to the SDK surface requires understanding the code generation pipeline, not editing those files directly, which is non-obvious and not prominently documented in CONTRIBUTING.md
- !getHtml() and getImage() return download URLs, not actual content — this is documented but easy to miss, and calling fetch() on expired URLs is not handled by the SDK at all
Code quality
The generate-sdk.ts code generator is genuinely impressive — it validates JSON Schema projections via resolveRef/validateProjection, emits deterministic TypeScript via ts-morph, and handles flatMap chains for nested projections with thoughtful edge cases. Unit tests in sdk.test.ts and client.test.ts are thorough: they cover cache hit/miss paths, concurrent connect() race conditions, and typed error codes (AUTH_FAILED, RATE_LIMITED, NOT_FOUND). One real concern: error classification in client.test.ts uses string-matching heuristics on error message text (e.g. checking for 'project not found' or '401' substrings) which is brittle against backend message changes.
What makes it unique
This is the official SDK for a specific Google product (Stitch, a Gemini-powered UI generation service), so there's no real alternative or competing implementation — it's either this or raw MCP protocol calls. The code generation pipeline (capture tools manifest → IR schema → ts-morph codegen) is an interesting architectural pattern worth studying for anyone building SDKs over MCP servers. The Vercel AI SDK integration via stitchTools() is a clean design that other MCP-backed SDKs could emulate.