Skip to main content
Glama
plopino

plopino

Official
by plopino
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

plopino

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_html / 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_html

You have the page as a string. The most direct path for generated HTML.

publish_path

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

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.

Related MCP server: sitebox

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

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.

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".

Self-hosted / local

Set PLOPINO_BASE_URL to point at another instance:

PLOPINO_BASE_URL=http://127.0.0.1:8787 npx -y plopino

Requirements

  • Node 18 or newer (uses the built-in fetch, FormData and Blob).

  • The only runtime dependency is the MCP SDK.

Development

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

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

PLOPINO_BASE_URL=http://127.0.0.1:8787 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.

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_htmlPublish an HTML page and get a linkA

Publish an HTML page to a public URL. Use this whenever the user asks to share, send, publish, or "give me a link to" a page — for example a dashboard, report, chart, or interactive page you just generated. 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
htmlYesThe 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).
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.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behaviors: pages are public, kept for a month anonymously, permanent with a token, and can be updated in place. This adds meaningful context about retention, access, and update semantics that the annotations do not convey.

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

Conciseness5/5

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

The description is front-loaded with the core action and usage trigger, then provides behavioral details and a clear alternative. It is moderately long but every sentence carries useful information without redundancy or filler.

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?

For a two-parameter tool with no output schema, the description is complete: it states what it returns (a public link), when to use it, behavior details, and how to handle the main limitation (relative references). The lack of an output schema is not a gap because the return value is clearly described.

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 description coverage is 100%, so the schema already documents both parameters. The description adds value by emphasizing self-containment and the publish_path alternative, but it largely restates schema content rather than providing new parameter-level meaning.

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 tool publishes an HTML page to a public URL, with a specific verb and resource. It also distinguishes itself from the sibling publish_path by explicitly noting when publish_path should be used for pages needing sibling files.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use conditions ('whenever the user asks to share, send, publish, or give me a link'), and an explicit alternative ('use publish_path when the page needs sibling files'). It also discourages an inferior approach, telling the user to upload files manually, which fully guides tool selection.

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.

TDQS

A4.4/5.0
Behavior5/5

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

The description discloses rich behavioral details beyond annotations: uploads to a public URL, recursive upload with symlink skipping, server-side zip unpacking, update behavior preserving links, token requirement for updates, and rendering behavior for different file types including the PowerPoint limitation. This fully compensates for the lack of safety 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 dense but earns its length: front-loaded with the core publish action, then use-case guidance, then rendering behaviors and limitations. Each clause adds useful information, though it could be slightly tightened by explicitly routing to publish_html for single-file HTML cases.

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 open-world nature, two parameters, and no output schema, the description covers what an agent needs: what to publish, when to use it, key file-type behaviors, update semantics, and limitations. Nothing essential for correct invocation or selection is missing.

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 description coverage is 100%, so the input schema already documents path and update_url well. The description adds no new parameter-level semantics beyond what the schema provides, including the zip unpacking and link replacement behavior. Baseline 3 is appropriate.

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 states a specific verb ('publish') with a clear resource scope: local file, zip, or directory, and explicitly notes directory structure preservation. It differentiates from the sibling publish_html by emphasizing when sibling files are needed and by positioning itself as the general sharing path for many document types.

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?

The description gives explicit guidance on when to use this tool, such as when a page needs CSS/JS/images or when sharing documents that should render readably. It does not explicitly name the sibling tool publish_html or state a when-not-to-use condition, but the context is clear enough for an agent to select it appropriately.

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. 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."
  2. 2 tool updatesv0.1.4
    • First observedpublish_html
    • First observedpublish_path
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation3/5

The two tools have distinct intended use cases—single HTML pages versus files/directories with assets—but a simple standalone HTML file could reasonably be published with either, creating mild ambiguity. The descriptions help, but the boundary is not fully crisp.

Naming Consistency5/5

Both tools follow a clear, consistent verb_noun snake_case pattern: publish_html and publish_path. This makes the naming predictable and easy to extend.

Tool Count3/5

Two tools is on the thin side for a publishing service, but the pair covers the two main modes (single page vs. full path). It feels minimal but not unreasonable.

Completeness3/5

The tools cover publishing HTML and arbitrary paths, but there is no obvious way to manage, update, or unpublish previously published pages despite mentions of tokens and permanent storage. Basic publishing is covered, but lifecycle operations are missing.

Maintenance

ActivityNo data
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • hushdrop

    maxtechera
    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

  • sitebox

    zarguell
    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.
    -

  • shippage-mcp

    jieshu666
    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.
    5 npm
    1
    MIT