stitch-mcp-stdio
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STITCH_API_KEY | Yes | Your Stitch API key. Get it from stitch.withgoogle.com -> Profile -> Settings -> API Key. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_projectA | Creates a new Stitch project. A project is a container for UI designs and frontend code. |
| get_projectA | Retrieves the details of a specific Stitch project using its project name. |
| delete_projectA | Deletes a specific Stitch project using its project name. Instructions for Tool Call:
|
| list_projectsA | Lists all Stitch projects accessible to the user. By default, it lists projects owned by the user. |
| list_screensA | Lists all screens within a given Stitch project. |
| get_screenA | Retrieves the details of a specific screen within a project. |
| generate_screen_from_textA | Generates a new screen within a project from a text prompt. Instructions for Tool Call:
Output:
|
| edit_screensA | Edits existing screens within a project using a text prompt. Instructions for Tool Call:
|
| generate_variantsA | Generates variants of existing screens within a project using a text prompt. Instructions for Tool Call:
|
| upload_design_mdA | Uploads DESIGN.md to a Stitch project. Use this tool when the user wants to create a design system from a DESIGN.md file. Instructions for Tool Call:
|
| create_design_systemA | Creates a new design system for a project. Use this tool when the user wants to set or update the overall visual theme, style, or branding of the application. This includes configuring:
Instructions for Tool Call:
|
| create_design_system_from_design_mdA | Creates a design system for a project, with user uploaded DESIGN.md file, and displays the design system in the UI. Instructions for Tool Call:
|
| update_design_systemA | Updates a design system for a project. Use this tool when the user wants to change the overall visual theme, style, or branding of the application. This includes configuring:
|
| list_design_systemsA | Lists all design systems for a given project. |
| apply_design_systemA | Applies a design system to a list of screens. Use this tool when the user wants to update one or more screens to match the style of a design system. This tool applies the selected design system's foundational design tokens (colors, fonts, shapes, etc.) to the chosen screens, modifying their appearance to align with the design system. |
| download_assetsC | Download screens and assets to a local directory |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools target distinct resources and actions (projects, screens, design systems, assets), making selection relatively straightforward. However, create_design_system and create_design_system_from_design_md overlap in purpose, and edit_screens vs generate_variants could be confused since both modify existing screens.
Tool names consistently follow a verb_noun pattern (create_project, get_screen, list_design_systems, apply_design_system, etc.). Even longer names like create_design_system_from_design_md and generate_screen_from_text follow the same predictable structure.
At 16 tools, the server is slightly large but still well-scoped across four coherent areas: projects, screens, design systems, and assets. A few tools could be consolidated (e.g., upload_design_md and create_design_system_from_design_md are tightly coupled), but the count is reasonable for the domain.
The core workflows are covered: project CRUD, screen listing/retrieval/generation/editing, and design system create/update/list/apply. Minor gaps include no delete for screens or design systems and no project update tool, but these are workable and not likely to cause major agent failures.