Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@publish-my publish this folder as a live website"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for publish.my: your AI agent publishes a folder as a live
website at https://<id>.publish.my. Free, and no account needed to start.
Ask your agent to "put this online" and it calls publish_site. The first publish gives a
preview link; the user enters their email on that page once and the site goes live at the same
address. After that, every publish goes live immediately.
Claude Code
claude mcp add publish-my -- npx -y publish-myCursor: add this to ~/.cursor/mcp.json
{ "mcpServers": { "publish-my": { "command": "npx", "args": ["-y", "publish-my"] } } }VS Code
code --add-mcp '{"name":"publish-my","command":"npx","args":["-y","publish-my"]}'Codex
codex mcp add publish-my -- npx -y publish-myClaude Desktop, Windsurf and other MCP clients: a stdio server running npx -y publish-my
(Node 20 or newer).
claude.ai and ChatGPT have no filesystem, so they use the remote connector instead: add a
custom connector with the URL https://api.publish.my/mcp and sign in to publish.my once.
Related MCP server: StaticX MCP Server
Tool | What it does |
| Packs a folder (with |
| Checks whether the user has confirmed their email for a new site. |
| Lists the user's sites with status and 30-day views. |
| Recovers access to a live site after the key on this machine was lost. |
There is no delete tool. Sites are deleted in the console.
The same files the curl flow uses, so the two stay interchangeable:
~/.publishmy: your publish.my API key (mode 600), saved when you activate your first site.
A working key here is never replaced by a key for a different account.
~/.config/publish-my/keys/<site id> (mode 600): if a site gets activated on a different account
than the key in ~/.publishmy, its key is kept here and used only for that site.
<project>/.publish-my.json: which publish.my site this folder is, so "publish again" updates
the same address.
~/.config/publish-my/pending.json (mode 600): secrets for sites waiting for activation. It
is kept out of the project folder so it never ends up in git.
Hidden files (.env and similar), node_modules and file types publish.my does not host are left
out of the upload. The tool reports what it left out.
Environment overrides: PUBLISHMY_API_KEY, and PUBLISHMY_API_URL for testing.
500 MB per account, unlimited sites, 50 MB per upload, 2,000 files per site, static files only. Framework apps (Next.js, Vite, Astro, SvelteKit, Nuxt) must be built first; publish the output folder. Full details: https://publish.my/agents/
npm test # unit tests
./scripts/e2e-dev.sh # full flow against a local publish.my DEV server (needs the app repo)
node scripts/client.mjs listCheck whether the user has activated a newly published site (entered their email and clicked the link). When they have, the site is live and the publish.my key is saved for future updates.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Site to check; omit to check every site waiting for activation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and idempotentHint=true, which is non-obvious for a 'check' tool; the description partially earns that back by explaining that the publish.my key gets saved as a side effect. It does not say whether the save happens on this call, whether it polls, or what happens if the user hasn't activated yet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the verb and the meaning of the check. The second sentence earns its place by explaining the consequence of activation, though it could be marginally compressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with full schema coverage this is nearly complete, but with no output schema the description should hint at what the check returns (a boolean? per-site statuses when project_id is omitted?) — the agent has no idea what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single project_id parameter is already documented as 'omit to check every site waiting for activation.' The description adds no syntax, format, or scoping detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('check whether the user has activated a newly published site') and defines activation concretely as entering an email and clicking the link. It implicitly ties into the publish flow, but never names publish_site, list_sites or reconnect_site to differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention of a 'newly published site' implies this is the follow-up step to publishing, but the description never says when to call it versus list_sites or reconnect_site, nor whether it should be polled or called once.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's publish.my sites with their URLs, status and 30-day views.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuine value beyond that by disclosing the payload contents (URLs, status, 30-day views), which matters because there is no output schema. It stops short of noting ordering, pagination, or behavior when the user has no sites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every element (resource, returned fields) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param read tool with no output schema, the description covers what the agent needs to call it and interpret the result. Minor gaps remain around result ordering, pagination, and the empty-list case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb ('List') and resource ('the user's publish.my sites') and even previews the returned fields. It reads clearly as the read counterpart to publish_site / reconnect_site, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the discovery step before publish_site or check_activation, but nothing states when to call it versus when to skip it or what prerequisites exist (e.g. authentication, account connection).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a local folder (with index.html at its top) as a public static website on publish.my and return its URL. Use for "publish", "deploy", "host", "put online", "share a link", and "publish again / update the site". The first publish of a folder gives a preview URL the user activates by entering their email on that page; after that, publishes go live immediately. Re-publishing a folder that is already live updates the same URL: ask the user first, then pass confirm_update: true. Framework apps (Next.js, Vite, Astro, SvelteKit, Nuxt) must be built/exported first; pass the output folder (out/, dist/, build/, .output/public).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Folder to publish; must contain index.html at its top. Absolute path preferred. | |
| new_site | No | Publish as a separate new site even if this folder was published before. | |
| project_id | No | Update this existing publish.my site (e.g. "88vk3mqtxz"). Normally omitted: the folder's .publish-my.json is used. | |
| confirm_update | No | Set true only after the user confirmed replacing their live site. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint and non-idempotency, but the description adds the critical behavior model: first publish is gated by an email-activation preview page, re-publishing overwrites the same URL, and the user must confirm before replacing a live site. That is precisely the context an agent needs to avoid destroying a live site unintentionally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and return value, then ordered by lifecycle: first publish, re-publish, framework apps. Dense but every sentence carries operational meaning; slightly crowded in the middle with quoted synonyms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by stating it returns the site URL and explaining the preview-activation state. For a destructive, open-world publish tool with four parameters, all decision-relevant context (prerequisites, confirmation, update semantics) is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, and the description earns above that by clarifying the path semantics (must be a built output folder such as out/, dist/, build/, .output/public for framework apps) and the confirm_update sequencing. It leaves new_site and project_id largely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — publish a local folder as a public static site on publish.my — and includes the concrete precondition (index.html at top) and the return value (URL). An agent can tell this apart from check_activation and list_sites without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger vocabulary (publish, deploy, host, put online, share a link) plus a decision rule: first publish yields a preview requiring email activation, subsequent publishes go live. It also states the re-publish workflow (ask the user, then confirm_update: true) and the framework prerequisite. It falls short of 5 only because the sibling tools are never named as alternatives for the surrounding steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when a site is already live but this machine lost its publish.my key (updates fail with 401/403 or "no key"). Emails the site owner a confirm link; once clicked, the key is saved and updates work again.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Or: a published folder; its .publish-my.json gives the id. | |
| project_id | No | The site id (the part before .publish.my). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write behavior (readOnlyHint=false), open-world effects, non-idempotency, and non-destructiveness. The description adds valuable context beyond those annotations: it sends an email to the site owner, requires the owner to click a confirmation link, and then saves the key so updates work again. It does not detail permissions or rate limits, but it discloses the external email side effect and asynchronous confirmation flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the usage trigger before explaining the effect. Every sentence earns its place by covering the failure scenario and the confirmation flow without redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only two optional parameters, the description gives an agent enough to understand the trigger, the external email action, and the confirmation outcome. It does not state what the tool returns immediately after sending the email, but the overall context is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters (path and project_id) have description text in the schema. The tool description itself adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb (reconnect) and resource (site), and specifies the triggering condition: a live site whose publish.my key was lost locally and whose updates fail with 401/403 or "no key." It distinguishes the scenario from publishing a new site, though it does not explicitly name sibling tools like check_activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use conditions: the site is already live, the machine lost its key, and updates fail with 401/403 or "no key." It does not mention when not to use it or name alternatives, but the triggering scenario is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_activationlist_sitespublish_sitereconnect_siteScored across 4 tools
Each tool targets a distinct step in the static-hosting lifecycle (publish, check activation, list, reconnect), and descriptions spell out the trigger conditions. The only soft overlap is between check_activation and reconnect_site, since both hinge on the user clicking an emailed link, though the preconditions (new site vs. lost key) are stated clearly enough to separate them.
All four tools follow a uniform snake_case verb_noun pattern (publish_site, check_activation, list_sites, reconnect_site). No mixed conventions or vague standalone verbs.
Four tools is a tight, purposeful surface for a static-site publishing service, with each tool earning its place. It sits at the low end of the comfortable range, but nothing feels redundant or padded.
Publish (create), re-publish (update), list (read), activation check, and key recovery are covered, so the core loop is closed. However, there is no way to unpublish/delete a site, rename it, or inspect a single site's details, which are predictable needs for a hosting service.
Deploy static sites from AI agents: deploy_site publishes files and returns a live URL in seconds.
Publish websites from your AI chat: pages, multi-file sites, ZIPs or templates, live in seconds.
Get share links, publish and manage websites, artifacts and agents. No account needed.
Publish a site your AI built to paid hosting, then read it back, change a page or restore a version.
