Loading
The hosted Thryvate MCP endpoint gives your assistant a safe set of tools to publish and refresh sites over HTTP, with nothing to install. Connect it in the browser and your AI can keep a site live as it works.
Thryvate runs a remote MCP server at https://app.thryvate.com/api/mcp. There is no binary to download, and an OAuth-capable client needs no token: add it as a remote MCP server and, on first connect, the client opens a browser for you to click Authorize, choosing how long the connection lasts (including never expiring). The credential is negotiated machine-to-machine and never passes through the chat.
claude mcp add --transport http thryvate https://app.thryvate.com/api/mcpAny client that supports HTTP (Streamable) MCP with OAuth works the same way: point it at the endpoint URL and approve the browser prompt. The server advertises its authorization server at /.well-known/oauth-authorization-server and answers an unauthenticated request with a 401 pointing there.
For an MCP client that cannot do the browser flow, authenticate with a Thryvate API token sent as a bearer header. A token can publish and change your sites, so treat it like a password: pass it as an environment variable or request header, never paste it into a chat or commit it. Create one in the dashboard, export it, then add the server.
export THRYVATE_TOKEN="<your token>"claude mcp add --transport http thryvate \
https://app.thryvate.com/api/mcp \
--header "Authorization: Bearer $THRYVATE_TOKEN"Any HTTP (Streamable) MCP connector works the same way: point it at the endpoint URL and send Authorization: Bearer <token>.
{
"mcpServers": {
"thryvate": {
"type": "http",
"url": "https://app.thryvate.com/api/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Create one token per agent so you can revoke a single client without disrupting the others, and revoke it any time from the dashboard.
The server exposes a small, focused set of tools. Each one maps to an action you could take in the dashboard, so there are no surprises.
| Tool | What it does |
|---|---|
publish_site | Publish a site from HTML or a bundle and return its stable link. Pass a slug to update the same site in place on later calls. |
update_site | Replace the contents of an existing site by id without changing its link, visibility, or allowlist. |
get_site_content | Fetch a site’s current entry document by id so your AI can read it, edit it, and push it back with update_site. |
list_sites | List your non-deleted sites with their status, visibility, links, and expiry. Filter by visibility, status, link expiry state, or sites expiring within N days. |
get_site | Fetch one site’s status, visibility, current version, view count, and the allowlist it’s shared with. |
set_visibility | Switch a site between public and a verified allowlist. |
list_allowlist | Show who a private site is currently shared with before you change it. |
add_to_allowlist | Add emails and/or domains to a private site’s allowlist without dropping anyone already on it. |
remove_from_allowlist | Take specific emails and/or domains off a private site’s allowlist, leaving everyone else. |
set_allowlist | Replace a private site’s entire allowlist with a new set of emails and/or domains (overwrites the existing list). |
set_render_options | Set per-site delivery: deep-link routing (free) and the external-origin allowlist (paid). |
set_link_expiry | Set or clear an expiry on a site’s share link (free on every plan). |
set_view_password / clear_view_password | Protect a site behind a view password or remove it. The password is never echoed back. |
list_access_requests | List people waiting for approval to view a private site. |
approve_access_request / deny_access_request | Approve (allowlisting the requester) or deny a pending access request. |
delete_site | Delete a site: purge its content and make the link non-viewable. |
list_versions | List a site’s versions newest-first with their size and timestamp. |
rollback_site | Restore a prior version as the current content; the link stays the same. |
Install the Thryvate plugin and your assistant gets ready-made commands (/thryvate:connect, /thryvate:publish, /thryvate:update, and /thryvate:share) that drive these same tools, so you skip explaining them every time.
Give publish_site a slug and the publish becomes idempotent: the first call creates the site, and every later call with the same slug updates it in place at the same URL. Anyone already viewing sees the new version live, without reloading, so your assistant can iterate while an audience watches the page evolve.
update_site and rollback_site work the same way: the share link, visibility, and allowlist all stay put. Pair it with a Premium custom domain and your audience always has one stable address, with no manual uploads and no broken links.
Every tool reports failures as a structured result with a stable code and a human-readable message, mirroring the REST API. An assistant can branch on the code (drop a disallowed file on bundle_invalid, prompt for an upgrade on plan_limit) instead of parsing prose.
{
"code": "bundle_invalid",
"message": "Disallowed file type in bundle: script.exe"
}