Skip to main content
Two integration paths work today, and each has its own kind of prompt. Pick whichever matches your setup - you don’t need both.
  • .env path - works with any agent, no install. You create the form yourself in the dashboard, put the access_key in .env, and prompt your agent to wire the snippet using it.
  • MCP path - frictionless after a one-time install. Your agent is connected to the MCP server and provisions the form itself via create_form, with no dashboard visit at all.
Every prompt below targets a capability that’s actually shipped - nothing here describes a REST API, a component that doesn’t exist yet, or a CAPTCHA step.

Contact form

.env path - create the form in the dashboard first, put FORM_PASTE_ACCESS_KEY=fp_... in .env, then prompt:
MCP path - with the MCP server connected (see Install):
The agent calls create_form, gets back an access_key and a wired snippet, and pastes the snippet into your project. If the destination email is new, it’ll tell you to check your inbox for a verification code - see create_form → Destination verification for why that step can’t be automated away.

Feedback form

Same mechanics as the contact form - this just tells the agent which fields make sense (feedback text, optional rating) rather than name/email/message.

Newsletter signup

A minimal form (email + submit) - good for testing the redirect-after-submit flow; see Redirects if you want visitors to land on a “thanks for subscribing” page.

Framework-specific

Name the framework and Formpaste renders that framework’s snippet instead of plain HTML:
Supported framework names: HTML, React, Next.js, Astro, Vue, Svelte - see Framework snippets for what each one looks like.

Checking submissions

MCP-only (this needs a live tool call, not just a snippet to paste):
The agent calls list_submissions and summarizes the result. By default it only sees metadata (counts, timestamps, status) - it won’t see message content or visitor emails unless you specifically ask for that, e.g.:
That phrasing is what should push the agent to pass includeContent: true - see list_submissions → PII posture for why that’s opt-in rather than the default.

Verify your work

Once a form is created and wired, have the agent prove it is live before you move on. Create, wire, and verify end to end:
Confirm an existing form is wired correctly:
List my forms:

Why prompts, not docs, are the integration unit

The prompt - not the endpoint - is what developers actually copy and share. Every prompt above is a real, working instruction against a shipped capability: no fictional REST calls, no components that don’t exist yet, no CAPTCHA step to configure. If a prompt here ever stops working against the current build, that’s a docs bug - open an issue rather than assuming your agent did something wrong.

MCP server

Install steps for the MCP path.

Quickstart

The manual, no-agent version of the same flow.