dropthis blog

How AI Agents Publish to the Web: MCP, CLI, SDK, or API

damian@dropthis.app (Damjan Malis) — Fri, 12 Jun 2026 00:00:00 GMT

An AI agent that can write HTML but can't put it anywhere is a typewriter without paper. The moment agents started generating reports, dashboards, games, and landing pages, "how do AI agents publish to the web" stopped being a hypothetical and became an architecture decision. There are four real answers — an MCP server, a CLI, an SDK, or a raw REST API — and we ship all four at dropthis, so this comparison comes from running them in production, not from reading other people's docs.

What are the four ways an AI agent can publish to the web?

An agent can publish through an MCP server (tool calls inside a chat client), a CLI (shell commands inside a terminal agent), an SDK (typed library calls inside a codebase), or a REST API (direct HTTP from anywhere). All four can produce the same result — a live URL — but they differ sharply in auth, setup, and who the natural caller is.

Surface	Natural caller	Auth model	Setup cost	Best for
MCP server	Claude, ChatGPT, Cursor, Windsurf	OAuth 2.1 (remote) or env key (stdio)	One connector entry	Conversational publishing
CLI	Claude Code, Codex, terminal agents	API key in env	One `npm install -g`	Repo and file workflows
SDK	Your application code	API key in env	One dependency	Products and pipelines
REST API	Any language, any runtime	Bearer key	Zero dependencies	Everything else

The split matters because agents don't choose tools the way developers do. A chat agent picks whatever tools its client exposes; a terminal agent reaches for shell commands; a cron job calls whatever its language can import. You don't pick the best surface in the abstract — you pick the one that meets the agent where it already runs.

When should an agent publish over MCP?

Use MCP when the agent lives in a chat client. The Model Context Protocol, open-sourced by Anthropic in November 2024 and adopted by OpenAI's Agents SDK in March 2025, lets clients discover a server's tools at runtime — so a publish capability appears to the model as a native tool, with typed inputs and structured results.

Two properties make MCP the right default for conversational agents:

Runtime discovery. The client fetches tool definitions when it connects. When a server adds a verb — say, update_settings next to publish — every connected agent gets it without a software update. The tool description itself teaches the model when to use it, which is why well-written descriptions measurably reduce misuse.

Delegated auth. Remote MCP servers authenticate with OAuth, so the user clicks "approve" once and no credential ever appears in the conversation. A scoped token (for example drops:write) limits what a hijacked session can do. The trade-off is operational: someone has to run that OAuth server, handle dynamic client registration, and enforce scopes on every dispatch — we learned each of those the hard way building mcp.dropthis.app.

MCP's weakness is the terminal. A coding agent mid-task doesn't want a connector handshake; it wants a command that exits 0.

When does a CLI beat an MCP server?

A CLI wins whenever the agent already has shell access and the content already lives on disk. Terminal agents like Claude Code work in repositories — they build a static site, then run one command to put it online. Flags are deterministic, output is parseable, exit codes signal failure, and there's no server hop between the agent and the publish call.

The pattern that makes CLIs agent-friendly is strict non-interactivity: every option a human would be prompted for must be a flag, because an agent can't answer an interactive prompt it can't see. Our own CLI contract treats any prompt in non-TTY mode as a bug.

CLIs also compose with the rest of the shell. An agent that just generated 40 HTML reports can glob, loop, and publish them in one pass — something a chat tool-call loop does slowly and expensively.

Where do SDKs and the REST API fit?

SDKs and REST are the pipeline surfaces. When publishing happens on a schedule or inside a product — a nightly report generator, a CI artifact step, an app that gives every user a shareable page — there is no chat client and no terminal, just code. An SDK gives you types and retries; raw REST gives you zero dependencies in any language.

The practical difference between them is small enough that the decision usually reduces to: use the SDK if it exists for your language, use REST if it doesn't. Either way the contract should be boring — one call in, one URL out:

import { Dropthis } from "@dropthis/node";

const client = new Dropthis(); // reads DROPTHIS_API_KEY from the environment
const drop = await client.drops.publish({
  content: html,
  title: "Q2 revenue report",
});
console.log(drop.url); // live URL, ~1s later

One number worth knowing when you wire this into an agent pipeline: payload limits. On dropthis, a free drop carries up to 5 MB and expires after 7 days; Pro raises that to 100 MB and permanent URLs. Agents that generate media-heavy pages hit size ceilings far sooner than humans do, so check limits programmatically instead of letting a 413 surprise your pipeline.

How does authentication differ across the four surfaces?

Remote MCP uses OAuth 2.1 with PKCE — the user approves once in a browser and the client holds a scoped token. Every other surface uses an API key read from the environment. The rule of thumb: interactive runtimes get OAuth so users never handle keys; non-interactive runtimes get keys because there is no user present to click "approve."

Surface	Credential	Where it lives	Revocation story
Remote MCP	OAuth 2.1 token, scoped	Chat client's token store	Disconnect the connector
Local (stdio) MCP	API key	MCP config env block	Rotate the key
CLI	API key	Shell environment / keychain	Rotate the key
SDK / REST	API key	Secret manager, CI secrets	Rotate the key

The OAuth 2.1 draft matters here because it made PKCE mandatory — which is what makes it safe for chat clients to register dynamically and connect without a pre-shared secret. If you're evaluating any publish-capable MCP server, the two questions to ask: does it enforce scopes on every tool dispatch (not just at token mint), and can a token downscope but never upscope? Both have been real vulnerabilities in shipping MCP servers — including, briefly, ours.

