Edit Any Rich Text in Your App Using Cursor's AI — Complete Guide

Edit Any Rich Text in Your App Using Cursor's AI — Complete Guide

Quick answer: To edit any rich text in your app using Cursor's AI, connect the Eddyter MCP server to Cursor, then ask the agent to replace your plain textareas with the Eddyter editor. Cursor writes the integration code for your framework. Your users then rewrite, shorten, translate and fix grammar with AI built into the editor itself.

Two different AIs are doing two different jobs here, and mixing them up is where most people get stuck. Cursor's agent works on your code: it finds the fields and wires in the editor. The AI inside Eddyter works on your users' content. This guide covers both, in the order you'll actually do them, plus the parts most tutorials skip: storage, version history, comments, email templates and going to production.

What "edit any rich text with Cursor" really means

Picture a typical SaaS app. A blog admin with a <textarea>. A CRM notes field. A product description box that someone hacked together with contenteditable three years ago. Each one stores text differently, and none of them can rewrite a paragraph for you.

You could rebuild each field by hand. Or you open Cursor and say "make every one of these a proper rich text editor with AI writing tools." That second path is what this guide is about.

One thing to get straight early: Cursor never reads or edits the text your users write. The Eddyter MCP server only sends tool arguments (like a framework name or a feature toggle) and an OAuth token scoped to one license key. Your documents, editor content and local files are never sent. Cursor changes your source code. Your users change their content.

Where this pays off: real use cases

Not every app needs this. These are the places where swapping a textarea for an AI rich text editor changes how people work:

If your app has even one of these, the setup below is worth the twenty minutes.

What you need before you start

• Cursor, any recent version with MCP support and Agent mode.
• An Eddyter account and license key. Create one from your license key dashboard. The free plan works for the editor; the AI writing tools sit on paid plans (see pricing).
• A React-based app. The npm package supports React 18.2+ and 19.x on Node 16+. Cursor's auto-generated snippets cover React, Next.js (App Router and Pages Router), Vite and Remix.

That's the whole list. No extra build plugins, no separate AI API key for the editor.

How to edit rich text in your app using Cursor's AI (step by step)

Step 1. Connect Eddyter MCP to Cursor

Open cursor.directory/plugins/eddyter and click Add to Cursor, or add the hosted server to .cursor/mcp.json:

1
2
3
4
5
6
7
8
{
  "mcpServers": {
    "eddyter": {
      "type": "http",
      "url": "https://mcp.eddyter.com/mcp"
    }
  }
}

Sign in when Cursor asks, pick your license key, then type "Is my Eddyter key valid?" in Agent chat. If you get back a plan and an expiry date, you're connected. The full walkthrough, with the five common setup errors, is in How to Add Eddyter MCP to Cursor.

Put the config in the project file rather than your home folder. There's no secret in it, so it's safe to commit, and every teammate who opens the repo gets the same Eddyter tools.

What goes wrong: you ask in Ask mode instead of Agent mode, and Cursor answers from memory without calling any Eddyter tool. Switch to Agent.

Step 2. Ask Cursor to find every text field worth upgrading

Before you install anything, get a map. Paste this into Agent chat:

1
2
3
Find every textarea, contenteditable element and rich text component in this repo
that stores formatted content (posts, notes, descriptions, emails).
List file, component name, and how the value is saved.

You'll usually find more than you expected. Not every field deserves an editor, though. A "company name" input should stay an input. Upgrade the fields where people write paragraphs: blog bodies, ticket replies, knowledge base articles, product descriptions, internal notes.

Then pick one field to start with. The one your users complain about most is a good choice. Ship that, watch how people use it for a week, and roll out to the rest. Replacing twelve fields in one pull request is how you end up debugging twelve save flows at once.

What goes wrong: the agent flags search boxes and single-line inputs. Tell it to skip anything under two lines or anything that isn't saved as content.

Step 3. Let Cursor add the editor

Now the useful prompt:

1
2
Add Eddyter to my Next.js app and replace the textarea in
app/admin/posts/[id]/page.tsx with it. Keep the existing save logic.

Cursor calls get_integration_snippet, installs eddyter, and writes the component. In a Next.js App Router project it creates two files: an Editor.tsx marked 'use client', and an EditorClient.tsx that loads it with next/dynamic and ssr: false. That second file is the one people forget by hand, and it's why you'd otherwise hit window is not defined on your first npm run dev.

The core of what it writes looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
import { ConfigurableEditorWithAuth, EditorProvider, defaultEditorConfig } from 'eddyter';
import 'eddyter/style.css';
export default function PostEditor({ value, onSave }) {
  return (
    <EditorProvider defaultFontFamilies={defaultEditorConfig.defaultFontFamilies}>
      <ConfigurableEditorWithAuth
        apiKey={process.env.NEXT_PUBLIC_EDITOR_API_KEY!}
        initialContent={value}
        onChange={(html) => onSave(html)}
      />
    </EditorProvider>
  );
}

