Magic Patterns

Fills in one concept of an existing Magic Patterns inspiration document with its self-contained HTML. Use this after create_inspiration_document to stream concepts in one at a time: pass the html directly here instead of holding it all for a single create call. The concept renders live on the shared page as soon as its html arrives, and the document flips to "ready" once every concept is filled. INPUT: - inspirationId: the inspiration document id returned by create_inspiration_document. - variantId: the concept id returned by create_inspiration_document (targets that specific placeholder). If omitted, the first still-empty concept is filled. - name / description: optional; updates the concept's label/direction. - html: the full, self-contained HTML document (non-empty). RESPONSE: { ok, variantId, url }.

Resets every concept of an existing Magic Patterns inspiration document back to an empty placeholder — dropping each concept's html and its pre-created "Iterate" room. Use this to REPLACE all concepts: clear the document, then invent a fresh set of directions and stream each one's html back in with inspiration_add_variant (targeting the returned concept ids). The document shows loading tiles again until the new concepts arrive. INPUT: - inspirationId: the inspiration document id returned by create_inspiration_document. RESPONSE: { ok, url, variants: [{ id, name }] }. Each concept keeps its id and name; pass them to inspiration_add_variant (with a new name/description/html) to fill the fresh concepts in.

Revises a single already-filled concept of a Magic Patterns inspiration document in place, replacing its html (and optionally its name/description). Use this to UPDATE a subset of concepts (e.g. "focus more on the messaging", "update Concept C") without touching the others: read the current concepts with get_inspiration_document, regenerate the targeted concept FROM ITS PREVIOUS html, then push the revised html here. The concept's "Iterate in Magic Patterns" room is refreshed so it builds from the new html. INPUT: - inspirationId: the inspiration document id. - variantId: the concept id to revise (from get_inspiration_document). Required — this targets an existing filled concept, unlike inspiration_add_variant which fills empty placeholders. - name / description: optional; updates the concept's label/direction. - html: the full, self-contained HTML document (non-empty). RESPONSE: { ok, variantId, url }.

Lists the design systems available to the authenticated user. Returns both built-in (reserved) design systems and any custom design systems the user has created or has access to. Use this when the user mentions a specific design system (e.g. "use Shadcn", "with my company design system") so you can resolve the correct ID to pass to create_design. Each result includes: - id: The unique design system ID to pass to create_design - name: The human-readable name - isReserved: Whether it is a built-in preset (e.g. Base, Shadcn, MUI) - isActive: Whether this is the user's currently active design system

Lists the artifact version history for a design. Returns the most recent 20 versions with their artifact IDs, version labels, and titles. Use the skip parameter to paginate backwards. Because the editor is collaborative, new versions may have been created by the user or AI since you last checked. Use this alongside get_design_status to understand the full picture. Each version corresponds to a snapshot of the design's code at a point in time. Use the artifactId from a version entry to read_artifact_files for that version, or create_new_artifact to branch from it.

Compiles an artifact's source files and sets it as the active artifact for the design. This is the final step in the code-first workflow (Workflow B). This tool: 1. Compiles all source files in an existing artifact version (bundling for preview). 2. Sets that artifact as the design's active artifact (so it appears in the editor and preview). 3. Does NOT create a version entry. Call create_new_artifact first and publish the artifactId it returns. 4. Records your `description` on the version, above the file changes already logged from write_artifact_files. ALWAYS pass a description. The people who open this design did not watch you work, and the version is otherwise an unexplained code change. NEXT STEPS: The design preview will update. Share the editor URL with the user.

Publishes the design system's active artifact as a new immutable version. STRICT: refuses if the active artifact has validation errors — run write_design_system_files and clear all validationErrors first. Returns the new version (major.minor) and whether it is backwards-compatible with the previously published version (a breaking change — e.g. a removed component or prop — bumps the major version).

Reads the contents of one or more files from an artifact. IMPORTANT: Always read files BEFORE making changes with write_artifact_files so you understand the current state. This code is meant as a starting point or inspiration. It is NOT production-ready. You should adapt this code to match the user's project style, frameworks, libraries, and conventions.

Reads the contents of one or more files from a design system's active artifact. Design system file structure: - components/<Name>/index.tsx — component source (named exports only) - components/<Name>/<Name>.previews.tsx — preview definitions; default-export a ComponentPreviewModule with componentName, importPath, and previews - components/<Name>/Context.md — AI/usage documentation - index.css — design system styles / Tailwind imports - tailwind.config.js — Tailwind configuration - rules/<slug>.md — design rules Call get_design_system first to discover available file names. Always read before editing.

Reads the recent chat item history for a design. Returns the last 10 chat items (user prompts, AI responses, artifact versions, edits). Use the skip parameter to paginate backwards through older items. Because the editor is collaborative, the user may have sent prompts or made changes in the UI between your tool calls. Use this to catch up on what happened and understand the current context before acting. Note: Code contents are omitted from the response to keep it concise. Use read_artifact_files to read full file contents.

Sends a natural language prompt to the Magic Patterns AI for an existing design. The AI will interpret the prompt and generate/update code. Returns immediately with a requestId. EDITOR ONLY, NOT MAGIC OS: what this makes or changes lives outside any Magic OS, and it cannot be added, linked, or embedded into one afterwards. For work in a Magic OS, use the OS tools instead: create_os_file to make a design there, then write_file. And do not generate here to copy the result in: design it yourself, in the OS, or — only when the user asks for Magic Patterns’ AI to do it — hand it to MagicOS with ask_magicos. BEFORE CALLING: Call get_design_status(editorId) to make sure the design is not already generating (isGenerating=false) and to understand the current state. The user may have sent prompts or made changes in the UI. Use this for prompt-based updates to existing designs (Workflow A with existing design). ⚠️ IMPORTANT: This kicks off a LONG-RUNNING generation that typically takes 2–10 minutes. Do NOT poll more often than every 60 seconds. Call get_design_status(editorId) once every 60 seconds until isGenerating=false. Do NOT treat slow generation as an error — it is expected.

Creates or overwrites one or more files in an artifact. If a file exists, it will be replaced. If it doesn't exist, it will be created. IMPORTANT: This only saves source files — it does NOT compile or publish. Call publish_artifact after you have finished all file changes. Each file you write is logged onto the version in the design's chat, with a diff the user can open — so the design records what you changed, not just the end result. NEXT STEPS: - Call write_artifact_files again for additional files. - When done with all changes, call publish_artifact(artifactId, editorId) to compile and activate.

Creates or overwrites files in a design system. Incoming files are validated, merged onto the existing artifact (existing files are preserved), compiled, and activated immediately. COMPONENT FORMAT (required): - Use a PascalCase folder and write the complete trio for every code component: components/<Name>/index.tsx components/<Name>/<Name>.previews.tsx components/<Name>/Context.md - Export the component from index.tsx as a named export. Default exports reject the entire write; fix the file and retry. - Default-export the previews object from <Name>.previews.tsx. It must include componentName, importPath, and previews; every preview needs a render function returning JSX. - Do not write flat component files such as components/Button.tsx or components/Button/Button.tsx. IMPORTANT: - Call get_design_system first and pass its artifactId as baseArtifactId. A 409 means someone else changed the design system — re-read and retry. - Magic Patterns does not post-process MCP writes. Non-canonical paths, syntax errors, source-format violations, and shell/auto-generated files reject the entire write so you can fix them and retry. - validationErrors for incomplete component trios remain non-blocking — fix them before publish_design_system, which is strict. Load the design_system_authoring_guide prompt for the full file contract.