The failure mode nobody designs for: ghost drops

The most common bug in agent publishing isn't auth or payload size. It's identity: an agent generates an artifact, publishes it, loses the returned id, then "fixes a typo" by publishing again. Result: five URLs for one document, four of them stale. We call these ghost drops, and before we redesigned our verbs around the problem, they were the dominant pattern in our production data.

The fix is a vocabulary constraint, not a feature. publish never takes an id and always creates; update_content always takes an id and never creates. The publish response carries next hints telling the agent exactly which verb to use for follow-ups. Since shipping that split across all our surfaces, repeat-publish loops dropped to near zero. If you're building any publish tool for agents, make creation and mutation impossible to confuse — agents follow the grammar you give them.

Which surface should you pick?

Match the surface to the runtime, not to taste:

Agent in a chat client (Claude, ChatGPT, Cursor) → remote MCP with OAuth. Zero key handling for users.
Agent in a terminal (Claude Code, Codex) → CLI. Deterministic flags, shell composition.
Scheduled or product code → SDK in supported languages, REST anywhere else.
Unsure → start with REST; it's the substrate the other three are built on.

The deeper point: these aren't competing options, they're one capability that has to show up in four runtimes. An agent that publishes a report over MCP today may regenerate it from CI tomorrow — and if your publish layer doesn't keep ids, URLs, and verbs identical across surfaces, the handoff breaks. That consistency is the actual product. The transport is just plumbing.

How to Share Claude Artifacts at a URL You Control

damian@dropthis.app (Damjan Malis) — Fri, 12 Jun 2026 00:00:00 GMT

Claude artifacts are the fastest way to get a working page, game, or dashboard out of a conversation — and the slowest thing to get out of the chat window. If you want to share Claude artifacts with someone who wasn't in the conversation, you have two options: Claude's built-in share link, or publishing the artifact yourself at a URL you control. This tutorial covers the second path, and when it's worth the extra sixty seconds.

What are Claude artifacts, and when do you need your own link?

Artifacts are standalone outputs — HTML pages, React components, documents, diagrams — that Claude renders in a side panel (introduced by Anthropic in June 2024). Claude can share one at a public link, which is fine for show-and-tell. Publish it yourself when you need control: your domain, a password, updates in place, or an expiry you choose.

The control argument in one table:

	Built-in share link	Published yourself
URL	Anthropic's domain	Your drop URL or custom domain
Update in place	Re-share, new state	Same URL, new content
Password protection	No	Yes (Pro)
Search-engine control	Platform default	Your `noindex` choice
Expiry	Platform policy	7 days free, permanent or scheduled on Pro
Mix multiple artifacts	No	Yes — publish a folder

If none of those rows matter for the thing you just made, use the built-in link and stop reading. If one of them does, the rest takes about a minute.

How do you get an artifact out of the chat?

Open the artifact panel and either copy the code or download it as a file. HTML artifacts are self-contained — markup, styles, and script in one document — so what you copy is exactly what a browser needs. No build step, no dependencies, no framework runtime to install.

Two practical notes from publishing a lot of these:

Copy beats screenshot-and-rebuild. The artifact source is the deliverable. People rebuild artifacts in site builders far more often than they should.
React artifacts need an export step. Unlike HTML artifacts they assume a React runtime. Ask Claude to "convert this artifact to a single self-contained HTML file" first — it does this reliably, and the result publishes anywhere.

How do you publish the artifact to a URL?

The fastest path never leaves the chat: with a publish MCP connector installed, ask Claude to publish the artifact and it calls the tool itself — content in, URL back as the tool result. With dropthis's connector, that's the dropthis_publish tool over the Model Context Protocol, authenticated once with OAuth.

From a terminal it's one command on the downloaded file:

dropthis artifact.html --url
# → https://yourslug.dropthis.app/

Either way the response carries two things: the live URL and a drop id. The URL is for your audience. The id is for you — write it down next to the artifact, because it's the difference between updating the page and accumulating five stale copies of it. (Why ids and not URLs? See how agents keep publish and update straight.)

How do you update the page without changing the URL?

Pass the saved id to an explicit update verb: update_content over MCP, or dropthis drops update <id> artifact.html from the terminal. The URL your audience has keeps working; only the content changes. Publishing again instead would mint a second URL and strand everyone holding the first one.

This is the step both humans and agents get wrong, which is why it's a whole topic of its own in agent publishing. The rule is short: publish once, update forever. One artifact, one id, one URL for its whole life.

If you need the page to behave differently — password it, hide it from search, hang it on your own domain — that's update_settings, separate from content updates, so changing one never clobbers the other.

What about ChatGPT canvases and other AI output?

The same workflow applies to anything that produces HTML: ChatGPT canvases, Gemini outputs, agent-generated reports, or a folder your coding agent just built. Get the markup out, publish it, keep the id. The only thing that changes per platform is the export step — the publish-and-update loop is identical.

That's the deeper point behind this tutorial: AI tools are converging on generating publishable things, and the missing piece is rarely generation quality — it's a stable URL with your name on it. Whether the generator is Claude, ChatGPT, or an autonomous agent publishing over MCP, the contract you want underneath is the same: one call in, one URL out, updates that never break links. The surface — MCP, CLI, SDK, or REST — is just the transport. The permanence is the product.