Skip to main content
Glama

plopino

CLI: publish with one command

npx -y plopino publish ./index.html
npx -y plopino publish ./dist --json
npx -y plopino login
npx -y plopino publish ./dist --update https://plopino.com/b/YOUR_BOARD_ID/
npx -y plopino whoami
npx -y plopino logout

login prompts for an email and a hidden password. Create an account on the website first if needed. Login claims available anonymous uploads made with this CLI's saved identity, reports how many were claimed, and saves a session for future uploads. An existing PLOPINO_TOKEN overrides the saved session for publishing. For Google/GitHub-only accounts, use an API token for future uploads; CLI password login requires an account with a password.

Cookies are stored per server origin under ~/.config/plopino/, with owner-only file permissions. Override the directory with PLOPINO_CONFIG_DIR. Keep this directory to retain the ability to claim anonymous uploads. Passwords are never stored. Logging out revokes the session but preserves the anonymous identity. Browser and MCP sessions are separate: logging in on the website alone does not claim CLI uploads.

For non-interactive login, use login --email you@example.com --password-stdin, supplying the password through standard input from your secret manager. Do not pass passwords as command-line arguments. --json gives structured results and errors; errors exit with status 1. Default publishing writes only the URL to stdout and status to stderr.

Directory uploads skip .git, .env*, node_modules, .ssh, .aws, and symbolic links. Other files are included; publish the output directory you intend to share. A single explicitly selected file is uploaded as requested. Symlink inputs are rejected. CLI commands for the same server cannot run concurrently; after a forcibly terminated process, the next command identifies any stale lock to remove once no command is running.

For development before the npm release, replace npx -y plopino with node /path/to/boards/mcp/index.js in the examples above.

Related MCP server: sitebox

MCP

MCP server for Plopino — lets an AI agent publish what it just built and hand back a public link, without the user touching a browser.

agent writes index.html — or has a report / spreadsheet / markdown on disk
   ↓  publish_page / publish_path
https://plopino.com/b/xxxxxxxx/

Documents are first-class: Word (doc/docx), Excel (xls/xlsx) and Markdown render as readable pages, code and data files get syntax-highlighted previews, and images and video display inline. The recipient opens a link; they never download a file.

Tools

Tool

Use it when

publish_page

You have the content as a string — generated HTML, or a Markdown / CSV / code document. The filename decides how it renders: leave it at index.html for a page, pass report.md and it renders as a document.

publish_path

The page needs sibling files (CSS, JS, images), or you are sharing something that is already on disk — including any document, and including binary formats (docx, xlsx, pdf) that cannot be sent as a string. Point it at a directory and the structure is preserved — no need to zip first.

publish_files

Remote endpoint only. Same job as publish_path for clients that cannot hand over a local path: you send the file contents inline (a relative path plus its content, per entry).

Both take an optional update_url: pass a link returned by an earlier publish and that page's content is replaced while the link stays the same. This needs a token (see below).

Publishing is anonymous by default: no account, no configuration, no API key. The returned link is public; without a token the page is kept for a month, with a token it is permanent and can be updated in place.

Anonymous creates also return claimUrl. It is a private browser link for the publisher: open it yourself, sign in, and confirm the claim to keep that page in your account. Do not append it to the public URL or share it with page viewers. JSON output includes it as claimUrl; human output prints it on stderr for CLI publishes and inside the MCP tool result for agent publishes.

Authentication (optional)

Set PLOPINO_TOKEN to publish to your account instead of anonymously. You get private boards, updates that keep the same link, and you are not subject to the anonymous rate limit.

Create a token at plopino.com/b — the panel hands you a ready-made command with the token already in it (the server keeps an encrypted copy, so you can come back for it any time), then:

claude mcp add plopino --env PLOPINO_TOKEN=plp_xxx -- npx -y plopino

Leaving it unset is a supported configuration, not a degraded one. Most users never need a token — the anonymous flow is the product.

Install

Also listed in the official MCP registry as io.github.plopino/plopino-mcp, and on Smithery as an installable bundle.

Anything that speaks stdio MCP works — the server is a plain stdio process, so the only difference between clients is how you register it. All of the below are the clients' own documented forms (verified 2026-09). Wherever you see plp_xxx, paste a token from plopino.com/b — the panel there fills it in for you and lets you pick your client. If your client would rather not run a local process at all, skip to Remote endpoint — same tools, one URL.

