Connect your LLM to Just Publish.

Which endpoint

Two connectors, one per assistant, because an OAuth token is bound to the endpoint that issued it. Pick by which assistant you are connecting, not by what you want to publish - the publishing behaviour is identical. Adding the server by hand, in a client that does not do OAuth? That endpoint is below Quick start.

Quick start

Add the endpoint your client needs, then ask the model to publish your files. Each tab below uses the endpoint from the table above; the tool reference and the JSON-RPC examples further down document the open one. Want click-by-click connect steps instead of the raw schema? See Connect your AI assistant.

Server URL: https://mcp.justpublish.ai/claude
Authentication: OAuth 2.1 - Just Publish registers itself, so there is
                no client ID or client secret to fill in

{
  "mcpServers": {
    "just-publish": {
      "url": "https://mcp.justpublish.ai/"
    }
  }
}

Server URL: https://mcp.justpublish.ai/
Authentication: None

Once connected, ask the model something like: "Publish this HTML to Just Publish and give me the URL." The model calls deploy and hands back the live URL. On the open endpoint it also returns a site_id and an edit_token, and the token is the only way to update that exact site later. On a signed-in endpoint the site belongs to the account, so the assistant can find and edit it again without a token.

The signed-in endpoints, in detail

https://mcp.justpublish.ai/claude and https://mcp.justpublish.ai/chatgpt run the same server as the open endpoint, behind OAuth 2.1, for clients that require an authenticated connector. A site published there is filed under the signed-in person's account: deploy takes no email parameter, and the site is live immediately with nothing to prove afterwards. On the open endpoint at https://mcp.justpublish.ai/, which the steps above configure for a hand-added client, the email argument carries that accountability instead. The signed-in discovery documents are https://mcp.justpublish.ai/.well-known/oauth-protected-resource/claude and https://mcp.justpublish.ai/.well-known/oauth-protected-resource/chatgpt. They are separate endpoints so each connector gets its own audience-bound token, and each advertises the contract that directory's rules require: on /chatgpt, deploy creates a new site only and no tool takes an edit_token.

Because it knows who is asking, a signed-in endpoint serves a fourth tool the open one cannot: list_sites, which takes no parameters and returns the websites that person has already published - live URL, site_id, whether each is live or archived, when it was last updated, and any connected custom domain. It is how an assistant finds a site whose edit_token was lost. On those endpoints get_site_files and update_site_file also work without an edit_token on that person's own sites.

Setting up the Claude connector, step by step and for every Claude surface: Connect Just Publish to Claude.

Adding the server by hand

A client that does not do OAuth adds the open endpoint instead. Same server, same publishing behaviour, three tools rather than four.

Tool reference - deploy

Publishes a static site. First call (no site_id) creates a new site and returns its credentials. Later calls with the same site_id + edit_token update the site in place. The schema below is the one served at https://mcp.justpublish.ai/; on a signed-in endpoint deploy takes no email and edit_token is optional on your own sites.

Parameters

File object

Response (success)

{
  "url":            "https://xK3p9wnA2b.justpublish.site/",
  "site_id":        "xK3p9wnA2b",
  "edit_token":     "...",            // only on create
  "created":        true,             // false on update
  "files_uploaded": 4,
  "total_bytes":    12842
}

Errors

Errors come back as a tool-call result with isError: true and a human-readable message - not as a JSON-RPC error. The model surfaces the message to the user.

JSON-RPC examples

Create a new site

POST https://mcp.justpublish.ai/
Accept: application/json, text/event-stream
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "deploy",
    "arguments": {
      "email": "you@example.com",
      "files": [
        { "path": "index.html", "content": "<h1>hello world</h1>" }
      ]
    }
  }
}

Update an existing site

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "deploy",
    "arguments": {
      "email": "you@example.com",
      "site_id": "xK3p9wnA2b",
      "edit_token": "the token you saved at create time",
      "files": [
        { "path": "index.html", "content": "<h1>hello v2</h1>" }
      ]
    }
  }
}

Constraints

• index.html at the root of the file map is required. A site without it is rejected at deploy.
• Max site size: 50 MB. Max single file: 5 MB. Max 500 files per site.
• Path rules: no .., no leading /, no backslash, no null bytes. The deploy is rejected at validation time, not silently truncated.
• Per-IP rate limits on both site creation and deploys per rolling hour.
• Static files only. No server-side execution, no build step, no environment-variable injection.
• Sites with no traffic for an extended period may be archived (TTL policy).

Edit token & persistence

The edit_token is the only credential needed to update a site over MCP. It's returned once, at create time, and never again - the server stores only a hash. Store it alongside the site_id in your LLM's conversation context, in a saved note, or wherever your client keeps state across sessions.

Losing the token orphans the site from MCP updates. Recovery: sign in at /login with the email you used at deploy time. The dashboard lists your sites and uses session-authenticated HTTP endpoints (not the edit_token) to update or delete them.