This MCP server lets an agent sign in to Drop2Run, publish files or folders as sites, list sites, and permanently delete sites.
Sign in via browser (login) or device code (login_code), storing an access token; optionally replace an existing token and wait up to 240 seconds for approval.
Publish text files (publish_files) as a site, returning the live URL, site ID, subdomain, file count, and whether unchanged; supports a new site or publishing over an existing one.
Publish a folder (publish_dir) of static files (requires index.html at root, or .md/.pdf files) and get the same structured publish result.
List sites (list_sites) on the account, including each site’s ID, subdomain, URL, and name.
Delete a site (delete_site) permanently, including files, history, and subdomain, with a required exact subdomain confirmation to prevent accidental deletion.
Source for the two Drop2Run packages that run on your machine: the drop2run
command line tool and the @drop2run/mcp server.
Both are installed globally and then handed a credential. This repository exists so you can read what you are giving that credential to.
npm i -g drop2run # https://www.npmjs.com/package/drop2run
npx @drop2run/mcp # https://www.npmjs.com/package/@drop2run/mcpThe command line tool signs in through a browser and publishes a folder:
drop2run login
drop2run deploy distlogin needs a browser on the same machine; drop2run login --device covers a remote shell, and CI
uses a DROP2RUN_TOKEN from https://dropto.run/account/tokens. The other commands are init,
ls, open, rollback, rm, token list, whoami and where, and --json on any of them
prints machine-readable output.
The MCP server is registered with a client rather than run by hand. Claude for macOS and Windows
installs it from a bundle — download drop2run.mcpb and open it,
and there is no config file and nothing to install first. Claude Code takes one command:
claude mcp add drop2run -s user -- npx -y @drop2run/mcpIt exposes seven tools — publish_files, publish_dir, list_sites, list_folders, delete_site,
and login / login_code to get a token without leaving the chat. The publishes answer with structured fields
beside the sentence, so a URL does not have to be read back out of prose; delete_site is permanent
and asks for the site's subdomain repeated back before it runs. The token goes to the same place the
CLI stores one, so signing in through either covers both.
Each package documents itself in full, including the sign-in flows and what happens without a
site: packages/cli/README.md and
packages/mcp/README.md. The hosted documentation is at
dropto.run/docs/cli and
dropto.run/docs/mcp.
Related MCP server: Nippy
Package | Published | What it is |
| The command line tool: | |
| An MCP server, so an agent can publish what it just wrote | |
| no | The deploy engine — manifest, hashing, upload, go-live. No Node APIs, no browser APIs |
| no | The parts that need |
core and node are not published. They are bundled into each package's dist/ at build time, which
is why drop2run installs with no runtime dependencies at all — an intentional choice for
something that holds a token. @drop2run/mcp has two, both required by the protocol:
@modelcontextprotocol/sdk and zod.
Each package stands alone — there is no workspace root, and internal imports resolve through the
relative paths in each tsconfig.json.
cd packages/cli # or mcp, or node
npm ci
npm run typecheck
npm test
npm run build # writes dist/, which is what npm shipspackages/core has no dependencies and no build of its own; it is typechecked by the packages that
bundle it.
This repository is an export of the four packages above, with their full history. The Drop2Run service itself — the API, the edge router, the dashboard — is not here and is not open source. What that means in practice: the code that decides what happens to a file after it leaves your machine is not something this repository lets you audit. What it does let you audit is everything that happens to your files and your token before that point, which is the part that runs with your privileges.
Issues about the CLI or the MCP server are welcome here. Anything about the hosted service belongs at dropto.run/contact.
Pull requests are welcome too, with one thing worth knowing first: this repository is generated, so a pull request is not merged here. The change is applied in the source repository and reaches this one in the next export, with your commit and its authorship carried along; the pull request is then closed with a link to the commit. Merging it here instead would put a commit in this history that no future export contains, and the two would diverge on the very next update.
MIT.
Takes a site down permanently — its files, its history and its subdomain. Nothing here undoes it, and the subdomain becomes available for anybody to claim. Requires confirm to repeat the site's own subdomain exactly; ask the person for it rather than filling it in from what you already know, because that is the step this asks for.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | Subdomain or site id to delete. | |
| confirm | Yes | The subdomain of the site being deleted, repeated exactly. A mismatch refuses the call rather than guessing which site was meant. |
| Name | Required | Description |
|---|---|---|
| siteId | Yes | Identifier of the site that was deleted. |
| subdomain | Yes | Its subdomain, now unclaimed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds real value beyond that: explicit irreversibility ('Nothing here undoes it'), the concrete consequence that the subdomain becomes claimable by anyone, and the refuse-on-mismatch guardrail behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the permanence and consequence before the confirm mechanics, so the most decision-relevant fact lands first. Slightly long but every clause carries distinct information (scope, irreversibility, subdomain consequence, confirm protocol).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need no explanation; annotations cover the safety profile; schema covers both params. The description fills the remaining gap — permanence, real-world consequence, and the confirm protocol — leaving nothing an agent needs to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, and the confirm description covers the mismatch-refusal. The description adds workflow meaning the schema lacks — that the confirm value should be solicited from the user rather than supplied from prior knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('takes a site down permanently') plus the full blast radius — files, history, subdomain. An agent can distinguish this from list_sites (read) and the publish_* siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives strong procedural guidance for the confirm step (ask the person rather than volunteering the value), which is genuinely useful usage direction. However, it never routes the agent to or away from alternatives (e.g. list_sites to identify the target) and offers no explicit when-not-to-use framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the sites on this account, so a publish can go to one of them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sites | Yes | Every site on this account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful scope constraint that results are limited to 'this account', but says nothing about ordering, pagination, or empty-result behavior; with annotations carrying the main burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence, front-loaded with the verb and resource and ending with the motivating use case. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument read-only lister with an output schema that documents the return shape, the description supplies scope and purpose adequately. Only minor gaps remain (ordering/pagination, what to do with the returned identifiers), which the output schema largely mitigates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and fully described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists the sites') plus scope ('on this account'), and hints at the downstream purpose ('so a publish can go to one of them'). It is clearly distinguishable from the mutation siblings (delete_site, publish_*) without naming them, so it stops just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so a publish can go to one of them' implies the workflow context — call this before publishing to obtain a valid target — but there is no explicit when-to-use/when-not statement and no sibling is named as an alternative or prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Signs in through a browser on this machine and stores an access token, which every other tool then uses. Opens the browser here and waits for the person to approve. If it answers that nothing has been approved yet, call it again to keep waiting — that is not a failure. Needs no command line and no token pasted by hand.
| Name | Required | Description | Default |
|---|---|---|---|
| replace | No | Sign in even though a token is already stored. Use when switching accounts, or when the stored token is being refused. | |
| waitSeconds | No | How long this call waits for the approval before answering. Default 120. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true and non-idempotent, so the agent knows this reaches outside the machine. The description adds real value beyond that: it discloses browser launching, human approval, token persistence for other tools, and the non-obvious retry-on-pending semantics that would otherwise look like an error. It stops short of token lifetime or what a successful response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the core action and impact, then the mechanics, then the critical retry caveat. Every sentence carries information; only the closing 'no command line' clause is arguably redundant with the browser-first framing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no required args and no output schema, the description covers the interaction model, the blocking/wait behavior, and how to interpret an inconclusive result. It does not describe the shape of a success response, but the pending-approval case — the only one that could confuse an agent — is handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'replace' and 'waitSeconds' fully documented in the input schema, so the baseline is 3. The description's 'waits for the person to approve' loosely corresponds to waitSeconds but adds no syntax, default, or constraint detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource ('Signs in through a browser on this machine and stores an access token') and clarifies downstream impact ('which every other tool then uses'). It implicitly contrasts with the code-paste flow ('no command line and no token pasted by hand') but never names the sibling login_code, so the differentiation is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational guidance for the tricky case: a 'nothing approved yet' answer is not a failure and the tool should be called again to continue waiting. It also implies the no-prerequisite case ('needs no command line and no token pasted by hand'), but it never states when to prefer this over login_code, leaving one gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Signs in where no browser can be opened on this machine — a container, a remote host. The first call returns a short code and a URL to enter it at, which the person opens anywhere; call it again to wait for the approval and store the token.
| Name | Required | Description | Default |
|---|---|---|---|
| replace | No | Sign in even though a token is already stored. | |
| waitSeconds | No | How long a waiting call polls before answering. Default 120. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-idempotent, open-world operation, and the description adds the genuinely useful behavior beyond them: a two-phase interactive handoff with a human, a long-polling wait, and persistence of the resulting token. It does not spell out what happens to an existing token (the schema's 'replace' parameter carries that), so it is not fully self-contained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, no filler, and the disqualifying condition (no browser available) is front-loaded before the mechanics. Every clause contributes information an agent needs to drive the flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully explains what the first call returns (a short code and a URL to enter it at) and what the second call accomplishes (wait for approval, store the token). Nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so 'replace' and 'waitSeconds' are already documented with their semantics and bounds. The description only alludes to 'call it again to wait', adding no syntax or default detail beyond the schema — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource ('signs in') and immediately bounds the scenario ('where no browser can be opened on this machine — a container, a remote host'), which separates it from the sibling 'login' tool. An agent can pick this over 'login' without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage condition is explicit and memorable (headless/remote environment with no browser), and the description explains the required call pattern: call once to get a code, call again to wait and store the token. It stops short of naming 'login' as the alternative for browser-capable machines, so routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publishes a folder of static files and returns its URL. The folder needs an index.html at its root, or .md and .pdf files, which are served through the reader.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path of the folder to publish. | |
| site | No | Subdomain or site id to publish over. Omit to create a new site. |
| Name | Required | Description |
|---|---|---|
| url | Yes | The live URL of the published site. |
| files | Yes | How many files the site now serves. |
| siteId | Yes | Identifier of the site, stable across publishes. |
| subdomain | Yes | The site's subdomain, which is what `site` accepts. |
| unchanged | Yes | True when every file already matched what the site served, so no new version was published. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds genuine behavioral context beyond the annotations: the index.html-at-root requirement and the .md/.pdf reader-serving path. However, the annotations flag destructiveHint=true and the description is silent on what publishing over an existing 'site' destroys or replaces, which is exactly the consequence an agent needs before invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with the action and return value front-loaded and the content requirement second. Nothing is redundant, though the second clause packs two distinct ideas (required file types and reader serving) together.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers the returned URL, so the description needn't explain returns. What remains missing is the destructive/overwrite behavior implied by the annotations and the 'site' parameter, which is the main risk an agent must understand before calling a write tool that replaces a site.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, and the description adds the folder-content contract (index.html or .md/.pdf) that constrains 'path'. It adds no semantics for 'site' (e.g., whether publishing over an existing id replaces content), so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Publishes a folder of static files') and adds the outcome ('returns its URL'), which is precise enough to act on. It never distinguishes itself from the sibling publish_files, so an agent must infer the folder-vs-files split from the names alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of the sibling publish_files as the alternative, and no prerequisites (auth, ownership of the target site). The only routing signal is the tool name itself; the description offers none.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publishes one or more files written here — markdown, HTML, CSS, JSON — as a site, and returns its URL. A single page goes at index.html; a single .md, .markdown or .pdf file is a site on its own, served through the documents viewer. Text only: a PDF or an image has to be published from disk with publish_dir.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Subdomain or site id to publish over. Omit to create a new site. | |
| files | Yes | The files to publish. |
| Name | Required | Description |
|---|---|---|
| url | Yes | The live URL of the published site. |
| files | Yes | How many files the site now serves. |
| siteId | Yes | Identifier of the site, stable across publishes. |
| subdomain | Yes | The site's subdomain, which is what `site` accepts. |
| unchanged | Yes | True when every file already matched what the site served, so no new version was published. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered; the description adds real behavioral context — the returned URL, the text-only content constraint, and how single files are served through the documents viewer. It does not, however, disclose what happens when publishing over an existing site id (overwrite vs. merge), which is the main risk implied by destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and return value, then routing rules, then the hard exclusion. No filler, and each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and the description covers content-type limits and the sibling handoff well. The remaining gap is the behavior of republishing onto an existing site, which matters for a tool flagged destructive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description goes beyond the schema by explaining how paths map to pages (a single page at index.html; a lone .md/.markdown/.pdf becomes its own site). It adds little about the `site` parameter beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Publishes one or more files written here ... as a site, and returns its URL') and immediately differentiates itself from the sibling publish_dir by naming what it cannot handle. An agent can distinguish this from publish_dir and delete_site without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: files written in this session go here, while 'a PDF or an image has to be published from disk with publish_dir.' It also names the alternative tool and the exact condition that selects it, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1delete_sitelist_sites1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "sites": {
+ "description": "Every site on this account.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "What it is called, or null when it has no name.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "siteId": {
+ "description": "Identifier of the site.",
+ "type": "string"
+ },
+ "subdomain": {
+ "description": "Its subdomain, which is what `site` accepts.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Its live URL.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "siteId",
+ "subdomain",
+ "url",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "sites"
+ ],
+ "type": "object"
+}loginlogin_codepublish_dir1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "files": {
+ "description": "How many files the site now serves.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "siteId": {
+ "description": "Identifier of the site, stable across publishes.",
+ "type": "string"
+ },
+ "subdomain": {
+ "description": "The site's subdomain, which is what `site` accepts.",
+ "type": "string"
+ },
+ "unchanged": {
+ "description": "True when every file already matched what the site served, so no new version was published.",
+ "type": "boolean"
+ },
+ "url": {
+ "description": "The live URL of the published site.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "siteId",
+ "subdomain",
+ "files",
+ "unchanged"
+ ],
+ "type": "object"
+}publish_files1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "files": {
+ "description": "How many files the site now serves.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "siteId": {
+ "description": "Identifier of the site, stable across publishes.",
+ "type": "string"
+ },
+ "subdomain": {
+ "description": "The site's subdomain, which is what `site` accepts.",
+ "type": "string"
+ },
+ "unchanged": {
+ "description": "True when every file already matched what the site served, so no new version was published.",
+ "type": "boolean"
+ },
+ "url": {
+ "description": "The live URL of the published site.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "siteId",
+ "subdomain",
+ "files",
+ "unchanged"
+ ],
+ "type": "object"
+}v0.2.0list_sitespublish_dirpublish_filesScored across 6 tools
login and login_code are clearly differentiated by environment (browser vs. headless), and publish_files vs publish_dir are distinguished by input type (files vs directory). However, the boundary between publishing text content and static files could be slightly clearer, as both result in a site.
All tool names use snake_case and follow a verb_noun or noun_verb pattern (login_code, publish_files, delete_site, list_sites). The only minor deviation is 'login' lacking a noun, but it's intuitive and consistent overall.
Six tools provide a well-scoped set covering authentication, publishing, deletion, and listing. Each tool earns its place without redundancy or excessive granularity.
The surface covers authentication, publishing, listing, and deletion, which are the core operations for managing sites. Minor gaps include no explicit update or rename for existing sites, and no tool to retrieve a site's metadata or content, but these are workaroundable by re-publishing or listing.
Deploy static sites from AI agents: deploy_site publishes files and returns a live URL in seconds.
Publish static sites to permanent URLs in one call. No account, email code, or claim link.
Deploy the small apps your agent builds: one tool call returns a live, private shareable HTTPS link.
Instant web publishing for AI agents. POST HTML, get a live URL. No account needed.
