# yetty [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/avniy/yetty-mcp  
**GitHub Stars:** 0  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/yetty

## Description
Build, edit and run real hosted websites from your AI - content, SEO, menus, publish with rollback.

## Tools
Capabilities this server exposes over MCP:

- **yetty_status** — Connection + authentication status. Call this FIRST. Unauthenticated sessions can still park a website (batch tools) and start email sign-up — the response tells you exactly how.
- **yetty_authoring_guide** — READ THIS BEFORE WRITING OR SENDING ANY HTML (no account needed, free, instant, no arguments). Returns yetty's exact structure rules — repeated items sharing one class, semantic class names for field labels, headings before sections, no JS-rendered content — that decide whether the site converts into a clean editable CMS with named fields and add/remove collections, or a wall of generic "Text" fields.
- **yetty_pull_template** — Pull a ready-made Yetty template file WITH its usage contract (no account needed, free, instant). Four boilerplates, one per store surface: template:"checkout-skeleton" (cart / checkout / thank-you markup with every data-yetty-component and data-yetty-slot mark), "account-skeleton" (the buyer's /account page in the site's own design), "order-status-skeleton" (the /order/{token} confirmation), "pay-skeleton" (the /pay/{token} frame - the payment element stays hosted and non-removable). Every file carries a commented CONDITIONAL REGIONS section showing the component logic grammar (data-yetty-when / data-yetty-each / data-yetty-state; full grammar in yetty_authoring_guide's logic_and_conditional_components chapter). Restyle freely to match the site; NEVER remove or rename data-yetty-* marks; write NO cart/checkout/account JavaScript of your own (Yetty provides the behavior); send the styled file back with the site files. (Connected Live-plan stores can additionally pull 24 gallery-<surface>-<layout> LAYOUT skeletons - different page structures over the same contract, auto-adjusted to the site's own colors and fonts.)
- **yetty_batch_start** — No account needed: start a PARKED file batch — send the site now, authenticate after. Returns park_ref (use it as batch_ref). Files are stored safely but NOT processed until the owner approves by email. EXAMPLE: yetty_batch_start {} -> {park_ref:"pk_..."} -> yetty_batch_file {batch_ref:"pk_...", path:"index.html", content:"..."} per file -> yetty_batch_end {batch_ref:"pk_..."} -> yetty_signup {email:"owner@x.com", park_ref:"pk_..."} -> owner clicks the email -> yetty_claim_status {park_ref:"pk_..."} gives you an API key + the build status.
- **yetty_batch_file** — Add ONE file to the parked batch. Args: batch_ref (the pk_... park_ref); path (relative, folders allowed); content (text) OR content_base64 (binary). Returns {received_bytes, sha256} — verify against your local copy; mismatch = resend THIS file. Send EXACT bytes, never retype.
- **yetty_batch_end** — Close the parked batch. Nothing is processed yet — next call yetty_signup {email, park_ref} so the owner can approve by email.
- **yetty_signup** — Link a parked upload to the owner's email: sends them an approval email and returns a short user_code. The site is processed ONLY after the owner opens the email and types that code on the approval page. Args: email (the owner's), park_ref. SHOW THE OWNER THE CODE, then poll yetty_claim_status every ~30s.
- **yetty_claim_status** — Check a parked upload. States: parked (send yetty_signup) -> awaiting-approval (owner must open the email and type the user_code) -> approved (returns your api_key ONCE + waiting_url — reconnect with Authorization: Bearer <api_key> for the full toolset).
- **yetty_login** — Sign the OWNER in by email — no dashboard, no key copying. Works for existing accounts AND (when signups are open) new ones. FLOW: yetty_login {email:"owner@x.com"} -> {login_ref, user_code} -> SHOW the owner the user_code; they open the emailed link and type it -> poll yetty_login_status {login_ref} every ~20s -> it returns an api_key ONCE + the exact reconnect command. Use this whenever you are unauthenticated or your token expired.
- **yetty_login_status** — Check an email sign-in: pending (owner has not typed the code yet) -> approved (returns api_key ONCE + reconnect instructions). EXAMPLE reconnect for Claude Code: claude mcp remove yetty; claude mcp add --transport http yetty https://mcp.yetty.ai/ --header "Authorization: Bearer <api_key>" -s user

## Claude Desktop Quick Installation
Remote MCP endpoint (confidence: high). Install path detected from listing signals. Add as a URL/SSE server in your client:

```json
"mcpServers": {
  "yetty": {
    "url": "https://mcp.yetty.ai/mcp"
  }
}
```

## Documentation

## What yetty MCP server does

The yetty MCP server gives an AI client control over websites hosted on Yetty. It can start a site from static HTML or a ZIP archive, convert that source into Yetty’s managed CMS, and apply changes to the resulting site. The platform preserves the supplied HTML structure during conversion rather than redesigning it.

Website operations span content, publishing, discovery, and day-to-day administration. An agent can update text and images, work with posts and other collection items, manage menus and taxonomy terms, edit global content and translations, and prepare a site for publication. It can also inspect traffic analytics, review leads, check links, and work with forms, integrations, and webhooks.

## How it works

The hosted endpoint is `https://mcp.yetty.ai/mcp` and uses Streamable HTTP. Clients can authenticate through OAuth 2.0 with PKCE and dynamic client registration, or send a Yetty API key as a Bearer token. Every mutation creates a version that can be rolled back, so publishing and later recovery are handled through version history rather than separate manual backups.

The server supports staged drafts with a publishing step, readiness checks, and rollback. SEO-related operations include titles, descriptions, robots settings, AI-crawler policy, redirects, permalinks, sitemaps, and `llms.txt`. Site search and commerce readiness for Yetty Shops are also exposed where applicable.

## Setup and configuration

For a remote-capable client, add the Yetty MCP URL as a remote connector. OAuth-capable clients can sign in with a Yetty account. API-key authentication uses an `Authorization: Bearer yk_...` header. Keys are created from the Yetty dashboard under API Keys and are shown only when created.

The repository also includes `yetty-mcp.py`, a zero-dependency Python bridge for clients that cannot connect to remote MCP servers. Configure the bridge as a local stdio server and provide the `YETTY_API_KEY` environment variable. Claude Code can be configured with an HTTP transport command, while Cursor, Windsurf, and VS Code can use a server URL and authorization header.

Before submitting a site for conversion, call `yetty_authoring_guide`. It returns the structure conventions that affect the generated CMS, including rules for repeated items, class naming, heading order, and JavaScript-rendered content.

## Tools and capabilities

The yetty MCP server covers these operational areas:

- Create sites from HTML or ZIP files, upload content in chunks, start conversion, and reprocess with the latest engine.
- Edit text and image fields, compose posts, manage collections, items, menus, taxonomies, terms, global content, and translations.
- Check publication readiness, publish versions, inspect history, and roll back changes.
- Configure SEO metadata, crawler controls, redirects, permalinks, sitemaps, and `llms.txt`.
- Review analytics by browser, device, referrer type, and country; inspect leads; and check links.
- Manage forms, integrations, webhooks, search, and Yetty Shops readiness.

## Limitations and notes

The remote service requires a Yetty account for OAuth or a Yetty API key for bearer authentication. The local bridge requires Python and a key. Site conversion itself is free, while hosting plans are charged per site. CMS quality depends on following the authoring guidance before conversion. The material does not specify individual tool names beyond `yetty_authoring_guide`, so clients should discover the available operations through MCP rather than relying on an undocumented static tool list.

_Full upstream README: https://allmcps.com/mcp/yetty/readme_