On a Vite project the same prompt gives you a shorter result. There's no SSR boundary, so you get one component, and the key goes in VITE_EDDYTER_API_KEY instead. The MCP tool knows the difference, so you don't have to remember it.

Two props worth asking Cursor to add while it's in there:

• toolbar={{ mode: "sticky", offset: 64 }} if your app has a fixed header. The default offset is 20px, which tucks the toolbar under most navbars.
• editor={{ maxHeight: 600 }} with toolbar={{ mode: "static" }} if the editor sits inside a modal or a card and only the content area should scroll.

What goes wrong: the stylesheet import gets dropped during a refactor. Without eddyter/style.css the toolbar and tables render unstyled, and it looks broken even though it isn't.

Step 4. Wire the HTML into your save flow

Eddyter's onChange returns an HTML string. If your old textarea saved plain text, you now have a choice to make, and Cursor can't make it for you:

Ask Cursor to write the migration, but read it before you run it. This is the one step in the whole guide that touches real user data.

If your team already writes in Markdown, there's a softer path. The editor's toolbar has a Markdown menu with Import Markdown (paste or upload a .md or .txt file up to 2 MB), Copy as Markdown and Download as .md. Users can bring old content in one document at a time, and anything Markdown can't represent is simplified rather than silently dropped.

To show saved content on public pages, use the same component in read-only mode:

1
2
3
4
5
<ConfigurableEditorWithAuth
  apiKey={apiKey}
  mode="preview"
  initialContent={savedHtml}
/>

One component for writing and rendering means the published page looks exactly like the editor did. No second stylesheet to keep in sync.

Step 5. Turn on the AI editing tools for your users

This is where "edit any rich text with AI" actually happens for the people using your app. Back in Cursor, ask:

1
What editor features are enabled on my Eddyter key?

Cursor calls get_config and lists what's on, what's off but allowed, and what your plan locks. To switch something on or off, just say so ("turn on AI chat in the editor") and Cursor calls update_config. The change is live on every editor using that key, with no redeploy.

Once AI is on, your users select text and get:

• Enhance with AI to rewrite and refine a passage
• Make Longer and Make Shorter, plus Simplify for plain-language rewrites
• Adjust Tone (formal, casual, friendly, professional)
• Fix Grammar and Translate into 50+ languages
• AI chat, smart autocomplete and text-to-image generation inside the document

Here's what that looks like in practice. Your support agent writes a reply that's technically right and a bit blunt. They highlight it, pick "professional," and send. Nobody copies text out to a chatbot, pastes it back, and then spends two minutes fixing the formatting the chatbot stripped.

Because the config lives on the license key, you can also turn features off by chat. If AI image generation doesn't fit a legal or finance product, ask Cursor to disable it, and it disappears from every editor on that key instantly.

Step 6. Add comments and @mentions for teams

If more than one person touches the same document, ask Cursor:

1
2
Pass the logged-in user to EditorProvider as currentUser
and load our team members into mentionUserList.

The currentUser object takes an id, name, email and an optional avatar. With it set, users can attach threaded comments to selected text and tag teammates with @mentions. Feedback stays anchored to the sentence it's about instead of living in a Slack thread nobody can find later.

Step 7. Turn on version history

Version history is server-backed and plan-gated. The editor ships the whole UI: a toolbar toggle and a side panel where users save, name, preview and restore versions. Your only job is to pass a stable documentId, and this is a good prompt to hand Cursor:

1
2
3
Pass the post's primary key as documentId to the Eddyter editor.
In our Save handler, save to our API first, then call
editorRef.current?.saveVersion({ documentId: saved.id }).

Two details save you a support ticket later:

• Always pass a real documentId in apps where many documents share one URL (like /notes). Without it, the editor falls back to an id derived from the page URL, and every note's history collides into one.
• Call saveVersion() before you switch to a read-only view. It reads the live editor, so once the editor unmounts it returns { skipped: true, reason: "unavailable" }.

There's no timed autosave, saving unchanged content is deduplicated, and restoring an old version appends it as the newest one rather than deleting anything. That last part matters when an intern restores the wrong version on a Friday afternoon.

Bonus: email templates with merge tags

If your app sends marketing or transactional emails, the same editor has a second surface. The envelope button in the toolbar switches to an email builder with a block palette, a 600px canvas and a styles panel. It outputs email-safe HTML (nested tables, inline styles, absolute image URLs), which is what Outlook and Gmail need and what a normal rich text editor doesn't produce.

