"MUI" matching MCP tools:

• get_design_guidelinesA

  Marmo UI MCPA

  MANDATORY FIRST CALL before writing any @marmoui/ui code in this session. Returns a step-by-step generation checklist (which tools to call, in what order), critical rules (no namespace sub-components, PageSection is self-closing, no Sidebar export), component patterns, and ICON LIBRARY RULES. Pass iconLibrary (default "phosphor"; also "material" | "lucide" | "tabler" | "heroicons" | "feather") to get that library's import source, icon name map, and weight/style mapping — and pass the SAME value to review_generated_code so it enforces it. Ask the user which icon library they want before writing UI code. Call topic="patterns" to get the generation checklist specifically.

  ConnectorNo auth

• render_diff_imageA

  UI VerifyA

  Fetch a story's image as an INLINE image (base64 pixels, not a URL) so a vision model can look at it directly. Needs a native MCP client that renders image content; piped through raw curl it is useless (use get_diff's URLs there instead). Two ways to address it: (1) diffResultId + which for a CHANGED story - which is baseline|candidate|diff (the triptych) or before_after, the baseline and candidate SIDE BY SIDE (before on the left, after on the right) cropped to the changed region - and when a story changed in SEVERAL far-apart places, one such crop PER region stacked top to bottom, so a header-plus-footer change is two tight crops, not a page-tall image. before_after is usually what you want for a code change - it zooms to what moved instead of a full page. Get diffResultId from get_build (changedStories[].diffResultId) or get_diff. (2) a build selector (commitSha|prNumber|buildId) + storyId for ANY story's current image - the candidate if it changed this build, else its baseline. This second form is the only way to see an UNCHANGED/passed story's pixels (list them via list_build_stories status=unchanged), so you can confirm 'identical to baseline'. Errors if the image doesn't exist (a genuinely new story has no baseline, so no before_after either).

  ConnectorNo auth

• list_build_storiesA

  UI VerifyA

  Page through one build's stories filtered by status (resolved by commitSha/prNumber/buildId). Use it to read past get_build's first page, or to browse the unchanged/passed stories get_build only counts. status='changed' returns changed stories (same shape + order as get_build, regression-first); status='failed' returns failed stories; status='unchanged' returns the stories that did NOT change this build but have a baseline on this branch (storyId, viewport, browser) - fetch any of their images by storyId with get_diff or render_diff_image to confirm 'identical to baseline'. Returns { stories, nextCursor }: pass nextCursor back as `cursor` for the next page; null means no more. limit defaults to 25 (max 100). Unchanged is only available once the build has settled (an in-progress build has rendered nothing, so it returns an empty page).

  ConnectorNo auth

• render_diff_imageA

  UI VerifyA

  Fetch a story's image as an INLINE image (base64 pixels, not a URL) so a vision model can look at it directly. Needs a native MCP client that renders image content; piped through raw curl it is useless (use get_diff's URLs there instead). Two ways to address it: (1) diffResultId + which for a CHANGED story - which is baseline|candidate|diff (the triptych) or before_after, the baseline and candidate SIDE BY SIDE (before on the left, after on the right) cropped to the changed region - and when a story changed in SEVERAL far-apart places, one such crop PER region stacked top to bottom, so a header-plus-footer change is two tight crops, not a page-tall image. before_after is usually what you want for a code change - it zooms to what moved instead of a full page. Get diffResultId from get_build (changedStories[].diffResultId) or get_diff. (2) a build selector (commitSha|prNumber|buildId) + storyId for ANY story's current image - the candidate if it changed this build, else its baseline. This second form is the only way to see an UNCHANGED/passed story's pixels (list them via list_build_stories status=unchanged), so you can confirm 'identical to baseline'. Errors if the image doesn't exist (a genuinely new story has no baseline, so no before_after either).

  ConnectorNo auth

• review_generated_codeA

  marmo-uiA

  ⚠️ MANDATORY — call this on every piece of code you generate before returning it to the user. Validates TSX/JSX against real @marmoui/ui prop signatures and returns { valid, errors[], warnings[], suggestedFixes[], iconLibrary }. Catches: (1) unknown imports, (2) Tabs.List/Tabs.Trigger namespace misuse → auto-suggests TabsList/TabsTrigger fix, (3) PageSection used as wrapper (must be self-closing), (4) hallucinated props, (5) icons imported from the wrong icon library (pass iconLibrary — default "phosphor" — matching what you passed to get_design_guidelines; wrong-library icon imports are ERRORS). If valid=false, fix all errors and call this again. DO NOT return code with errors to the user.

  ConnectorNo auth

