publish-my
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PUBLISHMY_API_KEY | No | Environment override for your publish.my API key. | |
| PUBLISHMY_API_URL | No | Environment override for the publish.my API URL, used for testing. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| publish_siteA | 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). |
| check_activationB | Check 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. |
| list_sitesA | List the user's publish.my sites with their URLs, status and 30-day views. |
| reconnect_siteA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.