MCP connection

Frontfriend’s MCP server exposes design-system context and supported design workflows to authenticated agents. It connects your brand foundations, design rules and component knowledge to the agent working in your application.

Authenticate once

Use the Frontfriend CLI’s supported authentication flow:

pnpm exec frontfriend login
pnpm exec frontfriend mcp --help

Open the provided verification link and complete sign-in. Do not paste a personal credential into documentation, a prompt or committed project files.

Connect your client

Use frontfriend agents install to generate the client connection, and inspect frontfriend mcp --help for the options supported by your installed version. The mcp command starts the local stdio proxy. It refreshes authentication from your frontfriend login credential and connects your client to the Frontfriend server. Confirm that your client can list the Frontfriend tools before beginning a design task.

Run pnpm exec frontfriend doctor after restarting your coding agent. It checks the connection and local adoption and reports whether onboarding is complete. pnpm exec frontfriend connect --resume activates a reviewed snapshot.

Use Claude Code or Codex with the generated client configuration. For other MCP clients, verify their support for the authentication and tool capabilities your workflow requires.

Ask for the right facts

Component tools include list_components, get_component_api, get_component_source and get_add_command. Use these for components that are not yet installed. Request the explicit Application target rather than mixing primitive-specific APIs.

The registry provides source-derived API metadata and composition rules. Inherited primitive props remain linked to their upstream source instead of being guessed from a screenshot.

Read the design rules

Use get_rules_index to discover the available rule areas, then get_rules to read the relevant rules. The response combines shared chapters, application rules and enabled starter packs for the selected system view. Use search_rules to discover candidates, then fetch their context before building.

Rules in force are returned in full for the selection; other guidance is paginated. Keep the application and release or snapshot selection consistent with the components you are inspecting. Read Design rules for scope, maturity and review behavior.

Design workflows

Install Design Skills for guided design and audit flows. Keep generated project context current through the documented sync workflow. See Agent context.

Review foundation edits

For Frontfriend generated and Figma-backed foundations, propose_foundation_edit and validate_foundation_edit return the same impact report without writing. A successful commit_foundation_edit returns that report for the saved batch. Read the report before you commit a colour scale edit: contrast calculations can also change inherited on* text, icon, and border colours.

• semantic_tokens_changed counts distinct semantic paths whose resolved value changes in light or dark mode. A path changed in both modes counts once.
• semantic_changes lists up to 50 entries, sorted by path and mode. Each entry has path, mode, kind, before, and after. The values are resolved from the expanded tokens. reference_before and reference_after retain source references when either value is a reference; a detached value has a null reference. A missing token has a null resolved value.
• kind: "direct" means the batch explicitly sets or resets that semantic path in that mode. All other changes are derived, including changes to a colour behind an unchanged reference and contrast-derived on* changes.
• semantic_changes_truncated and semantic_changes_omitted show whether the list is incomplete and how many path/mode entries were omitted. Counts and affected components always use the full diff.
• components_affected and component_ids use the changed semantic paths. Non-colour foundation edits also use a conservative utility scan.
• token_values_changed counts changed source-token leaves. A reference change with the same resolved value affects this count, but not the semantic count.

The existing changes list contains the submitted foundation edits. Check impact.semantic_changes for their effects on semantic values. Reference values that cannot be resolved remain reference strings in before and after.

describe_foundation_controls and get_onboarding_status return permissions. When edits_need_review is true, your account is a workspace member: the agent still proposes and validates the batch, but commit_foundation_edit saves it as a proposal with status: "pending-review" and a review_url. An admin or owner approves or rejects it in Studio, and nothing changes in the foundations before the approval. If the foundations changed in the meantime, Studio validates the proposal again and shows it as stale when it no longer applies. A newer proposal from the same member replaces their pending one, and a pending proposal for an app holds that app’s onboarding approval. get_onboarding_status reports the outcome in foundation_proposals.

Access and limitations

MCP calls are scoped to authorized workspace data. Review generated proposals and confirm the intended scope before applying changes.