Your app declares the merge fields, and users pick from that list:

1
2
3
4
5
6
7
8
9
10
<ConfigurableEditorWithAuth
  apiKey={apiKey}
  emailMergeTags={[
    { value: "FNAME", name: "First name", sample: "Alex", group: "Contact" },
    { value: "COMPANY", name: "Company", sample: "Acme", group: "Contact" },
  ]}
  onChange={(html, meta) => {
    if (meta?.mode === "email") setEmailHtml(html);
  }}
/>

Write "FNAME", not "{{FNAME}}". The editor adds the braces for you, and it rejects a value that already has them so you never ship {{{{FNAME}}}} to someone's inbox.

A prompt library you can copy into Cursor

These are the prompts we use most. Each one maps to a single Eddyter MCP tool, so Cursor knows exactly what to call.

Cursor AI vs. the editor's built-in AI: who does what

Our take: let Cursor do the boring integration work, and let your users have the AI where they're already typing. Trying to make one AI do both jobs is how you end up piping customer content through a coding tool.

Before you ship: production checklist

• Key per environment. Use separate license keys for staging and production so feature toggles you test on staging don't hit real users. When you sign in through Cursor, check which key you picked.
• Env variables, not hardcoded keys. Keep the editor key in NEXT_PUBLIC_EDITOR_API_KEY (or VITE_EDDYTER_API_KEY) and out of your components.
• Layout check. Put the editor in your real page layout, not a blank test page. In flex rows add min-w-0 to its column; in CSS grid use minmax(0, 1fr) instead of 1fr.
• Dark mode. The editor picks up a dark class on <html> or <body>, then falls back to the system setting. Flip your theme once and confirm.
• Credits. Ask Cursor "How many AI credits are left?" in your first week to see real usage before you pick a plan.

Troubleshooting

The editor renders but the AI buttons are missing. AI features are plan-gated. Ask Cursor "What editor features are enabled?" and check for anything marked locked by plan.

"I asked Cursor to turn a feature on and nothing changed." update_config is clamped to your plan. If the feature isn't included, the request won't flip it. On a local npx install, writes stay off until you set EDDYTER_ALLOW_WRITES=true.

window is not defined in Next.js. The editor is rendering on the server. Make sure it's loaded through next/dynamic with ssr: false, or ask Cursor to regenerate the snippet for your router.

Editor overflows in a flex or grid layout. Add min-w-0 to the editor's flex column, or use minmax(0, 1fr) in CSS grid. The editor also logs a console warning naming the parent element that won't shrink.

Version history shows the wrong document. You're relying on the URL fallback. Pass the record's primary key as documentId.

AI credits run out mid-month. Ask Cursor "How many AI credits are left?" to see the balance and the reset date before your users find out the hard way.

Frequently asked questions

Can Cursor edit the content my users write?

No. Cursor edits your code. The Eddyter MCP server never receives documents or editor content. Content editing happens through the AI tools inside the editor, triggered by your users.

Is the Eddyter MCP server free?

Yes. The server is MIT licensed and free to use. You need an Eddyter account with an active license key, and the free plan works for connecting Cursor.

Do I need my own OpenAI or Anthropic key for the editor's AI?

No. Eddyter runs managed AI credits on paid plans, so the editor's AI works without a separate model key. BYOK mode is available if you prefer to use your own.

Does this work outside Next.js?

Yes. Cursor's snippets cover React, Next.js, Vite and Remix. Eddyter itself also supports Vue, Angular, Svelte, Laravel, Vanilla JS and React Native, with setup steps in the docs.

Can I use Claude Code or ChatGPT instead of Cursor?

Yes. The same server URL, https://mcp.eddyter.com/mcp, works in Claude.ai, Claude Desktop, Claude Code, Codex and ChatGPT. The Eddyter MCP page has setup steps for each client.

What format does Eddyter save content in?

HTML. The onChange callback returns an HTML string you can store in any database column. Users can also copy or download a document as Markdown from the toolbar.

Can I control which features my users see?

Yes. Features are set on your license key, and you can toggle them from Cursor with a prompt like "turn off AI image generation." Changes apply to every editor on that key with no redeploy, within the limits of your plan.

What is Eddyter built on?

Eddyter is built on Lexical, Meta's open source editor framework, and outputs clean HTML that you can store and render anywhere.

Next step

Connect Eddyter in Cursor, then paste one prompt: "Find my rich text fields and replace the most important one with Eddyter." You'll have an AI-ready editor running locally before your coffee cools. If you want the bigger picture on why agent-driven setup beats copying SDK docs, read MCP vs Traditional Editor SDK Integration, or compare options in our Top 10 Rich Text Editors for Developers.