Adding a contact form to a static site without a backend: Sakupa's mail-form app

#ai #webdev #mcp

A quick disclosure first: I am not Sakupa's developer. I came across this MCP server while reading about AI-published websites, and this post summarizes only public information from its official site and manual. This is not a first-hand usage report.

Sakupa is an MCP server that lets an AI agent publish and run a static site without an account registration. Static sites have one obvious gap: there is nowhere for a visitor to leave a message. Sakupa's answer so far is a single app, and it is worth looking at closely because of what it does — and does not — promise.

The gap a static site leaves

A static site can show opening hours, a menu, and announcements. It cannot receive a message on its own. The usual fix is to add a backend, which is exactly the kind of moving part a small shop does not want to maintain. Sakupa's app catalog addresses this gap from the static side instead.

The first app: a mail form

The first app in the catalog is a mail form. You can check the catalog with apps. The idea is simple: add a contact window to a static site, so a visitor can send a message and the shop receives it by email. There is no database, no login system, and no backend to keep running.

What to check before relying on it

The mail allowance depends on the plan. The plan catalog is public through plans, and each plan's form mail quota should be confirmed there before promising a contact window to visitors. A form that silently stops accepting messages is worse than no form at all, so the quota is part of the design, not a footnote.

How it fits the rest of Sakupa's design

The app sits inside the same careful flow as the rest of the service. Publishing goes through a read-only analyze check, then a preview and confirmation step before anything runs. Contracting is per site, not per account: the free preview is normally 30 days, plans start at ¥200 a month, and there is no automatic upgrade to a higher plan. Payment goes through a Stripe page handled by the person, never through the AI, which never touches card numbers.

What it does not do

It does not turn a static site into a web app. There is still no database and no login functionality. The mail form adds one narrow channel — a visitor's message arriving by email — and that narrowness is the point. A small shop gets a contact window without taking on a backend.

The question I would ask first

If I were considering it, I would start from the quota, not the form itself: how many messages does this plan allow, and what happens when that number is reached? The official information answers the first part. The second part is worth confirming in the manual before the form goes live.

DEV Community