drop2run-mcp

Official

by Drop-to-run

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Publish files you wrote

publish_files

Destructive

Publish text files as a live website and return its URL. Create a new site or publish over an existing one using a subdomain or site id.

Instructions

Publishes one or more files written here — markdown, HTML, CSS, JSON, source code, any text — 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. To hold an address before the content exists — the person asks for the site first and the files later — publish a placeholder index.html with subdomain, then publish the real files over it with site. There is no way to create an empty site.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "files": "<files>"
    },
    "name": "publish_files"
  }
}

Input Schema

Name	Required	Description
`site`	No	Subdomain or site id to publish over. Omit to create a new site.
`files`	Yes	The files to publish.
`folder`	No	Folder to file the new site in, when the person asked for one: its path of names such as Clients/Acme, or its id from list_folders. Only for a new site — do not pass it together with `site`; moving an existing site is update_site's `folder`. It never creates a folder: a folder that does not exist is refused with the list of those that do, and nothing is published.
`subdomain`	No	Subdomain to create the new site under, when the person asked for a particular address. Only for a new site: leave it out to publish over an existing one, and do not pass it together with `site`. Ask rather than inventing one — the name is the URL somebody will be given, changing it later spends one of the few changes a site gets, and an unused site made under a guessed name has to be deleted by hand.

Output Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.6Oct 21, 2026

changedInput schema / properties / subdomain / description

Previous value: -"Subdomain to create the new site under, when the person asked for a particular address. Only for a new site: leave it out to publish over an existing one, and do not pass it together with `site`. Ask rather than inventing one — the name is the URL somebody will be given, it cannot be changed afterwards, and an unused site made under a guessed name has to be deleted by hand."New value: +"Subdomain to create the new site under, when the person asked for a particular address. Only for a new site: leave it out to publish over an existing one, and do not pass it together with `site`. Ask rather than inventing one — the name is the URL somebody will be given, changing it later spends one of the few changes a site gets, and an unused site made under a guessed name has to be deleted by hand."

Changed1 schema field changedv0.2.5Oct 14, 2026

changedInput schema / properties / folder / description

Previous value: -"Folder to file the new site in, when the person asked for one: its path of names such as Clients/Acme, or its id from list_folders. Only for a new site — do not pass it together with `site`; moving an existing site is done in the dashboard. It never creates a folder: a folder that does not exist is refused with the list of those that do, and nothing is published."New value: +"Folder to file the new site in, when the person asked for one: its path of names such as Clients/Acme, or its id from list_folders. Only for a new site — do not pass it together with `site`; moving an existing site is update_site's `folder`. It never creates a folder: a folder that does not exist is refused with the list of those that do, and nothing is published."

Changed2 schema fields changedv0.2.4Oct 6, 2026

addedInput schema / properties / folder

Added value: +{
+  "description": "Folder to file the new site in, when the person asked for one: its path of names such as Clients/Acme, or its id from list_folders. Only for a new site — do not pass it together with `site`; moving an existing site is done in the dashboard. It never creates a folder: a folder that does not exist is refused with the list of those that do, and nothing is published.",
+  "type": "string"
+}

addedInput schema / properties / subdomain

Added value: +{
+  "description": "Subdomain to create the new site under, when the person asked for a particular address. Only for a new site: leave it out to publish over an existing one, and do not pass it together with `site`. Ask rather than inventing one — the name is the URL somebody will be given, it cannot be changed afterwards, and an unused site made under a guessed name has to be deleted by hand.",
+  "type": "string"
+}

Changed1 schema field changedv0.2.1Sep 12, 2026

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"
+}

First observedv0.2.0Sep 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already flag destructive/openWorld/non-idempotent, and the description adds real behavioral context: single-page vs single-doc routing to index.html or the documents viewer, the overwrite semantics of publishing 'over' a site, and the scarcity of subdomain changes. It stops short of explicitly stating that publishing over an existing site replaces existing content, which is the crux of the destructiveHint.

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?

Front-loads the core purpose and URL return before constraints. Dense but every sentence carries a rule or exclusion; slightly long, though nothing is clearly redundant.

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?

With an output schema present, the description needn't explain return values, yet it confirms the URL return. For a 4-param destructive tool with rich schema coverage, all the decision-critical context (routing, placeholder technique, exclusivity) is present.

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%, so the baseline is 3, but the description adds meaning beyond the schema: it clarifies the subdomain/site mutual exclusivity as a workflow, warns not to invent a subdomain, and explains folder is only for new sites while moving uses update_site's folder.

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?

States a specific verb (publishes) and resource (files written here) and names exactly what content types are accepted. It explicitly differentiates from the sibling publish_dir, noting that PDFs and images must come from disk with publish_dir.

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?

Explicit routing rules: use publish_files for text written in-session, publish_dir for binary-from-disk. It also gives a concrete workflow for reserving an address (placeholder index.html with subdomain, then republish with site) and states the hard exclusion 'There is no way to create an empty site.'

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