Claude Code

claude mcp add plopino -e PLOPINO_TOKEN=plp_xxx -- npx -y plopino

Codex (CLI and IDE extension share ~/.codex/config.toml)

codex mcp add plopino --env PLOPINO_TOKEN=plp_xxx -- npx -y plopino

Gemini CLI

gemini mcp add -e PLOPINO_TOKEN=plp_xxx plopino npx -y plopino

WorkBuddy — ~/.workbuddy/mcp.json (%USERPROFILE%\.workbuddy\mcp.json on Windows; needs WorkBuddy 5.3+), then restart WorkBuddy:

{
  "mcpServers": {
    "plopino": {
      "command": "npx",
      "args": ["-y", "plopino"],
      "env": { "PLOPINO_TOKEN": "plp_xxx" }
    }
  }
}

Cursor — the same JSON in .cursor/mcp.json (project) or ~/.cursor/mcp.json (global). Windsurf — the same JSON in ~/.codeium/windsurf/mcp_config.json. Claude Desktop — the same JSON in claude_desktop_config.json.

VS Code — same idea in .vscode/mcp.json, but the key is servers, not mcpServers:

{
  "servers": {
    "plopino": {
      "command": "npx",
      "args": ["-y", "plopino"],
      "env": { "PLOPINO_TOKEN": "plp_xxx" }
    }
  }
}

No npm? The server also ships as a single self-contained file on the site. Two lines instead of one, but nothing to install:

curl -fsSL https://plopino.com/plopino-mcp.mjs -o "$HOME/.plopino-mcp.mjs"
claude mcp add plopino -e PLOPINO_TOKEN=plp_xxx -- node "$HOME/.plopino-mcp.mjs"

"$HOME/…" is expanded by your shell as you paste, so the absolute path is what gets registered. That matters: MCP clients spawn the server from an arbitrary working directory, so a relative path would break.

Then just ask: "publish this to Plopino", or "give me a link for that page".

Remote endpoint — nothing to install

Everything above runs on your machine. There is also a hosted Streamable HTTP endpoint serving the same tools, for clients that support remote MCP servers and would rather not run a local process at all:

https://plopino.com/mcp
claude mcp add --transport http plopino https://plopino.com/mcp

Any client that accepts a remote server URL takes that same address. Authentication works the same way: send a token as Authorization: Bearer plp_xxx if you have one, and publish anonymously if you don't.

Two differences from the stdio build, both deliberate:

  • publish_path is not available remotely. It takes a path on the machine the server runs on — which, remotely, is not your machine. Use publish_files and send the contents.

  • The endpoint is stateless: each request is handled on its own, no session to keep alive.

Self-hosted / local

The instance the server publishes to defaults to https://plopino.com. Set PLOPINO_BASE_URL to point at another one — a staging host, or your own deployment:

PLOPINO_BASE_URL=https://plopino.com npx -y plopino

Requirements

  • Node 20 or newer (required by the MCP TypeScript SDK v2).

  • The only runtime dependency is the MCP SDK.

Development

npm install
npm test        # 路径展开的边界 + 协议握手/工具列表(不需要网络)

To exercise the full publish path, run a Plopino instance and drive the server over stdio against it:

PLOPINO_BASE_URL=https://plopino.com node index.js

stdout is the MCP protocol channel. Anything written there that is not a JSON-RPC message will break the client. All logging must go to stderr — hence console.error everywhere and never console.log.

Privacy Policy

Full policy: https://plopino.com/privacy

  • What is collected. Only what publishing requires: the file contents and file names you pass to a tool, the destination URL, and — for anonymous publishes — the requesting IP address (used for the daily rate limit). The MCP server itself collects nothing and sends no telemetry; it runs locally and writes only to stderr.

  • How it is used and stored. Uploaded content is stored on Plopino's servers and served from the returned public link. A PLOPINO_TOKEN is stored locally in your MCP client configuration; the server keeps only its SHA-256 hash.

  • Third parties. No content or usage data is sold, shared or sent to third parties for advertising. Plopino uses Cloudflare as its CDN/reverse proxy and self-hosted Umami for aggregate, cookieless visit counts.

  • Retention. Anonymous uploads are deleted after 30 days; a link can also be removed earlier from the account page. Uploads made with a token are kept until you delete them or the account is closed. Request deletion or report abuse at abuse@plopino.com.

  • Contact. abuse@plopino.com (abuse and privacy requests), or https://plopino.com/abuse.

