API vs MCP: Choose the Right Publishing Path for AI-Generated HTML

Table of contents

1. The publishing choice is about ownership
2. Use the API for deterministic automation
3. Use MCP for agent-driven handoff
4. Keep the contract the same
5. A practical decision checklist
6. Final thought

The publishing choice is about ownership

Publishing generated HTML is not one workflow. Sometimes the HTML file is already done and a deterministic process needs to upload it. Sometimes an agent is still deciding what to generate, how to group outputs, and what link to hand back.

That difference matters more than the transport.

OpenAPI exists so humans and tools can understand an HTTP API without reading the service source. MCP gives models a tool interface built around JSON-RPC messages, capabilities, schemas, and tool calls. Both are useful. They just sit in different parts of the workflow.

For BinHTML, the rule is simple: use the API docs when your code is the publisher. Use the MCP docs when your agent is the publisher.

Use the API for deterministic automation

The REST API is the right fit when the publishing step is already part of a known system:

• a CI job creates an HTML test report
• an internal script exports a weekly dashboard
• a backend service publishes a generated report after a user action
• a scheduled job uploads the same artifact shape every time

In these cases, the caller already knows the file, title, project name, visibility, expiry, and API key. The API request is a clean contract: send sourceHtml, get back the share URL, management URL, and source download URL.

This is also easier to review operationally. You can log the request ID, validate the payload before upload, retry predictable failures, and keep secrets in the system that already runs the job.

If your team wants a stable machine interface for publishing, start with /api/v1/artifacts and keep the agent out of the final network call.

Use MCP for agent-driven handoff

MCP is a better fit when the agent is doing more than uploading a finished file.

A good MCP publishing task might sound like this:

1. Generate a status report from these logs.
2. Publish the HTML to the Launch project.
3. Return the BinHTML link and a short review note.

The agent can call publish_html or publish_project as part of the same session where it reads context, revises the artifact, and prepares the handoff. That is the point of a tool interface: the model can discover a capability, call it with structured arguments, and include the result in its answer.

MCP also puts human review in the right place. The current MCP tools specification treats tool calls as model-controlled, while recommending clear UI, tool visibility, and confirmation for sensitive operations. Publishing generated HTML is exactly the kind of action where a visible tool call and a clear result are useful.

Use MCP when the handoff is still conversational. Use the API when the handoff has already become infrastructure.

Keep the contract the same

The two paths should not create two product behaviors. Whether the caller uses REST or MCP, the output should still be a managed BinHTML artifact:

• sandboxed rendering for the shared HTML
• an unlisted or private visibility choice
• optional expiry where the plan supports it
• source access through the management surface
• project grouping when several outputs belong together
• a link that can be shared, reviewed, compared, or revoked

That consistency is what lets teams mix workflows. A CI job can publish a first report through the API. An agent can later publish a revised review packet through MCP. A reviewer can use Compare before sending the updated link.

For multi-file work, publish the related outputs into a project link instead of pasting several artifact URLs into a ticket. If that becomes a regular team workflow, check the pricing page so plan limits and project share requirements are clear before automation depends on them.

A practical decision checklist

Use the API when:

• the HTML already exists before the agent starts talking
• the workflow runs from CI, a backend, or a scheduled job
• the caller needs explicit retries, logs, and secret handling
• the same payload shape is published repeatedly
• the final step should be owned by infrastructure

Use MCP when:

• the agent is generating or revising the HTML in-session
• the user wants the agent to return the final share link
• several artifacts need to be grouped into one project handoff
• the publish step should be visible as an agent tool call
• the workflow benefits from a natural language instruction instead of custom glue code

There is no need to force one path everywhere. The better system is usually boring: API for repeatable automation, MCP for agent-native publishing, and the same BinHTML artifact lifecycle behind both.

Final thought

The question is not which protocol is more modern. The question is who owns the last mile of the handoff. If your system owns it, call the API. If your agent owns it, expose MCP and let the agent publish through a visible, reviewable tool call.