drop2run-mcp

Official

by Drop-to-run

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Change a site's settings

update_site

DestructiveIdempotent

Change settings of an existing site while omitted fields stay unchanged. Updates go live on every edge in about a minute without republishing.

Instructions

Changes one or more settings of an existing site; anything left out stays as it is. Takes effect on every edge within about a minute, without publishing again. Settings the plan does not include are refused with the reason. Only change what the person asked for — never invent a password or a date.

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": {
      "site": "<site>"
    },
    "name": "update_site"
  }
}

Input Schema

Name	Required	Description
`mode`	No	How the site serves: `static` answers 404 for a missing path, `spa` falls back to index.html for a client-side router, `docs` reads documents through the viewer. Setting it stops the mode being detected on each publish.
`name`	No	What to call the site in the dashboard. An empty string clears it.
`site`	Yes	Subdomain or site id, from list_sites.
`forms`	No	Whether the site's forms (marked data-drop2run) accept submissions.
`folder`	No	Folder to move the site to — a path such as Clients/Acme or an id from list_folders — or `root` for the top level. Never creates a folder.
`confirm`	No	Required only with `expiryAction: delete`: the site's subdomain, repeated exactly as the person said it. Ask for it rather than filling it in.
`comments`	No	Who may comment on the site's pages: `off`; `invited` — the people invited with the comment role, on an invite-only site; or `anyone` signed in. Only on plans that include comments.
`password`	No	A password visitors must type before seeing the site, as the person gave it. An empty string removes the password. On an invite-only site a password replaces invite-only and shuts out everyone on its list, so check get_site's `invitedOnly` and ask first.
`upstream`	No	Sends the site's /api/* calls to an API of the person's own without putting a key in the page. A route is a line in the site's _redirects ending in 200, pointing at this origin — `/api/* https://api.example.com/v1/:splat 200` — published like any other file. Headers the page sends are filtered to a short list, so anything the provider always needs goes in `headers` here. Anybody who can open a public site can call these routes: suggest a key with the least access, and a password or invite-only for an internal tool. Plans without the proxy refuse it.
`expiresAt`	No	When the site should come down, as an ISO 8601 instant in the future such as 2026-12-01T09:00:00Z. An empty string cancels a scheduled takedown.
`invitedOnly`	No	True: only the people on the site's list (invite_people) can open it, each signed in. It replaces a password. False: anybody with the link can open it again. Change it only when the person asked who should see the site.
`expiryAction`	No	What the takedown does, read only with `expiresAt`: `pause` (the default) keeps the files and can be resumed; `delete` removes the site and frees its subdomain, and needs `confirm`.

Output Schema

Name	Required	Description
`mode`	Yes	How it serves its files.
`name`	Yes	What it is called, or null.
`siteId`	Yes	Identifier of the site.
`comments`	Yes	Who may comment on its pages: nobody, the people invited to comment (only while it is invite-only), or anybody signed in. Null when that could not be read.
`folderId`	Yes	The folder it is filed in, or null at the top level.
`expiresAt`	Yes	When it is scheduled to come down, or null.
`invitedOnly`	Yes	Whether only invited people can open it, or null when that could not be read. Null does not mean public.
`expiryAction`	Yes	What the takedown does: `pause` or `delete`, or null when none is scheduled.
`formsEnabled`	Yes	Whether it accepts form submissions.
`passwordProtected`	Yes	Whether visitors must type a password.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.6Oct 21, 2026

addedInput schema / properties / upstream

Added value: +{
+  "description": "Sends the site's /api/* calls to an API of the person's own without putting a key in the page. A route is a line in the site's _redirects ending in 200, pointing at this origin — `/api/* https://api.example.com/v1/:splat 200` — published like any other file. Headers the page sends are filtered to a short list, so anything the provider always needs goes in `headers` here. Anybody who can open a public site can call these routes: suggest a key with the least access, and a password or invite-only for an internal tool. Plans without the proxy refuse it.",
+  "properties": {
+    "headers": {
+      "description": "Headers to attach to every call, such as `authorization: Bearer …` or a fixed `anthropic-version`. A value is encrypted on arrival and can never be read back — only its last four characters are shown — so take it from the person, never invent one. A name given again replaces that header.",
+      "items": {
+        "properties": {
+          "name": {
+            "minLength": 1,
+            "type": "string"
+          },
+          "value": {
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "value"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "methods": {
+      "description": "Methods visitors may send; GET only when a new upstream leaves this out. A method that writes lets anybody who opens the site write with the key — add one only when the person asked, and say so.",
+      "items": {
+        "enum": [
+          "GET",
+          "POST",
+          "PUT",
+          "PATCH",
+          "DELETE"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "origin": {
+      "description": "`https://` and a host name, nothing after it, such as https://api.openai.com.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "remove": {
+      "description": "True removes the upstream with all its keys; its routes then answer 502.",
+      "type": "boolean"
+    },
+    "removeHeaders": {
+      "description": "Header names to drop from this upstream.",
+      "items": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "origin"
+  ],
+  "type": "object"
+}

Addedv0.2.5Oct 14, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Adds real value beyond the annotations: propagation timing ('takes effect on every edge within about a minute, without publishing again') and refusal behavior for plan-gated settings ('Settings the plan does not include are refused with the reason'). The annotations already flag destructive/idempotent/open-world, so the remaining gaps (auth requirements, reversibility of individual changes) are minor.

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?

Four front-loaded sentences; the merge-semantics and propagation-timing facts come first, with the guardrail last. Dense but every sentence carries a distinct fact, so nothing is padding. A slightly tighter phrasing of the last sentence would make it a 5.

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 12-parameter mutation tool with nested objects, an output schema, and full annotation coverage, the definition supplies the one thing structured fields cannot express: that this is a patch-merge, that effects propagate globally within a minute, and how plan-gated settings fail. Return values are covered by the output schema, so nothing essential is missing.

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 description coverage is 100%, so the baseline is 3, but the description contributes cross-parameter semantics the schema cannot: the omitted-fields-stay contract and the caution against fabricating password/date/expiry values. It does not restate individual field syntax, which is correct given the schema already carries it.

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?

States a specific verb and resource ('Changes one or more settings of an existing site') and immediately clarifies the partial-update contract ('anything left out stays as it is'). It is clearly distinct from delete_site, pause_site, and change_subdomain, but it never names a sibling to route the agent, so it stops short of the top band.

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

Usage Guidelines3/5

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

Offers scoping guidance ('Only change what the person asked for — never invent a password or a date'), which is useful behavioral steering, but gives no explicit when-to-use vs. when-to-use-an-alternative framing against change_subdomain, pause_site, or invite_people. Usage is implied rather than stated.

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