drop2run-mcp

Official

by Drop-to-run

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Change a site's settings

update_site

DestructiveIdempotent

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.

Instructions

Input Schema

TableJSON 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.
`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

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

Addedv0.2.5Oct 14, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-structured context: ~1 minute edge propagation, no republish needed, and that plan-gated settings are refused with a reason, which helps the agent anticipate failure modes.

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 tight sentences, front-loaded with the core action and patch behavior, then timing, then plan gating, then the safety guardrail. Every sentence carries information; no filler.

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?

With an output schema present, a 100%-covered 11-param schema, and strong annotations, the description only needs to add non-structured behavior — which it does (timing, plan refusals, no-republish, guardrail). Complete enough for correct invocation.

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% and the parameter descriptions are unusually rich (enum semantics, password/invite-only interaction, confirm requirements), so the schema carries the load. The description adds only the general patch contract, not per-parameter detail, which matches the baseline-3 case.

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 pins down the partial-update semantics ('anything left out stays as it is'). It does not name a sibling (e.g. pause_site, delete_site) to route against, but the scope is unambiguous.

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?

Gives useful context — propagation within ~a minute, no republishing, and a guardrail to change only what was requested. However, it never explicitly says when to prefer this over deleting, pausing, or rolling back a site, leaving alternative selection to inference from names.

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