For AI Agents

Audience: AI coding assistants (Claude Code, Cursor, Windsurf, Copilot, Antigravity, Kiro, Goose, Augment, Cline, etc.) and the humans configuring them. If you are a human reader, you're welcome here too — but the Quick Start is probably what you want.

This page is the canonical entrypoint for AI agents working with Myop. Bookmark it.

What does the user want to do?

Myop has two distinct workflows. Pick the one that matches your task — they share almost no code, so don't mix them up.

If the user says…	They want to…	Go to
"use Myop in my React app", "add a Myop widget", "load this component from Myop", "embed Myop"	Embed an existing component into their app	Embedding path
"create a Myop component", "build a component I can update later", "author a Myop component"	Author a new Myop component	Authoring path

Most user requests are embedding. If unsure, ask one clarifying question before generating any code.

Embedding path (host integration)

Use this path when the user wants to render a Myop component inside their existing app. Five steps:

Pick the host SDK            →  @myop/react, @myop/vue, @myop/angular, @myop/react-native
Install                       →  npm install @myop/react @myop/sdk
Render <MyopComponent>        →  componentId + data + on(action, payload)
Wire up CTAs                  →  typed `onPascalCase` props OR generic `on`
(Optional) local dev          →  enableLocalDev() or ?env=dev

Canonical pages for this path:

/docs/learnMyop/ReactHost — React host walkthrough
/docs/cli/host-integration — same flow for React, Vue, Angular, React Native
/sdk-reference.md — full type signatures

Minimal React example

import { MyopComponent } from "@myop/react";

export function MyopWidget() {
  return (
    <MyopComponent
      componentId="your-component-id"
      data={{ items: [...] }}
      onItemSelected={(payload) => console.log(payload)}
      style={{ width: 600, height: 400 }}
    />
  );
}

The user gets componentId from the Myop dashboard. If they don't have one yet, switch to the Authoring path first — you can't embed something that doesn't exist.

Never create iframes manually

Always use <MyopComponent>. Never hand-roll an <iframe> pointing at a Myop URL — the SDK owns iframe lifecycle, messaging, sizing, and caching.

Conventions for embedding

Pick the right SDK for the framework. Don't import @myop/sdk directly in a React app — use @myop/react's <MyopComponent>.
data is reactive. Update it like any React prop; the component re-inits.
CTAs travel up. The component emits myop_cta_handler(action, payload); the host decides what to do with them. Don't try to push state down through any other channel.
Auto-generated typed packages exist. For a published component you can npm install https://cloud.myop.dev/npm/{componentId}/react to get a fully typed component with the componentId baked in. Prefer this in production.

Authoring path (component development)

Use this path when the user wants to create or update a Myop component itself (the thing that gets embedded). Five steps:

Install the CLI               →  npx myop --version
Install agent skills          →  npx myop train
Connect the Myop MCP          →  npx myop mcp  (or claude mcp add myop …)
Read the component guide      →  MCP tool: get_myop_guide (no auth)
Build, then upload            →  MCP tools: upload_component → confirm_upload

Step 1 — Install the CLI

npx myop --version

The myop CLI ships scaffolding, dev server, host integration helpers, skill installation, and MCP setup. Full reference: CLI overview.

Step 2 — Install agent skills

npx myop train

Installs SKILL.md files into your project under the directory your AI assistant expects (e.g. .claude/skills/, .cursor/skills/, .windsurf/skills/). Skills teach the agent how to build Myop components correctly — the public component API, the host SDKs, the dev server flow, the common mistakes.

Skills are selected based on package.json: a React app gets the React host skill, etc. Full reference: CLI AI integration.

Step 3 — Connect the Myop MCP

# Claude Code (global)
claude mcp add myop https://mcp.myop.dev/mcp --transport http --scope user

# Or via the CLI helper (writes config for the detected assistant)
npx myop mcp

The MCP gives the agent access to the Myop platform — listing components, uploading new versions, and fetching the component development guide.

Tool	Auth required	What it does
`get_myop_guide`	No	Returns the Myop HTML Component Development Guide. Call this first.
`whoami`	Yes	Identity check
`list_organizations`	Yes	Orgs the user belongs to
`list_components`	Yes	List components in an org
`upload_component`	Yes	Step 1: get a presigned upload URL
`confirm_upload`	Yes	Step 2: confirm upload, get dashboard URL

Full reference: Myop MCP server setup.

Step 4 — Read the component guide

Before generating any component code, call:

MCP tool: get_myop_guide

It returns the canonical, up-to-date HTML Component Development Guide — the source of truth for the public component API (myop_init_interface, myop_cta_handler, etc.) and the single-file architecture. Always prefer the output of get_myop_guide over guesses from training data.

Step 5 — Build, then upload

The build product is a single HTML file at ./dist/index.html. Upload via MCP in two steps:

Call upload_component with name (and optional componentId, organization) → returns a curl command with a presigned URL.
Execute the curl command.
Call confirm_upload with the uploadId → returns the dashboard URL.

Save the returned componentId and orgId to myop.config.json so the next upload updates the existing component instead of creating a new one.

Step 6 — Inspect history and compare versions