• mu_quoteA

  muA

  Ask the MU manufacturing router how a thing could be MADE before you create a product: which supplier(s) can make it, the est. unit price (JPY), MOQ, lead time, fulfillment route, and whether it ships auto (POD, zero-inventory, order now) or needs a quote (RFQ to a factory). Pass `kind` (a known POD kind like tee/hoodie/rashguard_ls, OR a non-POD kind like `gi`/`loopwheel_sweat`/`seamless_knit`/`rashguard_premium`) OR a free-text `description` (e.g. "道着 for a dojo", "a seamless knit sweater") and the router infers the kind. Optional `qty`, `region` (e.g. jp/us), `budget` (JPY/unit). Read-only — creates nothing. No API key required. Options are ranked: buyable-now (auto + in budget) first. If an option's mode is `auto`, follow up with mu_create_product; if `quote`, it needs a human RFQ.

  ConnectorNo auth

• list_build_storiesA

  UI VerifyA

  Page through one build's stories filtered by status (resolved by commitSha/prNumber/buildId). Use it to read past get_build's first page, or to browse the unchanged/passed stories get_build only counts. status='changed' returns changed stories (same shape + order as get_build, regression-first); status='failed' returns failed stories; status='unchanged' returns the stories that did NOT change this build but have a baseline on this branch (storyId, viewport, browser) - fetch any of their images by storyId with get_diff or render_diff_image to confirm 'identical to baseline'. Returns { stories, nextCursor }: pass nextCursor back as `cursor` for the next page; null means no more. limit defaults to 25 (max 100). Unchanged is only available once the build has settled (an in-progress build has rendered nothing, so it returns an empty page).

  ConnectorNo auth

• list_pr_storiesA

  UI VerifyA

  Page through the PR-vs-base changeset stories of one kind (resolved by commitSha/prNumber/buildId) - use it to read past get_pr_changeset's first page. kind='new' returns stories the PR adds that the base branch has no baseline for; kind='changed' returns stories whose image differs from the base branch's accepted image (even if accepted mid-PR, with status=accepted); kind='removed' returns stories that HAD a baseline on the base branch but are gone from head (a deletion; each carries lastBuildId, not a review status or verdict). Returns { stories, nextCursor }: pass nextCursor back as `cursor` for the next page; null means no more. limit defaults to 25 (max 100). Requires the PR visual changeset feature.

  ConnectorNo auth

• list_pr_storiesA

  UI VerifyA

  Page through the PR-vs-base changeset stories of one kind (resolved by commitSha/prNumber/buildId) - use it to read past get_pr_changeset's first page. kind='new' returns stories the PR adds that the base branch has no baseline for; kind='changed' returns stories whose image differs from the base branch's accepted image (even if accepted mid-PR, with status=accepted); kind='removed' returns stories that HAD a baseline on the base branch but are gone from head (a deletion; each carries lastBuildId, not a review status or verdict). Returns { stories, nextCursor }: pass nextCursor back as `cursor` for the next page; null means no more. limit defaults to 25 (max 100). Requires the PR visual changeset feature.

  ConnectorNo auth

