Use Artifact Links, Project Links, and Compare Views for Different Review Jobs

Table of contents

1. Start with the review job, not the publish method
2. Use one artifact link for one deliverable
3. Use a project link when the handoff has multiple parts
4. Compare before you approve a regenerated artifact
5. Pick API vs MCP based on who decides what gets published
6. A default handoff pattern for teams

Start with the review job, not the publish method

Teams often ask whether they should publish through the API or through MCP. That is a useful implementation question, but it is usually not the first decision.

The first decision is simpler: what kind of review job are you creating?

• one report, prototype, or dashboard that stands on its own
• a bundle of related outputs that should be opened together
• a revised artifact that should be checked against an earlier version before anyone acts on it

BinHTML supports all three cases, but the handoff works better when the link shape matches the review job.

Use one artifact link for one deliverable

Use a single artifact link when the output is one thing people can review in one pass: one migration plan, one CI summary, one design option, or one research brief.

BinHTML's API docs describe the base publish flow clearly: send a complete HTML document, get back a hosted share URL, a management URL, and a source download URL. The MCP docs describe the same publish path for agents that call BinHTML as a remote tool.

A single artifact link is the right default when:

• the output has one owner and one reviewer path
• the artifact summary explains the whole job
• a follow-up should create a new version, not a second sibling link

If you mostly need a stable link an agent can return at the end of a run, stop here. Do not create a project page just because the product supports projects.

For the low-level publish contract, see API vs MCP: Choose the Right Publishing Path for AI-Generated HTML.

Use a project link when the handoff has multiple parts

A project link is better when the review packet is a set, not a file.

Typical cases:

• an executive summary plus a detailed appendix
• a design comparison plus supporting research notes
• a CI report plus a remediation checklist plus a rollout plan

In those cases, the project page becomes the handoff surface. Each artifact still has its own viewer, but the reviewer starts from one index URL instead of a pasted list of separate links.

This is also the point where plan limits matter. BinHTML's pricing page positions project share links as a Pro feature, while the standard artifact publish flow remains the base path for ordinary uploads. That split is useful in practice: most teams should start with single artifacts, then add project links when the review loop is consistently multi-part.

If your team is already sharing bundles, keep the project page narrow. It should explain what belongs in the packet and link to the artifacts. It should not turn into another free-form surface. For the product-specific shape, see Project Share Pages: One URL for a Multi-Artifact Handoff.

Compare before you approve a regenerated artifact

A regenerated artifact is not the same review job as a first publish.

Once an agent revises an HTML artifact, the question changes from "can I open this?" to "what changed, and should I trust the change?"

That is where compare views matter. The compare step should happen before the updated link is treated as approved. This is especially important when the artifact includes:

• changed numbers or conclusions
• revised outbound links or embedded assets
• removed warnings, assumptions, or caveats
• structural changes that affect how someone interprets the page

BinHTML's Compare section is the right place to anchor that habit. If you want the broader workflow, pair this with Compare Before You Share: Reviewing Agent-Generated HTML Changes.

A simple rule works well: first publish creates the review link, later publishes create a review decision.

Pick API vs MCP based on who decides what gets published

After you know the review job, the API vs MCP choice is straightforward.

Use the API docs when your script, CI job, or backend already knows exactly what to publish. The caller has the HTML, the title, and the project grouping logic, so the publish step is just one more HTTP request.

Use the MCP docs when the agent is still deciding what the output set should be. The Model Context Protocol defines a standard tool interface, and OpenAI's MCP documentation describes how remote MCP servers can expose tools to model-driven workflows. That fits BinHTML well when the agent needs to decide whether the handoff is one artifact or a grouped project.

A practical split looks like this:

• API: deterministic pipelines, CI jobs, scheduled reports, backend-owned publish steps
• MCP: interactive agent sessions, research assistants, coding agents, and tool-driven review flows

Do not force everything through MCP if the publish step is already deterministic. Do not bolt on raw API calls inside prompts if the agent already has a clean remote MCP tool.

A default handoff pattern for teams

If you want one repeatable default, use this:

1. Publish one artifact first.
2. If the work naturally expands into a packet, group the outputs under one project link.
3. If the artifact is regenerated, compare before anyone approves or forwards it.
4. Return the hosted links, not the HTML blob, in agent tool results.

That pattern keeps the workflow understandable for humans and easy to automate for agents.

Final thought: teams get cleaner review loops when they stop treating every generated HTML output like the same kind of thing. Pick the link shape that matches the review job, and the rest of the workflow gets simpler.