update_siteUpdate files on an existing site in place — the URL stays the same. Only the listed files change; pass deletePaths to remove files. Small binaries go inline with encoding="base64"; bigger ones via start_revision.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| siteId | Yes | Site id from publish_site or list_sites | |
| deletePaths | No |
Changes observed during successful MCP inspections.
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / files / items / additionalPropertiesRemoved value: -falseInput schema / properties / files / items / properties / content / descriptionPrevious value: -"File content: UTF-8 text, or base64 when encoding is \"base64\""New value: +"File content: UTF-8 text, or base64 when encoding is \"base64\". Omit when passing sourceUrl."Input schema / properties / files / items / properties / sha256Added value: +{
+ "description": "Optional SHA-256 (hex) of the decoded bytes; verified before publishing, mismatches are rejected with both hashes",
+ "type": "string"
+}Input schema / properties / files / items / properties / sourceUrlAdded value: +{
+ "description": "Public http(s) URL to fetch this file from server-side (max 25 MB) — skips inline token cost for existing assets. Pass exactly one of content or sourceUrl.",
+ "type": "string"
+}Input schema / properties / files / items / requiredPrevious value: -[
- "path",
- "content"
-]New value: +[
+ "path"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry read/write and destructive hints, and the description adds valuable scoping beyond them: 'Only the listed files change', 'pass deletePaths to remove files', and 'the URL stays the same'. This clarifies what is and is not affected by the destructive operation. It doesn't add rate-limit or return-behavior context, but the core destructive contract is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences, each carrying distinct information: purpose, scope of changes, and a binary-size routing note. It is front-loaded with the most important fact and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema's richness, the description omits important call-relevant semantics: sourceUrl vs content selection, sha256 mismatch behavior, and the intended large-file alternate. The internal contradiction around start_revision vs start_upload is a serious completion failure because an agent following the description may invoke the wrong sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the sparse top-level schema: it clarifies that deletePaths removes files and that inline binaries use encoding="base64". However, with schema description coverage at 33%, it still does not explain the content-vs-sourceUrl choice or the sha256 verification role, leaving the agent to discover these semantics only in the nested schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update files on an existing site in place') and adds a useful scoping signal: 'the URL stays the same.' This distinguishes it from a publish/create action that might mint a new URL. It could name sibling tools like publish_site or update_preview explicitly, but the core purpose is clear and well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives misleading guidance for larger binaries: it says 'bigger ones via start_revision', but the input schema's own encoding property says that beyond inline limits 'use start_upload'. This directly contradicts the schema and could route the agent to the wrong sibling. It also provides no concrete guidance about when to choose update_site vs update_preview or publish_site.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.