Google Stitch MCP examples for the Dev with Bebz ChatGPT MCP workshop
Server has 8 tools with explicit registration, Zod schemas, and tool annotations. Naming follows verb_noun convention (list_, create_, pull_, start_, job_). Descriptions are present (avg ~120 chars) but lack actionable context for LLM selection. Input schemas use Zod with type constraints, but parameter descriptions are minimal (avg ~30 chars). Output schemas are not documented. Error handling exists but lacks recovery guidance. Security: API key properly injected via environment; no secrets in parameters. Composition is reasonable, tools chain logically (start_generate → job_status → job_result). Major gaps: parameter descriptions do not explain constraints, formats, or dependencies; output structures undocumented; no pagination guidance for list tools.
Create a Google Stitch project. This is normally a quick synchronous operation.
Return the completed result of a Stitch async job. If still running, returns the current status instead.
Check a Stitch async job. Returns queued, running, completed, or failed.
List recent local async Stitch jobs, newest first.
List Google Stitch projects owned by the API-key account.
List screens in a Stitch project, including artifact metadata and download URLs when available.
Parameter descriptions are minimal (avg 30 chars). 'Project ID', 'Job ID (UUID)', 'limit' lack context on format, range, or when to use. LLMs cannot infer constraints from names alone.
Output schemas are not documented. Tools return text via textResult() but LLMs cannot plan downstream calls without knowing response structure (fields, types, nesting). Breaks tool chaining.
stitch_list_projects and stitch_list_screens lack pagination parameters (limit, offset, cursor). Large result sets will blow context window. No guidance on result limits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Find a Stitch project and screen by title, download its HTML and screenshot artifacts, and save them directly inside the local repository workspace. Use this instead of asking the user to download files manually.
Start a long-running Google Stitch generate_screen_from_text job in a detached worker and return a job_id immediately. Use stitch_job_status to poll it. Do not call generate repeatedly for the same request.
Error handling returns raw API responses or generic errors. No recovery guidance (e.g., 'Job not found. Check job_id or call stitch_list_jobs to find valid IDs'). Agents cannot self-correct.
stitch_start_generate accepts enum deviceType and modelId but descriptions do not explain when to use MOBILE vs TABLET vs DESKTOP, or GEMINI_3_FLASH vs GEMINI_3_1_PRO. LLMs will guess.