Skip to main content
Glama
plopino

plopino

Official
by plopino
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Publish a page and get a link

publish_page

Publishes HTML, Markdown, CSV, JSON, or code content to a public URL and returns a shareable browser link; supports updating the same link with a token.

Instructions

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.

Input 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

NameRequiredDescriptionDefault
urlYesPublic link to the published page — give this to the user.
noteYesHuman-readable status: created vs updated, and how long the page is kept.
claimUrlNoPrivate browser claim link for the publisher only. Never give it to page viewers or append it to the public URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / properties / claimUrl
      Added value: +{
+  "description": "Private browser claim link for the publisher only. Never give it to page viewers or append it to the public URL.",
+  "type": "string"
+}
  2. Addedv0.1.10

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations, it discloses important behavior: public URL output, no account/configuration required, anonymous retention for a month, and token-based permanent storage with in-place updates. It does not cover limits or full public-visibility implications, but the added context is substantial.

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 front-loaded with purpose and usage guidance, and every sentence contributes useful context. It is slightly long and duplicates some filename guidance already in the schema, but it is not padded.

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

Completeness4/5

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

Given the output schema, annotations, and full parameter coverage, the description covers purpose, usage, return behavior, and retention well. The main omission is that the publish_path alternative/routing is left to the schema rather than the tool description.

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 baseline is 3. The description repeats the filename-rendering guidance already present in the schema and mentions content types, but it does not add parameter-specific detail beyond what the schema already provides.

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 specific verb and resource: publishing in-hand content to a public URL. It clearly contrasts with telling the user to upload the file manually, but it does not explicitly distinguish this tool from the sibling publish_path in the main description.

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 clear triggering conditions ('whenever the user asks to share, send, publish, or give me a link') and a preferred alternative over manual upload. It omits an explicit when-not/alternative case for publish_path, which is only mentioned in the parameter schema.

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

Deploy Server

Other Tools