drop2run-mcp

Official

by Drop-to-run

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Read a site's settings

get_site

Read-only

Reads one site's settings and state — serving mode, password, forms, scheduled takedown, folder, whether it is paused — and its versions, newest first, with the one being served marked.

Instructions

Reads one site's settings and state — serving mode, password, forms, scheduled takedown, folder, whether it is paused — and its versions, newest first, with the one being served marked. Also says which settings the account's plan does not include.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`site`	Yes	Subdomain or site id, from list_sites.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Its live URL.
`mode`	Yes	How it serves its files.
`name`	Yes	What it is called, or null.
`siteId`	Yes	Identifier of the site.
`status`	Yes	`active`, `paused`, or a state the platform put it in.
`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.
`versions`	Yes	Its versions, newest first.
`available`	Yes	Which settings the account's plan includes.
`expiresAt`	Yes	When it is scheduled to come down, or null.
`subdomain`	Yes	Its subdomain.
`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

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description adds what is included (versions newest first, the served version marked, plan gaps), but much of this is return-value content that the existing output schema already conveys.

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?

A single sentence that front-loads the core action and then lists inclusions; dense but no wasted clauses. Slightly heavy for one sentence, hence not a 5.

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, the description needn't explain return values, and annotations cover the safety profile. It is complete enough for a single-parameter read tool, lacking only explicit sibling routing guidance.

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 coverage is 100% and the schema itself documents the single 'site' parameter as a subdomain or site id sourced from list_sites. The description adds no additional meaning, format, or constraint beyond that, so the baseline 3 applies.

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 and resource ('Reads one site's settings and state') and enumerates the payload fields it returns (serving mode, password, forms, scheduled takedown, folder, paused, versions), which clearly distinguishes it from list_sites, update_site, and delete_site.

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?

Usage is implied by the singular 'one site's settings' scope and the schema's 'from list_sites' reference, so an agent can infer it is the per-site detail read. However, it never explicitly says when to use this versus list_sites or the update/pause/resume siblings.

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