Sakupa has no user accounts. That is a deliberate design choice, and it creates an obvious question: if the machine holding your site credentials is gone, what happens to the site?

No account means a different kind of recovery

In a normal service, you would reset a password and log back in. Here there is no account to log back into, so credentials are kept locally instead. Recovery therefore cannot be "prove who you are to the server." It has to be "prove control of something tied to the site."

Sakupa offers two paths under the recover tool:

• The device path. Recover through a device that still holds the relevant credentials.
• The DNS path. Recover through control of the domain's DNS settings.

Either path restores access to the site. The choice between them depends on what you still control: a surviving device, or a domain you can still configure.

The one decision the agent does not make for you

Recovery comes with a judgment call: should the old credentials be invalidated? Sakupa's design refuses to let the agent decide that. Whether old credentials are revoked is always the person's own choice, shown before the step runs.

That rule matters because the two outcomes are both risky in different ways. Revoking everything is safest if the old machine is lost to someone else, but it also cuts off anything still depending on those credentials. Keeping them is convenient, but leaves a lost machine with access. A design that forces this choice into the open, rather than quietly defaulting it, is treating the user as the owner of the risk.

Rotation is the companion tool

Recovery's companion is rotate, which exchanges the management credentials. It also runs through a preview first, and once it runs, all old credentials expire. The pair tells a coherent story: recover gets you back in, rotate lets you change the locks, and both steps show you what will happen before they do it.

The same caution, everywhere else

The pattern repeats across the tool list, which is why I keep coming back to it:

• analyze checks a site read-only before publishing and warns about unsuitable files.
• Publishing, deletion, and rotation all require a preview and a confirmation. Deleting a free site is explicitly irreversible.
• Payments go through Stripe's hosted pages. The agent never handles card numbers.
• A custom domain is only announced as published when its state is active and it returns HTTP 200, not when it is merely attached.

Limits worth knowing

Sakupa is for static sites only, not web apps with databases or logins. It is a relatively new service (first published on npm in July 2026, per the official timeline). The usual free preview is 30 days, with paid plans from 200 yen per month, contracted per site.

Account-free publishing sounds simple until the machine changes. Sakupa's answer is not to pretend that problem away, but to give it two explicit paths and one explicit choice. That honesty is what makes the design worth reading closely.

Links

• Official site: https://sakupa.com/
• Product page: https://sakupa.com/product/
• Manual: https://sakupa.com/manual/
• npm: @sakupa/mcp

Static sites have a well-known missing piece: a contact form. A static page cannot receive a submission on its own, so small sites usually bolt on a third-party form service. Sakupa's answer is its app catalog — and so far, the catalog has exactly one app: a mail form.

How it fits the tool list

The catalog is reached through the apps tool. The first (and currently only) entry is the mail form: a contact window you can add to a static site. Submissions arrive as email, so the site itself stays static — no database, no login system, no server-side code of your own.

That single-app catalog is itself a design statement. Rather than growing a plugin marketplace, the project shipped one app for the one gap every small-business site hits first: "how do visitors reach me?"

Quotas are tied to the plan

The mail form's monthly send quota depends on the plan, per the official documentation:

• Free preview: 5 sends per month
• Water plan (¥200/month): 50 sends per month

Quotas set expectations honestly: a brochure site with occasional inquiries fits comfortably, while a site expecting heavy form traffic would need to look at the higher plans. The quota is part of the plan description, not a surprise discovered after publishing.

What it does not do

The mail form does not turn the site into a web app. Sakupa's scope remains static sites only — no databases, no login features. The form is an inbox bridge, not a backend. And as with everything else in this server, money and authority stay with the human: plan changes go through Stripe's management page, and the AI never handles card numbers in chat.

Why start with this app

If you think about what a small business actually needs from a first website — a page that opens, a way to be contacted, a price that fits one site — the mail form covers the second need with the smallest possible machinery. It is also the easiest app to reason about: one input, one inbox, one monthly number.

The catalog may grow later, but starting with exactly one app keeps the question simple: does this one bridge solve the contact problem for your site? For many small sites, the answer is yes.

Scope notes (from official information only)

• Static sites only; not for web apps with databases or login features.
• A relatively new service (first published on npm in July 2026, per the official timeline). The free preview (usually 30 days) is the sensible way to try it small first.

Links

• Official site: https://sakupa.com/
• Product page: https://sakupa.com/product/
• Manual: https://sakupa.com/manual/
• npm: @sakupa/mcp

What is Sakupa, exactly?

It is an MCP server that lets your usual AI assistant — ChatGPT, Claude, and similar tools — publish and operate a static site such as a company homepage. The design covers more than building the page: publishing it, updating it, attaching a domain, and checking the subscription, all from within the conversation.

Do I need an account?