Notes

  • publish_path walks directories recursively and skips symbolic links — following them could escape the directory tree and upload files from elsewhere on the machine.

  • Anonymous uploads are rate-limited per IP by the server side.

  • Nothing is uploaded until a tool is called; the server does no network I/O at startup.

Available Tools

2 tools
publish_pagePublish a page and get a linkA

Publish content you have in hand to a public URL. Use this whenever the user asks to share, send, publish, or "give me a link to" something you just produced — an HTML page (dashboard, report, chart, interactive page), a Markdown document, CSV, JSON, or a code/data file. Everything it publishes becomes a page the recipient opens in a browser: the filename decides how it renders, so pass "report.md" for Markdown instead of renaming it to .html. Returns a public link that opens on any device; no account or configuration needed. Anonymous pages are kept for a month — with a token, storage is permanent and the page can be updated in place. Prefer this over telling the user to save the file and upload it somewhere themselves.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesThe complete content of the file, as a string. With the default filename this is a self-contained HTML document including the <html> tag — relative references to local files will not resolve, so use publish_path when the page needs sibling files (CSS, JS, images).
filenameNoWhat to name the file — this decides how the content is rendered, so get it right rather than renaming Markdown to .html. Defaults to "index.html". Use "report.md", "data.csv", "query.sql" and so on; subdirectories work too ("reports/q3.md"). Only text can be sent as a string — binary formats (docx, xlsx, pdf) must go through publish_path.
update_urlNoA URL returned by an earlier publish. When given, the content of that page is replaced and the link stays the same. Requires the server to be configured with a Plopino token.

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlYesPublic link to the published page — give this to the user.
noteYesHuman-readable status: created vs updated, and how long the page is kept.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is not read-only (readOnlyHint=false) and has open world effects (openWorldHint=true). The description adds valuable context: pages are public, no account needed, anonymous pages retained for a month, permanent storage with a token, and in-place updates via update_url. It does not contradict annotations and provides behavioral specifics beyond the safety flags.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a compact paragraph, roughly five sentences, front-loaded with the primary purpose and use cases. It efficiently packs usage triggers, behavioral notes, and filename guidance without redundancy. It is not overly terse but remains focused and scannable, earning a high but not perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the annotations cover safety, the description is largely complete. However, it does not explicitly mention the sibling tool publish_path or when to choose it (e.g., for file paths or binary content). While the schema hints at this, the description itself leaves the boundary ambiguous. This is a notable gap for a tool with a sibling, so completeness is adequate but not full.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds extra guidance beyond the schema, such as emphasizing that the filename decides rendering ('pass 'report.md' for Markdown instead of renaming it to .html') and clarifying that only text can be sent as a string, which reinforces the schema's note about binary formats. This lifts the score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'publish', the resource (content to a public URL), and explicitly enumerates the content types and user intents that trigger it (share, send, publish, give me a link). It also differentiates from the sibling publish_path by specifying 'content you have in hand' and later noting binary formats must go through publish_path, making the tool's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a strong when-to-use rule ('Use this whenever the user asks to share, send, publish...') and even advises preferring it over manual uploads. However, it does not explicitly name the sibling publish_path as the alternative for when content is a file path or binary, though the schema description covers this. The context is clear but the exclusion of alternatives is left to inference from the phrase 'content you have in hand'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

publish_pathPublish a local file or folder and get a linkA

