This server hosts its own plugin marketplace, named dropper, with one plugin: dropper-kit. It carries the dropper-cli skill and nothing else — no MCP server. Once it is installed, Claude uses the skill whenever a task asks to publish, share or host something, and you can invoke it directly as /dropper-kit:dropper-cli.

claude plugin marketplace add https://dropp.sh/plugin/marketplace.json
claude plugin install dropper-kit@dropper

A marketplace added by URL is not refreshed in the background. After a Dropper release, update the marketplace, then the plugin, and restart Claude Code.

claude plugin marketplace update dropper
claude plugin update dropper-kit@dropper

A one-off headless run, such as a CI job or a throwaway container, can load the plugin for that session alone, with no marketplace.

claude -p --plugin-url https://dropp.sh/plugin/dropper-kit.zip "publish ./dist and give me the URL"

The same skill is a single file at /skill.md, in the Agent Skills format. Put it in the skills directory of any agent that reads SKILL.md files, or use it in Claude Code without the plugin. Committed to a repository, it reaches everyone who works there, cloud sessions included.

# for you, in every Claude Code session
curl -fsSL https://dropp.sh/skill.md --create-dirs -o ~/.claude/skills/dropper-cli/SKILL.md

# for everyone who works in a repository: commit it there
curl -fsSL https://dropp.sh/skill.md --create-dirs -o .claude/skills/dropper-cli/SKILL.md

A sandbox needs three things: a personal API key in its secrets (mint one on the API Keys page), the CLI from its setup script, and network access to this server. The skill never prints the key; it proves the setup with dropper whoami.

# the sandbox's secrets
DROPPER_URL=https://dropp.sh
DROPPER_TOKEN=your-api-key

# its setup script
curl -fsSL https://dropp.sh/install.sh | sh
dropper whoami   # exit 0 = ready

The whole CLI, plus the things that make an agent's first publish go wrong. The CLI reference has every flag; the skill carries the judgement around them.

• Setup: install the CLI when it is missing, authenticate with an API key, prove it with dropper whoami, and read each whoami failure (no key, a rejected key, no network, a suspended account).
• Publishing: which files and directories dropper drop takes, the flags, and the output contract — the URL on stdout, a generated password on the next line, one error line and exit 1 on failure.
• Labels: every drop gets its project path (--label <repo>, or <repo>/<area>), reusing a path dropper labels ls already shows; the name rule, and renaming, moving, recolouring and deleting labels.
• Built sites: drop the build output, never a repository root (every file goes up, dotfiles such as .env included; symlinks are skipped); use relative asset URLs or a base path, because a drop lives under /d/<handle>/<slug>/; no SPA fallback; the entry-page order and the content types.
• Markdown: how a .md renders for browsers and serves its source to curl, mermaid diagrams, and that raw HTML inside Markdown shows as text.
• Updating: replace content under the same URL, rename, protect or unprotect, change the description or labels, and a create-or-replace snippet so a rerun updates the drop it made instead of failing.
• Checking: dropper list (and list --label) and whoami --json, and that 200 — or 401 for a protected drop — means the page is live.
• One file at a time: add, replace or delete single files, or have the server fetch an https URL into the drop, through the REST API with the API key.
• Judgement: it asks before deleting a drop, renaming it, listing it in the gallery, removing its password or renaming, moving or deleting a label, never publishes credentials or .env files, and replies with the URL rather than the page.