• mu_gi_logosA

  muA

  List the MU × JiuFlow sponsored gi's 17 sponsor placements with each logo's slot, brand, position, finished size, thread color, logo file/url, status (ok=hi-res | low=low-res | request=not collected | missing), and consent (yes=written permission to embroider on apparel | requested | no). ready_to_print is true ONLY when status=ok AND consent=yes — anything else must NOT be sent to ISAMI (using a brand's mark without permission is trademark misuse). Owner-only.

  ConnectorNo auth

• get_buildA

  UI VerifyA

  Triage one build, resolved by commitSha, prNumber, or buildId (exactly one). Returns the gate verdict and counts (total/changed/failed/unchanged), then the FIRST page (25) of the changed stories (story id, viewport, % pixels changed, review decision, the AI verdict aiVerdict=intended|regression + aiConfidence, and for a regression the judge's one-line aiFlagReason=what-looks-unintended, when AI review is on) and the first page of failed stories (failedStories[].kind is `render` when the story produced no frame, or `interaction` when it rendered and its play() assertion threw; failedStories[].error is the message's first line, errorTruncated marks the ones that carried more). When AI review ran, aiReview tallies how many changes look like regressions vs intended, and the changed list is ordered likely-regressions-first. changedNextCursor / failedNextCursor are non-null when there are more than 25: page the rest with list_build_stories. counts.unchanged is how many stories did NOT change and have a baseline - this triage call does NOT list them (keeps the response lean); call list_build_stories status=unchanged to browse them (e.g. to confirm a passed build's stories are 'identical to baseline'). No image URLs here - call get_diff or render_diff_image for pixels.

  ConnectorNo auth

• get_pr_changesetA

  UI VerifyA

  The cumulative 'this PR vs base' visual changeset (resolved by commitSha/prNumber/buildId) - what the whole PR does to the UI versus the branch it merges into, INDEPENDENT of what is left to review on the latest build. Unlike get_build (this commit vs the branch's own accepted baseline), this survives in-PR accepts: a story accepted mid-PR still shows under `changed` with status=accepted, so it answers 'what did this PR change' even after the gate reads clean. Returns base (the branch it merges into), counts {new,changed,removed,unchanged}, and the first page of `new` + `changed` + `removed` stories (storyId, title, name, kind, review status, aiVerdict). `removed` lists stories that HAD a baseline on the base branch but are gone from this PR's head (a deletion - otherwise invisible; each carries lastBuildId, the build that rendered its now-orphaned baseline). newNextCursor / changedNextCursor / removedNextCursor page the rest with list_pr_stories. No image URLs - fetch pixels by storyId with get_diff / render_diff_image. Requires the PR visual changeset feature.

  ConnectorNo auth

• get_diffA

  UI VerifyA

  Per-story diff detail for a build (resolved by commitSha/prNumber/buildId). Returns diff metrics and presigned, time-limited URLs (download them to a file, or link them in a PR comment) for the baseline, candidate, and diff PNGs. Defaults to the changed stories; pass storyId for one specific story. When that storyId is an UNCHANGED story it returns its baseline (diffResultId null, changed false, the baseline URL as both baselineUrl and candidateUrl) - the story rendered identical to baseline. Use render_diff_image instead when you want the actual pixels inline for a vision model, not a URL. When AI review is on, each diff carries the judge's call: aiVerdict (intended|regression), aiConfidence, aiSummary (what changed), aiReasoning, and aiFlagReason; all null when AI review didn't run for it.

  ConnectorNo auth

• review_diffA

  UI VerifyA

  Record a review on a single diff result (get diffResultId from get_build/get_diff). 'accept' makes the candidate the new baseline for that story on its branch, so the next build is clean; 'deny' records the rejection without changing the baseline; 'ignore' excludes the story from the gate persistently (the snapshot keeps differing on future builds but no longer flags the check) — use it for an intentional, ongoing diff like an animation or a live timestamp. This is the same accept/deny/ignore as the dashboard, attributed to your project key. Use after you've inspected the diff (e.g. with render_diff_image) and decided intended vs. regression.

  ConnectorNo auth

• get_buildA

  UI VerifyA

  Triage one build, resolved by commitSha, prNumber, or buildId (exactly one). Returns the gate verdict and counts (total/changed/failed/unchanged), then the FIRST page (25) of the changed stories (story id, viewport, % pixels changed, review decision, the AI verdict aiVerdict=intended|regression + aiConfidence, and for a regression the judge's one-line aiFlagReason=what-looks-unintended, when AI review is on) and the first page of failed stories (failedStories[].kind is `render` when the story produced no frame, or `interaction` when it rendered and its play() assertion threw; failedStories[].error is the message's first line, errorTruncated marks the ones that carried more). When AI review ran, aiReview tallies how many changes look like regressions vs intended, and the changed list is ordered likely-regressions-first. changedNextCursor / failedNextCursor are non-null when there are more than 25: page the rest with list_build_stories. counts.unchanged is how many stories did NOT change and have a baseline - this triage call does NOT list them (keeps the response lean); call list_build_stories status=unchanged to browse them (e.g. to confirm a passed build's stories are 'identical to baseline'). No image URLs here - call get_diff or render_diff_image for pixels.

  ConnectorNo auth

• get_pr_changesetA

  UI VerifyA

  The cumulative 'this PR vs base' visual changeset (resolved by commitSha/prNumber/buildId) - what the whole PR does to the UI versus the branch it merges into, INDEPENDENT of what is left to review on the latest build. Unlike get_build (this commit vs the branch's own accepted baseline), this survives in-PR accepts: a story accepted mid-PR still shows under `changed` with status=accepted, so it answers 'what did this PR change' even after the gate reads clean. Returns base (the branch it merges into), counts {new,changed,removed,unchanged}, and the first page of `new` + `changed` + `removed` stories (storyId, title, name, kind, review status, aiVerdict). `removed` lists stories that HAD a baseline on the base branch but are gone from this PR's head (a deletion - otherwise invisible; each carries lastBuildId, the build that rendered its now-orphaned baseline). newNextCursor / changedNextCursor / removedNextCursor page the rest with list_pr_stories. No image URLs - fetch pixels by storyId with get_diff / render_diff_image. Requires the PR visual changeset feature.

  ConnectorNo auth

• get_knowledge_versionA

  Marmo UI MCPA

  Returns the MCP knowledge version: gitSha, indexedAt, componentCount, patternCount, uptimeSeconds. Call this ONCE per session before generating UI code so you know how fresh the design-system data is. Cheap to call. If gitSha is "unknown" or indexedAt is far in the past, surface that to the user before relying on the data.

  ConnectorNo auth

• get_knowledge_versionA

  marmo-uiA

  Returns the MCP knowledge version: gitSha, indexedAt, componentCount, patternCount, uptimeSeconds. Call this ONCE per session before generating UI code so you know how fresh the design-system data is. Cheap to call. If gitSha is "unknown" or indexedAt is far in the past, surface that to the user before relying on the data.

  ConnectorNo auth

• mu_verifyA

  muA

  Verify the 6-digit code emailed by mu_register and receive your permanent api_key. Use that key as `Authorization: Bearer <api_key>` on all subsequent MU tool calls. No authentication required for this call.

  ConnectorNo auth

• mu_create_productA

  muA

  Create a product in one of your MU stores. Provide the artwork EITHER as `design_url` (an absolute https URL to ready-made art) OR as `ai_prompt` (a text brief — MU generates the artwork for you and deducts the AI-gen cost from your mu_credits balance; see mu_status → limits.ai_gen for cost_jpy and whether it is enabled). Pass exactly one of the two. `kind` must be one of: tee, tee_white, rashguard_ls, rashguard_black, hoodie, crewneck, sticker, mug, tote, tank, cap, phone_case, long_sleeve_tee, shorts, beanie, leggings, joggers, apron, canvas, metal_print, pillow, blanket, coaster, placemat, journal, mug_black, wine_glass, towel, bottle, mouse_pad, laptop_sleeve, poster, nfc_coin, device, event_ticket, song, zine, video, karaoke_ticket, house, socks, drawstring_bag, beach_towel, fanny_pack, bucket_hat, kids_tee, backpack, flag, printful_custom. `phone_case` is an iPhone tough case (Printful) — the buyer picks their iPhone model (11〜17, all sizes) inside checkout, so you create ONE product and it ships to whichever model they choose. . Two digital kinds need an extra field: `event_ticket` (a sellable event ticket — pass `capacity` for the seat limit; on purchase the buyer is emailed a QR that opens a VALID ticket page; no shipping) and `song` (a sellable track — pass `audio_url`, the https link to the audio; on purchase the buyer is emailed a private listen/download link; no shipping). Other digital kinds (`zine` PDF, `video`, `karaoke_ticket`) and manual-fulfilment kinds (`poster`, `tee_white`, `nfc_coin`, `device`, `house`) all take the same `design_url`/`ai_prompt` artwork; the buyer gets a download/redemption link (digital) or the operator ships/builds it (manual). Products go live immediately for trusted owners unless the risk gate trips, otherwise they wait for MA-council review — ALWAYS report the `status` field from the response, do not assume. Requires `Authorization: Bearer <api_key>`.

  ConnectorNo auth

• mu_preview_mockupA

  muA

  See the mockup BEFORE creating any product — nothing is created or sold, and it costs no credits. Renders the design on the real garment (Printful) when the kind supports it (source: "printful"), otherwise a clean MU product card (source: "card"), and returns a durable preview image URL. Optionally pass `position` (front-print DTG apparel only: tee / tee_white / hoodie / crewneck / tank / long_sleeve_tee) to preview a custom print placement — passing the SAME position to mu_create_product prints exactly what you previewed (WYSIWYG). Usually answers in 10-45s; if it returns status="processing", call this tool again with the returned `preview_id` to keep waiting. Rate limit: 30 previews/hour. Requires `Authorization: Bearer <api_key>`.

  ConnectorNo auth