Every push creates an immutable revision, so "what changed", "who changed it" and "what is on staging" are answerable exactly.

myop log                       # timeline: who, when, what is live where
myop diff                      # previous version -> current
myop diff @production          # what production serves -> current
myop diff by:someone@acme.com  # that person's last version -> current
myop diff -u                   # add the actual changed lines

Hosted assistants with no shell use the list_component_versions and diff_component_versions MCP tools instead.

Version refs. myop log prints the exact ref for each row, so copy it rather than assembling one:

Ref	Means
`latest`	the current version
`prev`	the version before it — crosses to the previous variant when the current variant has no earlier revision
`latest~2`	two content revisions back, within the same variant
`variant~1`	the previous sibling variant
`@production`, `@staging`	the version that environment is serving
`by:someone@acme.com`	that person's newest version (`~1` = their second-newest)
`rev:<24-hex>`	one exact revision
`at:<ISO date>`	the newest version at or before that instant

Write latest~1, never a bare ~1, in a shell — a leading tilde is tilde-expanded before the CLI sees it.

Never fetch two versions and diff them yourself. The comparison runs server-side and returns a summary — per-section byte deltas, Myop contract changes, and external endpoints added or removed. On a real 300 KB component that is a few hundred bytes instead of ~150,000 tokens of HTML.

Conventions for authoring

Single-file components. Myop HTML components are authored as one self-contained HTML file. Inline CSS and JS. No external imports from npm at runtime — use ESM CDNs or bundle.
The public API is small. myop_init_interface(data) receives data from the host, and the zero-argument myop_init_interface() returns the current state; myop_cta_handler sends actions back up. Don't invent globals — read the guide.
Sizing. Components default to "content" mode (auto height, full width). Use <meta name="myop:size" content='{"width":"100%","height":"100%"}'> for fill mode. The content must be valid JSON, not CSS-like syntax.
Local dev before upload. Run myop dev in the component dir to register with the local dev server and get HMR.
Don't fight the host. Components emit events via myop_cta_handler; the host decides what to do with them.

Machine-readable endpoints

A machine-readable copy of all Myop docs is available in a single file: llms-full.txt. A curated index lives at llms.txt. Most doc pages are also available as raw Markdown by appending .md to their URL — e.g. /docs/intro.md.

Caveat: the auto-generated SDK API reference pages under /docs/sdk* do not have individual .md mirrors. Fetch them in bulk via /sdk-reference.md. For the authoritative list of which URLs have a .md mirror, see /docs-index.json — each entry's markdown field is either the mirror URL or null.

Endpoint	What it is
`/llms.txt`	Curated index of the docs (llmstxt.org format)
`/llms-full.txt`	Every doc concatenated into a single file (~800 KB)
`/sdk-reference.md`	All SDK API docs (TypeDoc output) in one file
`/docs-index.json`	JSON list of every page with title, URL, and `.md` URL
`/message-protocol.json`	Iframe message protocol envelope + key list
`/sitemap.xml`	Standard XML sitemap
`/robots.txt`	Explicit allow-list for AI crawlers
`<doc-page>.md`	Raw Markdown source of most doc pages (see caveat above)

Things to avoid (both paths)

Skipping get_myop_guide before authoring and pattern-matching from training data — the public API has changed; the guide is authoritative.
Mixing the two paths. Embedding code (<MyopComponent>) does not belong in a component file. Component code (myop_init_interface, myop_cta_handler) does not belong in a host app.
Hand-rolled iframes. Always go through the host SDK.
Adding npm dependencies a component can't actually load during authoring. Bundle them or use an ESM CDN.
Uploading without myop.config.json — every upload after the first one needs a componentId to avoid creating duplicate components.

When to use Myop (and when not)

Use Myop when:

You want a part of an app to be updatable without a redeploy.
You want to ship an AI-generated component into a host app safely.
You're paying down UI debt by extracting widgets behind a stable contract.

Skip Myop when:

You need a static, redeploy-bound UI region — a plain component is simpler.
You need synchronous access to host internals — use a regular component.
You're building backend services — Myop is for runtime-loaded UI.

Helpful entry points

/llms-full.txt — fetch once, search locally
/sdk-reference.md — full SDK API in one file
Overview — what Myop is, which SDK to pick
React host — most common embedding path
Host integration (all frameworks) — Vue, Angular, React Native
HTML Component — most common authoring path
System Architecture — how the pieces fit together
@myop/react reference — type signatures

Feedback

Found a gap that made you hallucinate? File it at github.com/myopjs or ping us on Discord. Agent ergonomics is a first-class concern.

Open as MarkdownOpen in ChatGPT Open in Claude

What does the user want to do?​

Embedding path (host integration)​

Minimal React example​

Conventions for embedding​

Authoring path (component development)​

Step 1 — Install the CLI​

Step 2 — Install agent skills​

Step 3 — Connect the Myop MCP​

Step 4 — Read the component guide​

Step 5 — Build, then upload​

Step 6 — Inspect history and compare versions​

Conventions for authoring​

Machine-readable endpoints​

Things to avoid (both paths)​

When to use Myop (and when not)​

Helpful entry points​

Feedback​