Skip to main content
Glama

Update a drop's content

dropthis_update_content

Update an existing drop's content with new files while preserving its URL. Patch mode adds or updates only the files you send; replace mode swaps the entire bundle.

Instructions

Update the content of an EXISTING drop, keeping its current URL (ships a new deployment). Requires drop_id (the drop_… id from publish — id-only; call dropthis_resolve to convert a URL/slug) and exactly one content input (content, files, file, paths, or source_url). Use when the user edited, changed, regenerated, or wants to update the page and the URL should stay the same. PARTIAL BY DEFAULT (mode:"patch"): the files you send are upserted by path and every file you do NOT mention is carried forward unchanged — so to fix one page send only that page (a previously-bundled image stays), and to remove a file pass its path in delete_paths (e.g. delete_paths:["assets/old.png"]). Use mode:"replace" only to swap the ENTIRE content set in one call (the files you send become the whole drop and everything else is dropped; delete_paths is invalid in replace mode). Ships content only — it never changes settings; for title/visibility/password/expiry/metadata use dropthis_update_settings, and to create a brand-new drop use dropthis_publish. Not idempotent: a retry creates another deployment unless you pass the same idempotency_key. Oversized png/jpeg/webp images in the new content are optimized server-side by default (re-encoded smaller, paths unchanged, every transform disclosed in the response warnings[] as image_optimized/image_optimize_skipped); pass optimize:false for byte-exact storage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoLocal file OR directory path (stdio/local only).
modeNoHow to apply the files: "patch" (default) upserts the files you send and keeps every file you don't mention (use `delete_paths` to remove one); "replace" makes the files you send the drop's entire content set and drops the rest. Omit for patch.
pathNoFilename/path for inline content.
entryNoEntry file for a multi-file bundle.
filesNoA drop holds up to 200 files; each file is `content` (text you write), `source_url` (a remote asset dropthis fetches server-side — use this for images/video/pdf/fonts), or `content_base64` (small inline bytes only); never base64-inline an image into HTML. HTML/CSS/JS reference bundled assets by relative path. PATCH BY DEFAULT (mode="patch"): the files you send are upserted by path; every file you do NOT mention is kept untouched — so to fix one page send only that page, and to remove a file list its path in `delete_paths`. Use mode="replace" only to swap the ENTIRE content set in one shot (the files you send become the whole drop; everything else is dropped, and `delete_paths` is then invalid). `entry` selects the main file when it is not `index.html`.
pathsNoList of local file/directory paths to deploy as one bundle (stdio/local only).
contentNoInline HTML or text.
drop_idYesThe `drop_…` id of the drop to update (id-only — a URL or slug is rejected; call dropthis_resolve to turn a public URL/slug into its id first).
optimizeNoServer-side image optimization for oversized png/jpeg/webp files, on by default — omit to use the server default (true); every transform is disclosed in the response warnings[] (image_optimized/image_optimize_skipped). Pass false for byte-exact storage.
source_urlNoPublic http(s) URL to fetch and deploy.
if_revisionNoOptimistic lock: fail if revision differs.
content_typeNoMIME type for inline content.
delete_pathsNoPaths to remove from the drop in patch mode, e.g. ["old/stale.js","assets/dead.png"]. Patch-mode only — invalid with mode:"replace" (in replace, omitting a file already removes it).
idempotency_keyNoPrevent duplicate deploys on retry.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe drop's permanent drop_… id — persist it for every follow-up tool.
urlNoThe canonical, always-branded public URL (share with humans).
nextNoStructured follow-up hints keyed by action.
slugNoURL slug — a locator, not an id.
titleNo
rawUrlNoRaw-bytes URL for a single non-HTML file; null for HTML drops and collections.
statusNo
noindexNo
metadataNo
revisionNo
expiresAtNo
sizeBytesNoTotal published bundle size in bytes — check before iterating on a heavy page.
workspaceNoThe workspace this drop belongs to {id, slug, name, kind}.
visibilityNo
passwordProtectedNo
Behavior1/5

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

Annotation contradiction: the annotations declare destructiveHint:false, but the description explicitly says mode:'replace' makes the files you send become the whole drop and 'everything else is dropped' — clearly destructive to existing content. The description otherwise provides rich behavioral context (patch-by-default, delete_paths, idempotency, image optimization), but per scoring rules the contradiction forces a score of 1.

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 long but front-loaded with the most critical information (purpose, patch default, alternatives) and is well-structured. Some repetition exists (the files[] schema description repeats the patch/replace semantics) but the density of novel guidance justifies the length.

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 complex tool with 14 parameters, the description covers all key operational aspects: purpose, when to use, mode semantics, deletion, idempotency, image optimization, and sibling tool routing. It also addresses dependencies (drop_id resolution) and exclusions (doesn't change settings). Since an output schema exists, return-value documentation is not needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds substantial param semantics beyond the schema: exactly one of content/files/file/paths/source_url must be provided, drop_id is id-only requiring dropthis_resolve, delete_paths is patch-only and invalid in replace mode, optimize is on by default with warnings disclosure, and idempotency_key prevents duplicate deploys. These enrich parameter understanding significantly.

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?

The description opens with a specific verb+resource: 'Update the content of an EXISTING drop, keeping its current URL (ships a new deployment).' It also distinguishes from siblings by explicitly saying 'for title/visibility/password/expiry/metadata use dropthis_update_settings, and to create a brand-new drop use dropthis_publish.' This fully differentiates the tool.

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?

It gives precise usage context: 'Use when the user edited, changed, regenerated, or wants to update the page and the URL should stay the same.' It also states exclusions and alternatives, including pointing to dropthis_publish and dropthis_update_settings, and the requirement to resolve a URL/slug via dropthis_resolve first. The mode guidance (patch default vs replace) further clarifies when to use each variant.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dropthis-dev/dropthis-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server