Zeplin

@Zeplin show me the latest design specs for the checkout flow screens in our mobile app project

Here are the current checkout flow screens from your Zeplin project: 1. Cart Review (v3.2) - Updated 2 days ago - Dimensions: 375×812px - Primary CTA: #FF6B35, 16px padding - Typography: SF Pro Display, 18pt semibold 2. Payment Method (v2.1) - Updated 5 days ago - Card input fields: 8px radius, #E5E5E5 border - Error states defined with #D32F2F 3. Order Confirmation (v1.8) - Updated 1 week ago - Success icon: 64×64px, #4CAF50 - Receipt layout uses 16px grid system Each screen includes exported assets, color tokens, and spacing measurements ready for implementation.

This example shows design handoff retrieval — the core workflow where developers pull implementation details from Zeplin. Requires read access to the specific project. The MCP would return structured spec data; exact format depends on what Zeplin's API exposes (colors, typography, measurements, asset URLs).

@Zeplin compare the button styles between our iOS and Android design systems and flag any inconsistencies

Comparing button components across platforms: **Inconsistencies found:** - Primary button height: iOS uses 48px, Android uses 56dp (material standard) - Corner radius: iOS 8px vs Android 4dp - Disabled state opacity: iOS 40%, Android 38% **Aligned properties:** - Primary color: Both use #007AFF - Font weight: Both use semibold (600) - Horizontal padding: Both use 24px/dp - Minimum touch target: Both meet 44px accessibility standard The height difference is intentional per platform guidelines, but the radius and opacity discrepancies may need design review.

This synthesis example shows the AI reasoning over design data from multiple Zeplin styleguides. Useful for design system audits and cross-platform consistency checks. Accuracy depends on how Zeplin structures component metadata — some details may require manual verification in the Zeplin UI.

@Zeplin add a comment on the login screen design asking about the password visibility toggle icon size for accessibility

Comment posted to Login Screen (v4.3) in the Mobile App project: "Question for design review: The password visibility toggle icon appears to be 20×20px. Should we increase this to 24×24px to meet the minimum 44×44px touch target guideline? Current implementation might be difficult for users with motor impairments to tap accurately. — Posted via Switchy on behalf of [your name]" The design team will receive a notification. You can track responses in Zeplin or wait for updates in this Space.

This write example demonstrates collaboration features — leaving feedback directly on designs without switching tools. Requires write permissions to the project. Be aware this creates a permanent comment in Zeplin visible to the entire team, so prompts should be clear and professional since they represent your voice in the design review process.

When Zeplin MCP bridges design-to-code for small product teams

A 5-person product team ships a new feature every two weeks. The designer updates screens in Figma, exports to Zeplin, and the two frontend engineers need specs during implementation. The Zeplin MCP lets the team pull measurements, color tokens, and asset URLs directly into Switchy threads without tab-switching. This works when your design system is stable and the engineers already know which screens they're building. If your team is still iterating on visual direction or the designer hands off raw Figma files, skip this—Zeplin adds a step. The OAuth2 flow means each engineer authenticates once, then the whole team shares access to the same project specs. Best fit: teams that treat Zeplin as the single source of truth for production-ready designs.

Using Zeplin MCP to compare shipped UI against approved mocks

A 3-person team (one designer, one engineer, one QA) ships a customer dashboard update. The QA lead needs to verify that button spacing, font weights, and icon colors match the approved Zeplin screens before the release goes live. The Zeplin MCP pulls the reference specs into a Switchy thread so the QA lead can cross-check without opening Zeplin's web app. This scenario assumes your team already uses Zeplin as the handoff tool and that the screens are tagged with version numbers or feature flags. If your designer updates Zeplin screens after code ships, this breaks down—stale specs create false positives. The MCP saves 10-15 minutes per release cycle when the workflow is disciplined. If your team skips formal QA or uses screenshot diffing tools, you don't need this.

When Zeplin MCP speeds up external stakeholder walkthroughs

A 4-person agency team prepares a design review deck for a client. The account manager needs to pull screen annotations, color codes, and spacing notes from Zeplin into a Switchy thread that the whole team can edit before the call. The Zeplin MCP fetches this metadata without the account manager needing a Zeplin login—OAuth2 lets one team member authenticate and share access. This works when the client expects Zeplin as the deliverable format and the team wants to rehearse talking points in Switchy. If your client reviews designs in Figma or wants interactive prototypes, Zeplin is the wrong artifact and this MCP adds no value. Best for agencies that standardize on Zeplin for client handoffs and want to centralize review prep in one workspace.