Publish a local file, a zip, or a whole directory to a public URL, preserving the directory structure. Use this when the page needs sibling files (CSS, JS, images) — write them into a directory first, then publish that directory. It is also the way to share any document: Word (doc/docx), Excel (xls/xlsx) and Markdown render as readable pages, code and data files get syntax-highlighted previews, and images and video display inline — the recipient opens a link instead of downloading a file. (PowerPoint files publish and download fine but have no rendered preview.)

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to a file or directory on this machine. A directory is uploaded recursively with its structure preserved (symbolic links are skipped, so the upload cannot escape the directory); a zip archive is unpacked server-side.
update_urlNoA URL returned by an earlier publish. When given, the content of that page is replaced and the link stays the same. Requires the server to be configured with a Plopino token.

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlYesPublic link to the published page — give this to the user.
noteYesHuman-readable status: created vs updated, and how long the page is kept.

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate non-readonly, open-world, non-idempotent, non-destructive. The description adds meaningful behavioral specifics beyond those: it discloses that updating a URL replaces content, that symbolic links are skipped, and that zips are unpacked server-side. This enriches the agent's understanding without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two paragraphs and somewhat lengthy, but every sentence serves a purpose: it covers directory publishing, supported file types, the PowerPoint limitation, and the update_url behavior. It is front-loaded with the core purpose and structured logically, though it could be trimmed slightly without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, return values are not needed. The description covers edge cases (symlinks, zip unpacking), usage scenarios, and even the PowerPoint preview limitation. It is complete for an agent to know when and how to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description does not need to compensate. The description adds context about document types (Word, Excel, Markdown render as pages) but this is use-case guidance rather than parameter semantics; the schema already documents the path and update_url behavior thoroughly. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Publish a local file, a zip, or a whole directory to a public URL, preserving the directory structure.' It distinguishes itself from the sibling publish_page only implicitly (by describing its own scope) but does not explicitly name the alternative, so it loses a point for lack of direct differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides concrete context for when to use it: 'Use this when the page needs sibling files... write them into a directory first, then publish that directory. It is also the way to share any document...' This is clear usage guidance but does not explicitly state when not to use it or mention the sibling tool as an alternative, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.10
    • Removedpublish_html
    • Addedpublish_page
    • Changedpublish_path1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
        +  "$schema": "http://json-schema.org/draft-07/schema#",
        +  "additionalProperties": false,
        +  "properties": {
        +    "note": {
        +      "description": "Human-readable status: created vs updated, and how long the page is kept.",
        +      "type": "string"
        +    },
        +    "url": {
        +      "description": "Public link to the published page — give this to the user.",
        +      "type": "string"
        +    }
        +  },
        +  "required": [
        +    "url",
        +    "note"
        +  ],
        +  "type": "object"
        +}
  2. 2 tool updates
    • Changedpublish_html1 field changed
      • changedInput schema / properties / html / description
        Previous value: -"The complete HTML document to publish, including the <html> tag."New value: +"The complete HTML document to publish, including the <html> tag. It must be self-contained: relative references to local files will not resolve — use publish_path when the page needs sibling files (CSS, JS, images)."
    • Changedpublish_path1 field changed
      • changedInput schema / properties / path / description
        Previous value: -"Absolute path to a file or directory on this machine."New value: +"Absolute path to a file or directory on this machine. A directory is uploaded recursively with its structure preserved (symbolic links are skipped, so the upload cannot escape the directory); a zip archive is unpacked server-side."
  3. 2 tool updatesv0.1.4
    • First observedpublish_html
    • First observedpublish_path

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation4/5

The tools share a common purpose of publishing to public URLs, but their descriptions clearly distinguish between publishing content already in hand (publish_page) and publishing local paths or directories (publish_path). The use cases are well delineated, though an agent might need to carefully read the descriptions to avoid misselection when sharing a file from disk.

Naming Consistency5/5

Both tools follow the same verb_noun snake_case convention (publish_page, publish_path), making the pattern immediately predictable. The naming is perfectly consistent.

Tool Count4/5

With only two tools, the server is on the lean side, but for its narrow scope of publishing content, each tool serves a distinct and necessary role. The count feels appropriate rather than insufficient.

Completeness4/5

The two tools cover the core publishing scenarios: inline content and file/directory paths. While there is no explicit update or delete mechanism, the descriptions mention in-place updates via token, so the surface is reasonably complete for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables sharing artifacts (HTML, files, sites) with password protection and custom branding on your own domain, directly from any AI agent.
    8
    MIT
  • F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to upload, list, read, and delete static web pages via the Model Context Protocol, with REST API and optional authentication and TTL.
    -
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to publish HTML or Markdown to a public URL with a single HTTP POST, automatically converting Markdown to a styled webpage, with no account or setup required.
    2 npm
    1
    MIT