No. Instead, control of a site is proven by management credentials stored on your own machine (the manual places them under ~/.sakupa/credentials/, with only a reference in the project's .sakupa/site.json). No account also means the machine holding those credentials matters — which leads to the next two questions.

What if I replace my computer?

There is a recovery tool, recover, with two routes: a device route using another device or surviving information, and a DNS route if a custom domain is already connected. Whether the old credentials are revoked is always the owner's choice, never something the AI decides on its own. A companion tool, rotate, swaps the credentials entirely, and once it runs, all old credentials are revoked.

How much does it cost?

Publish first under the free preview (normally 30 days), then put only the sites you want to keep on a monthly plan: Water at ¥200, Personal at ¥500, Share at ¥1,000, Business at ¥2,000. Plans are per site and never upgrade themselves automatically. Form-email allowances run from 5/month on the free preview to 2,000/month on Business.

Do I hand my card number to the AI?

No. Plan checks, applications, changes, and cancellations only return a link to a Stripe-hosted page; card numbers never appear in the conversation. Creating the link alone does not change the contract.

Can I check a site before it goes live?

Yes. Before deploy, an analyze tool inspects the output folder locally and returns the list of what will be published plus warnings about files that should not be published. The AI explains that in plain language and takes an explicit confirmation before publishing. Deletions and credential swaps go through the same preview-and-confirm flow.

Can I use my own domain?

Yes, via a bind tool, with DNS-based confirmation. A domain is only described as published once its status is active and it returns HTTP 200. Attaching a domain alone is not publication.

What can it not do?

Static sites only — no database-backed or login-based web apps. A free site's deletion (delete) requires a preview and cannot be undone. Sakupa is relatively new (first published on npm in July 2026, per the official timeline), so the free preview is the sensible place to start.

Links

• Official site: https://sakupa.com/
• Product page: https://sakupa.com/product/
• Manual: https://sakupa.com/manual/
• npm: @sakupa/mcp

I am not the developer of Sakupa. I found this MCP server while researching AI-published static sites, and this post covers only what its official site and manual say. This is not a story about my own usage.

Why confirmation design is the feature to study

When an agent can publish, delete, and change things on your behalf, the interesting question is not what it can do. It is where it is forced to stop. Sakupa's 18 tools are split in a way that makes that stopping pattern visible, and I think the pattern is worth borrowing as a checklist for evaluating any agent tool.

Read-only tools vs. tools that change things

Several tools only read. analyze inspects the output folder and warns about files that should not be published. status shows connection state, expiry, and domain state. plans lists the pricing catalogue. billing checks the actual subscription and usage. help runs a local-only diagnosis. None of these change anything, and none of them ask for confirmation — because there is nothing to confirm.

The tools that change things behave differently:

• deploy publishes only after the analyze result has been explained and explicitly confirmed.
• delete requires a preview for free-site deletion, and deletion cannot be undone.
• rotate exchanges management credentials only after a preview, and all old credentials expire.
• report sends a failure report only when help recommends it, and only after a preview.
• support opens a ticket only after you confirm its contents.

The rule seems to be: the harder an action is to reverse, the heavier the confirmation in front of it.

Money and authority stay with the person

Two boundaries are drawn consistently. First, payment: subscription tools return Stripe-hosted page links only. The agent never handles card numbers, and creating a link does not change the subscription. Second, authority: when a site is recovered with recover (device path or DNS path), whether old credentials are revoked is always your choice, not the agent's.

That matters because the failure mode of an agent is rarely "it could not do the task." It is "it did the task before you understood what it was about to do." A design that separates reading from changing, and puts previews in front of irreversible steps, directly addresses that failure mode.

The limits, stated plainly

Sakupa only handles static sites — no databases, no login systems. A preview shows what will be published, not whether the content itself is correct; checking names, addresses, and prices is still your job. And it is a new service (first npm publish in July 2026, per the official timeline), so the free preview (normally 30 days) is the sensible place to start.

If you evaluate agent tools, try this: list the tools, mark which ones only read, and check what stands between you and every irreversible action. Sakupa's answer — previews, explicit confirmation, and keeping money and credential-revocation decisions with the person — is a good reference point, whatever tool you end up choosing.

Links

• Official site: https://sakupa.com/
• Product page: https://sakupa.com/product/
• Manual: https://sakupa.com/manual/
• npm: @sakupa/mcp

Why the domain step deserves its own post

Publishing a page is only half the job for a business website. The other half is making it answer at the company's own domain — and that step is where vague "it's live!" messages cause real confusion. A domain can be pointed, configured, propagated, and still not serving the right content, and every tool that blurs those states makes troubleshooting harder.

Sakupa's domain tool, bind, takes a stricter approach, and it is worth spelling out because the strictness is the feature.

What bind actually checks

According to the manual, connecting a custom domain works like this:

1. You ask the AI to connect your domain via bind.
2. Ownership and routing are confirmed through DNS.
3. The site is only described as published once two conditions are both true: its status is active and it returns HTTP 200.

That last point matters. Attaching a domain does not, by itself, earn the word "published." A domain that is pointed but not yet serving the site correctly is reported as not-yet-published, not papered over with a success message. For a small business owner who cannot tell a DNS problem from a deployment problem, that honesty saves a confused afternoon.

Where bind sits in the workflow

The domain step comes after the publish step, and it inherits the same confirmation habits as the rest of Sakupa's design:

• Before anything goes public, analyze inspects the output folder locally (read-only) and reports what will be published, plus warnings about files that should not be published. The AI explains that list and gets explicit confirmation before deploy runs.
• status lets you read the connection state, expiry, and domain state at any time without changing anything.
• If the machine holding the credentials is replaced, recover offers a device route or a DNS route to take the site back — and the decision about invalidating old credentials is always left to the person, never made by the AI.

So the domain is not a one-off setting you hope worked. It is a state you can re-check, with a defined "published" condition at the end of it.

The limits, stated plainly

Within the official information, a few boundaries apply:

• Sakupa targets static sites only — company introductions, shop pages, that kind of content. It is not for web apps with databases or logins.
• The domain check confirms serving state, not content correctness. Whether the phone number and opening hours on the page are right is still a human check, before or after bind.
• Plans are per site, starting with a free preview (normally 30 days) and paid plans from 200 yen per month, with no automatic upgrade to a higher plan. Payment itself never passes through the chat: plan tools only return links to Stripe-hosted pages.

If you are evaluating Sakupa, the domain step is a good litmus test for the whole design. A tool that refuses to call a half-connected domain "published" is a tool that takes its reporting seriously — and that is exactly the property you want from something you are trusting with a business's public face.

Links

• Official site: https://sakupa.com/
• Product page: https://sakupa.com/product/
• Manual: https://sakupa.com/manual/
• npm: @sakupa/mcp

Two things happened in the agent infrastructure layer this year that are worth more attention than they got: the Model Context Protocol (MCP) went stateless at the protocol layer, and the Agentic AI Foundation (AAIF) quietly became the neutral home for most of the agent stack.

MCP 2026-07-28: no more handshake, no more session header

The 2026-07-28 revision of MCP removed the mandatory initialize/initialized exchange and the Mcp-Session-Id header. Each request now carries its protocol version, client identity, and capabilities. Practical consequences:

• Plain round-robin load balancing works; no sticky sessions, no shared protocol-session store.
• Tool, prompt, and resource lists can be cached; gateways can route and authorize on MCP headers.
• Business state (browser sessions, jobs, approval state) has to be modeled explicitly with application-level handles instead of hiding inside a transport session.

"Stateless" does not mean your agent cannot keep state. It means the protocol stopped pretending to keep it for you.

The multi-version reality

Servers in the wild now speak 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28 side by side. Red Hat's MCP gateway went GA on October 16, 2026 with per-client negotiation across all four on one endpoint. The operational rule that follows from this: log the protocolVersion the server returns, not the one you requested — the returned value is the agreement. Recording whether tools/list stays stable between calls (the listChanged capability) makes incident triage much easier.

AAIF: from 3 projects to 10

The AAIF, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI in December 2025, started with MCP, goose, and AGENTS.md. On October 22, 2026, at AGNTCon + MCPCon North America, four more projects landed:

• Agent Skills (Anthropic) — the SKILL.md folder format for teaching agents task procedures. Anthropic reports 1 million published skills, roughly 280 million installs, and 70+ integrated platforms.
• Open Responses (OpenAI) — an open API specification for LLM interfaces.
• OpenEnv (Hugging Face) — containerized reinforcement-learning environments.
• OpenSandbox (Alibaba) — sandboxing to constrain what an agent can touch.

With Agent2Agent (A2A), Agent Router, and agentgateway already in the portfolio, the foundation now hosts ten projects and reports more than 300 member organizations.

What this means if you build agents

1. Skills are becoming portable assets. A procedure written once as a skill folder can travel across hosts instead of living inside one vendor's product.
2. Design tools for stateless calls. Requests that complete on their own, with state passed as explicit handles, survive both old and new hosts.
3. Treat version negotiation as a first-class concern. "Supports MCP" is no longer a sufficient statement; which revision you actually agreed on is the fact that matters.

The model race gets the headlines, but October 2026 is when the plumbing under personal agents started to look like settled infrastructure.

References

• Stateless MCP 2026: Agent Migration Guide (LLMFly AI, Medium): https://medium.com/@llmfly/stateless-mcp-2026-agent-migration-guide-043d87ff8cf2
• AAIF Explained: Anthropic, OpenAI Donate AI Agent Standards (Digitech Info): https://digitechinfo.net/agentic-ai-foundation-aaif-four-new-projects/
• Agentic AI Foundation takes four agent projects from tech donors (LavX News): https://news.lavx.hu/article/agentic-ai-foundation-takes-four-agent-projects-from-tech-donors
• AI agents in October 2026: where they stand (Brandon Ta): https://www.brandon-ta.com/blog/ai-agents-where-they-stand-october-2026/

Plenty of MCP servers generate files. Fewer handle the unglamorous part after generation: getting a small business website published, keeping it online, and maintaining it without a hosting dashboard. Sakupa (@sakupa/mcp on npm, listed on the official MCP Registry and the Claude, Codex, and Gemini plugin marketplaces) is built for exactly that. Reading the official manual, the workflow looks less like a control panel and more like a set of conversations with checkpoints. Here is how it fits together.

Setup: no account, no API key

You register the server with a one-line command (npx -y @sakupa/mcp@latest) in an MCP-capable AI tool. There is no signup and no API key. Instead, the server generates a management credential locally on your machine, stored under ~/.sakupa/credentials/. A project folder only keeps two small files: .sakupa/project.json and .sakupa/site.json, which reference that credential. Site ownership is your local environment, not a login — an unusual model worth understanding before the workflow itself.

The 18 tools, in the order you'd actually use them

The tools group naturally into five sets:

• Publishing and operations: init, analyze, deploy, refresh, status, delete
• Billing: plans, subscribe, billing, change, portal — these only create Stripe-hosted pages; payment itself happens on Stripe, never through the agent
• Domains and recovery: bind, recover, rotate
• Apps: apps — currently a single app, email forms
• Support: help, support, report

A typical publishing run goes like this:

1. init — initialize the project folder. No network call, no charge; it just lays the groundwork.
2. Prepare the static files — hand-written HTML or a framework build output. An index.html entry point is required.
3. analyze — before anything goes public, this read-only check inspects the output: it detects the framework and the correct output directory, confirms index.html exists, flags elements that don't fit static hosting (SSR, API routes, database dependencies), catches files that shouldn't be published (secrets, archives), and verifies size limits.
4. deploy — publish. The outputDir argument is required (for example "." for the project root, or "dist" for a build artifact). The first deploy creates a free preview at a URL of the form https://{shortId}.sakupa.com, valid for 30 days. Because that first deploy makes the site publicly reachable by anyone with the link, the tool stops and asks the user to confirm before proceeding.
5. Day-to-day operations — status reports the URL, plan type, and expiry; refresh extends a free preview; re-running deploy republishes updated content; delete removes a site, behind a preview and an explicit decision.

Binding a custom domain

The bind tool connects your own domain. You add two DNS records as instructed, and the tool decides completion by its own HTTP 200 check against the domain rather than by trusting the DNS change alone — a small detail, but it means "done" actually means reachable.

The one app: email forms

Static sites have no backend to receive a contact form. Sakupa's only app so far, email-forms, forwards form submissions to an email address, with bot filtering before delivery. The page side has a contract to follow:

• Load the script once per page: https://api.sakupa.com/v1/forms/embed.js
• Add a data-sakupa-form attribute to the form; its value becomes the notification email's subject
• Include a honeypot field (default name website) hidden with CSS — explicitly not type="hidden"
• A field named email automatically becomes the notification's Reply-To
• Up to 20 fields; file uploads are not supported

Activation itself has a human checkpoint: apps install asks for confirmation, sends a 6-digit code to the notification address (notifyEmail), and the form only goes live after that code is verified. Submissions are also stored server-side for 30 days (up to 1,000 per site) and can be read back through the inbox action.

Where it stops, and where it doesn't

The confirmation pattern is consistent. Outward-facing or hard-to-reverse actions pause for the user: the first public deploy, an app install, delete, and credential rotation via rotate (including the choice of whether old credentials are revoked — the user decides, the tool doesn't). recover exists for moving management to another environment, via a device-based or a DNS-based path. Inward, reversible work — inspecting tools, writing pages, running analyze — proceeds without prompts.

Pricing

The free preview lasts 30 days, with 5 form emails per month. Paid plans are per website: Water ¥200/month (1 custom domain, 50 form emails/month), Personal ¥500 (3 domains, 200), Share ¥1,000 (10 domains, 600), Business ¥2,000 (50 domains, 2,000).

Who this fits

If a site is static by nature — a company profile, a shop page, a landing page with a contact form — the remaining cost is usually publishing and upkeep, and that is precisely what this workflow moves into the chat. Anything needing a database, logins, or dynamic APIs is out of scope, and analyze will tell you so up front.