Stitch MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STITCH_HOST | No | Override the Stitch API endpoint URL (default: https://stitch.googleapis.com/mcp). Optional. | |
| STITCH_API_KEY | No | Google API key for Stitch access. One of STITCH_API_KEY or STITCH_ACCESS_TOKEN is required. | |
| STITCH_ACCESS_TOKEN | No | OAuth2 access token. One of STITCH_API_KEY or STITCH_ACCESS_TOKEN is required. | |
| GOOGLE_CLOUD_PROJECT | No | GCP project ID for billing (used with Bearer auth). Optional. |
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 |
|---|---|
| list_projectsA | Lists all Stitch projects accessible to the authenticated user. |
| get_projectB | Gets details of a specific Stitch project. |
| list_screensB | Lists all screens in a Stitch project. |
| get_screenA | Gets details of a specific screen including download URLs. |
| generate_screen_from_textC | Generates a new screen from a text prompt describing the desired UI. |
| edit_screensC | Edits one or more existing screens based on text instructions. |
| generate_variantsC | Generates design variants of an existing screen. |
| get_screen_codeA | Retrieves the HTML code content of a screen. Returns the raw HTML that can be used for code generation or analysis. |
| get_screen_imageA | Retrieves the screenshot/preview image of a screen as base64-encoded PNG. |
| build_siteA | Builds a site from a Stitch project by mapping screens to routes. Returns the design HTML for each page to use as context for code generation. |
| list_toolsA | Lists all available tools with their descriptions and input schemas. |
| get_workspace_projectA | Checks if there is an existing Stitch project associated with the current workspace/folder. Returns project info if found, or null if no project is set. Use this at the start of a session to check for existing projects. |
| set_workspace_projectA | Associates a Stitch project with the current workspace/folder. The project info is stored in .stitch-project.json in the current directory. |
| clear_workspace_projectA | Removes the Stitch project association from the current workspace/folder. |
| extract_design_contextA | Extracts design DNA from an existing screen — colors, typography, spacing, layout patterns, and component styles. Use this to maintain visual consistency across multiple screens. |
| apply_design_contextB | Generates a new screen using a previously extracted design context for visual consistency. |
| generate_design_tokensC | Generates design tokens (CSS variables, Tailwind config, SCSS, or JSON) from a screen's design. |
| generate_responsive_variantB | Creates a responsive variant of an existing screen for a different device type while maintaining the same design language. |
| batch_generate_screensB | Generates multiple related screens in a single operation with consistent design language. |
| generate_from_templateC | Generates a screen from a predefined UI template with user customizations. Provides 10 common templates (dashboard, settings, login, profile, pricing, landing-hero, data-table, kanban-board, chat-interface, file-manager) as a base prompt, layered with custom instructions for faster UI generation. |
| analyze_accessibilityA | Analyzes a screen for WCAG 2.1 accessibility compliance. Checks color contrast, text sizes, touch targets, semantic structure, and provides actionable recommendations. |
| compare_designsC | Compares two screens to identify design differences, inconsistencies, and suggest harmonization opportunities. |
| extract_componentsB | Extracts reusable UI component patterns (buttons, cards, forms, inputs) from a screen with their styles and variants. |
| design_diffA | Compares two screens by name and returns a structured diff showing added elements, removed elements, style changes, and text changes. Useful for tracking design iterations. |
| generate_style_guideB | Generates a comprehensive style guide / design documentation screen from an existing design. Creates a visual reference of colors, typography, components, and usage guidelines. |
| export_design_systemB | Exports a complete design system package from project screens including tokens, components, documentation, and assets. Ready for developer handoff. |
| suggest_trending_designB | Suggests and applies modern UI/UX design trends to a screen prompt. Includes glassmorphism, bento-grid, gradient meshes, micro-interactions, and more. |
| export_all_screensA | Exports all screens from a Stitch project. Fetches each screen's HTML code and screenshot, returning a complete project export as structured data. Useful for backing up or migrating designs. |
| screen_to_reactA | Converts a Stitch screen's HTML into a clean React/TSX function component with a typed props interface, Tailwind CSS classes extracted from inline styles where possible, and proper imports. Returns usable React code ready to drop into a project. |
| screen_to_plane_issueA | Creates a structured output from a Stitch screen suitable for creating a Plane (or similar PM tool) issue. Includes a title derived from the screen name, a description with the design preview as base64 image, an implementation checklist extracted from HTML components, and suggested labels. Bridges the Stitch-to-project-management workflow. |
| screen_to_tailwind_configA | Extracts a complete tailwind.config.ts from a screen's design. Analyses colors, fonts, spacing scale, border radii, shadows, and breakpoints to produce a ready-to-use Tailwind CSS configuration object. |
| screen_to_css_variablesA | Extracts CSS custom properties (variables) from a screen's design. Produces a complete :root block with semantic naming for colors, typography, spacing, shadows, and border radii. Supports optional dark-mode variable overrides. |
| validate_design_systemA | Validates whether a screen follows a given design token set. Checks colors, fonts, spacing, and border-radii against approved values and reports violations, compliance percentage, and suggestions for fixes. |
| generate_dark_modeA | Takes a light-mode screen and generates a dark-mode variant. Analyses the existing color palette and instructs Stitch to regenerate with inverted brightness, adjusted contrast, and preserved brand accents. |
| generate_component_variantsA | Analyses a screen to identify a target component (button, card, hero, form, navigation) and generates multiple visual variants of it as separate screens. Useful for A/B testing or building component libraries. |
| project_summaryA | Returns a high-level summary of a Stitch project: screen count, list of screens with names, detected common patterns, design consistency score (based on color/font overlap across screens), and device type distribution. |
| create_projectA | Creates a new Stitch project. A project is a container for UI designs and frontend code. |
| delete_projectA | Deletes a specific Stitch project using its project name. 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. |
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 44 tools
Numerous tools overlap significantly: generate_screen_from_text, edit_screens, generate_variants, batch_generate_screens, generate_from_template, generate_responsive_variant, generate_dark_mode, generate_component_variants, apply_design_context, and suggest_trending_design all involve creating or modifying screens with subtle differences. Similarly, create_design_system and update_design_system are almost identical in description, and generate_design_tokens, screen_to_tailwind_config, screen_to_css_variables, export_design_system, validate_design_system overlap in token extraction. This makes it difficult for an agent to pick the right tool.
Most tools follow a clear verb_noun pattern (e.g., list_projects, create_project, generate_screen_from_text). There are a few deviations like design_diff, project_summary, and screen_to_react, but these are still understandable and don't break the overall pattern. The naming is mostly predictable and systematic.
With 44 tools, the server far exceeds the 25+ threshold that typically indicates an excessive count. Even for a complex design tool, this many tools creates cognitive load and makes discovery and selection harder. A leaner set with clearer boundaries would be more appropriate.
The tool surface covers a wide range of design workflows: project CRUD, screen listing/generation/editing, design system management, exports, conversions, and analysis. Minor gaps exist (e.g., no delete_screen, no direct screen rename), but for the core purpose of UI generation and design system management, the set is fairly comprehensive and rarely leaves dead ends.