How to Publish Generated HTML From Windsurf

Table of contents

1. Cascade can create the output, but sharing is still a separate job
2. Decide whether the HTML is an artifact or a website
3. Use MCP when Cascade is still driving the handoff
4. Use the API when the workflow is deterministic
5. Return the link with source context
6. A practical Windsurf prompt

Cascade can create the output, but sharing is still a separate job

Windsurf Cascade is built to work inside a developer environment, and its MCP documentation describes connecting Cascade to external tools, APIs, databases, and services. That makes it a natural place for generated HTML work: Cascade can inspect project files, reason about a change, and produce a report or prototype that is easier to review in a browser than in a terminal response.

Common examples include:

• a code review report with grouped findings
• a release-readiness packet
• an incident timeline
• a dashboard snapshot from logs or test output
• a clickable prototype for stakeholder review
• a migration brief with tables, diagrams, and next actions

The weak point is the handoff. A local report.html works for the person sitting in Windsurf. It does not give a teammate a durable URL, source access, visibility controls, expiry, or a clear way to know whether the artifact changed after review.

That is the job BinHTML is built for. It publishes complete HTML documents as managed, sandboxed share links rather than asking every generated artifact to become a deployed website. For the broader workflow, start with the guide to publishing AI-generated HTML.

Decide whether the HTML is an artifact or a website

Before publishing from Windsurf, make the first decision explicit: is this output an artifact or a website?

Use an artifact link when the HTML is a work product:

• it explains a code change or technical decision
• it summarizes a run, incident, migration, or release
• it helps someone review an AI-generated output
• it may expire after the decision is made
• it should stay unlisted rather than indexed
• the owner may need to inspect the generated source later

Use website hosting when the output is meant to become a public site, production app, marketing page, custom-domain surface, or server-backed workflow. BinHTML is deliberately narrower than a deployment platform. It does not run server-side application code or provide application databases.

That distinction keeps the Cascade instruction clean. Ask Windsurf to prepare a reviewable HTML artifact, not to deploy a website, unless the output truly belongs in a deployment pipeline.

Use MCP when Cascade is still driving the handoff

MCP fits the interactive case because it lets an agent use external tools from the same workflow where it is reasoning. The MCP tools specification describes tools as named capabilities with schemas that a model can invoke to interact with external systems. Windsurf's Cascade MCP documentation covers adding servers, enabling tools, and connecting through supported transports.

With BinHTML, the useful MCP flow is:

1. Cascade creates or updates a self-contained HTML artifact.
2. Cascade calls a publishing tool such as publish_html for one artifact or publish_project for a packet of related artifacts.
3. BinHTML returns the share URL and source access context.
4. Cascade replies with the link plus a short reviewer note.

Use this path when the human is still collaborating with Cascade. For example, you might ask it to build a release review page, revise the risk section after feedback, then publish the final artifact to the same BinHTML project.

The BinHTML MCP docs are the source of truth for the tool contract and project publishing flow.

Use the API when the workflow is deterministic

The REST API is better when publishing is owned by a script, CI job, or scheduled workflow. If the automation already knows which HTML file to upload, what project it belongs to, and which visibility setting to use, it does not need the IDE agent to decide when to call a tool.

Use the API when:

• the artifact path is known
• the title, project name, visibility, and expiry are already configured
• retries and logging belong in the automation
• an API key is already available to the job
• the same workflow will run repeatedly

Windsurf can still help write or review that script. The final publish step should live where ownership lives: MCP for the active agent session, API for deterministic automation.

The BinHTML API docs describe the artifact publishing endpoint and the response fields a script should store or return.

Return the link with source context

A published URL is useful, but it is not the whole handoff. A reviewer still needs to know what the page represents and how to verify it.

Ask Windsurf to return:

• the BinHTML share URL
• the project link when several artifacts were grouped together
• a one-sentence purpose for the artifact
• the source file, branch, pull request, or commit the artifact describes
• the source download URL when the owner needs it
• the visibility setting and expiry window
• whether this created a new artifact or updated an existing link
• any missing data, stale assumptions, or review caveats

This protects the review workflow from polished but ambiguous output. A generated HTML page can look complete while still depending on the wrong inputs. The link-centered handoff should make ownership and evidence visible.

If several Windsurf outputs belong together, publish them to one stable project name and put run-specific details in artifact titles. That keeps the reviewer focused on one handoff URL instead of a fresh link for every revision. See project links for AI-generated HTML workflows and stable project names for recurring HTML workflows for the pattern.

A practical Windsurf prompt

Use a prompt like this when the artifact is ready to share:

For a multi-artifact handoff, make the project explicit:

That gives Cascade a precise boundary. It should generate the HTML, publish the artifact or project, and return a link-centered handoff. It should not paste the full HTML into chat, create a full deployment unless you asked for one, or hide important source context in the conversation.

Final thought

Windsurf is a strong place to create generated HTML because Cascade already has project context and can connect to tools through MCP. The missing step is disciplined publishing.

Treat Windsurf-generated HTML as an artifact first. Publish it with the visibility, source access, project grouping, and expiry the review job needs. Save full deployment work for outputs that are actually meant to become websites.