.envpath - works with any agent, no install. You create the form yourself in the dashboard, put theaccess_keyin.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.
Contact form
.env path - create the form in the dashboard
first, put FORM_PASTE_ACCESS_KEY=fp_... in .env, then prompt:
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
Newsletter signup
Framework-specific
Name the framework and Formpaste renders that framework’s snippet instead of plain HTML:Checking submissions
MCP-only (this needs a live tool call, not just a snippet to paste):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.:
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: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.