How to Connect an MCP Client to a Website Publishing Server

By Updated
Table of Contents

A website-publishing MCP server lets an AI client create files, publish a static site, and revise the same website without a separate deployment dashboard for every edit. The connection has three parts: a remote server URL, a supported transport, and authorization.

Revdoku’s hosted endpoint is:

https://app.revdoku.com/mcp

Use the Revdoku MCP landing page for copy-ready Claude, Codex, ChatGPT, OpenClaw, and generic-client instructions. This article explains how to validate the connection and choose between hosted MCP and local folder publishing.

Check the client first

The hosted Revdoku server needs a client that supports:

  • Remote MCP servers.
  • Streamable HTTP transport.
  • Browser-based OAuth.
  • Tool discovery after authorization.

Client interfaces vary. A setting may be called MCP server, custom connector, app, integration, or tool server. Workspace administrators may also control whether people can add connections.

If the client accepts only local STDIO commands, it cannot connect directly to this hosted URL. Use the Revdoku local client for files on the machine.

Add the server

In a generic compatible client:

  1. Create a remote MCP connection named Revdoku.
  2. Enter https://app.revdoku.com/mcp.
  3. Select Streamable HTTP if transport is requested.
  4. Select OAuth or Sign in with browser if authentication is requested.
  5. Save the connection.
  6. Complete the Revdoku authorization page in the browser.
  7. Return to the client and refresh its tools.

For Codex CLI, the same setup is:

codex mcp add revdoku --url https://app.revdoku.com/mcp
codex mcp login revdoku

For OpenClaw:

openclaw mcp set revdoku '{"url":"https://app.revdoku.com/mcp","transport":"streamable-http","auth":"oauth"}'
openclaw mcp login revdoku
openclaw mcp doctor revdoku --probe

Claude workspaces that expose custom connectors can add the same endpoint in connector settings. In ChatGPT, select the Revdoku app if it is available in the workspace. A normal chat prompt cannot install an app that the workspace does not expose.

Understand OAuth

OAuth should open a Revdoku page in the browser. Sign in there and approve the connection. Do not paste your password, a verification code, or any secret token into the AI conversation.

If authorization succeeds but no tools appear:

  1. Refresh the client’s connection list.
  2. Start a new chat or session.
  3. Ask the client to list tools from the Revdoku server.
  4. Disconnect and reconnect only if the client still shows a stale authorization state.
  5. Check whether a workspace administrator has restricted the connection.

Run a minimal publishing test

Start with one text file so the test isolates MCP from local-file access:

<!doctype html>
<html lang="en">
  <meta charset="utf-8">
  <title>MCP publishing test</title>
  <h1>First MCP publish</h1>
</html>

Ask the client:

Using Revdoku, create a website with this index.html, publish it, and return the website URL and identifier. Save that identity for the next step.

Open the URL and confirm the heading appears.

Then ask:

Update the existing Revdoku website you just published. Change the heading to “MCP update confirmed,” republish it, and return the URL. Do not create a new website.

Reload the original URL. The changed heading and unchanged URL verify that tool discovery, file writing, publishing, and identity reuse all work.

Authentication and previews

Revdoku requires OAuth before an MCP client stores files or creates a preview. Account creation stays in the browser; the AI client should never collect signup credentials in chat. After authentication, save a private draft and use a temporary 15-minute preview before publishing the main website.

Hosted MCP versus local publishing

Hosted MCP is a good fit when:

  • The AI client creates the site’s text files itself.
  • The website already exists in Revdoku.
  • The client needs to update or publish remotely.
  • You want one OAuth connection instead of moving credentials through prompts.

Use the local Revdoku client when:

  • The project is a folder on your computer.
  • It includes images, fonts, PDFs, archives, or other binary files.
  • A framework must run a local production build first.
  • The AI session already has safe shell access to the project.

A remote MCP server cannot read arbitrary files from your machine. Asking it to upload ./assets/logo.png does not make that local file available to the server. Publish the folder locally instead:

revdoku p path/to/site

Preserve the website identity

The most common workflow mistake is using a “create website” tool for every revision. Save the returned website or bucket identifier after the first publish and pass it back for updates.

Use instructions such as:

Update Revdoku website [identifier]. Replace its index.html with the revised version, publish that existing website, and confirm the URL remains [saved URL].

For local publishing, keep using the same bound project folder. See how to update an OpenClaw website without changing its URL for the full local update pattern.

Static hosting boundaries

An MCP publishing server can store and serve static output, but it does not turn a server application into a static site automatically. Before publishing:

  • Run the framework’s static production build.
  • Remove development-only references such as localhost.
  • Do not expose private environment variables.
  • Confirm client-side routes work on a static host.
  • Check that asset paths are relative to the published root.

If the project needs a continuously running server process or private server-side database connection, it needs a different runtime architecture.

Common connection errors

The client says the URL is unsupported

Confirm the client supports remote Streamable HTTP MCP, not only STDIO. Also enter the endpoint exactly, including https://.

OAuth completed but the client still says disconnected

Refresh or restart the client session. If it is managed by an organization, check the workspace connector policy.

Text files work but images do not

That is usually a local-file boundary, not an authentication failure. Use the local Revdoku client to upload binary assets.

The update created another URL

The client created a new website. Repeat the request with the original identifier and explicitly say to update the existing website.

The page opens but the app is broken

Confirm the published folder contains built static output and an index.html. Browser developer tools can reveal missing asset paths or references to a local development server.

Connection checklist

A complete MCP website-publishing test should prove all of these:

  • The server URL is correct.
  • OAuth completes in the browser.
  • Revdoku tools appear in the client.
  • A small static site publishes.
  • The returned URL opens.
  • A revision updates the same website.
  • Local binary files use the local client.
  • No credentials appear in chat or published files.

Once those checks pass, use the same small workflow in the real project: select the existing website, change files, publish, and verify the original URL.

Just ask to “publish to Revdoku” to publish your as a fast and secure website

from your Codex, Claude or another AI apppublish files or folders

Paste this into your AI app.

Free · Public or protected · Visitor analytics · Forms and email alerts Building websites for clients? Explore Revdoku for agencies

Share:
Markdown version
#MCP#website publishing#AI agents

Related Articles

↧
Loading PDF…