Skip to main content
Glama

Just Publish

by ai.justpublish

update_site_file

Change one or a few files of an already-published site, leaving every other file untouched (a merge — unlike deploy, which replaces the whole site). Ideal for small edits: fix a typo in index.html, swap a stylesheet, add one page. Best practice: call get_site_files first, edit the returned content, then call this with the files you changed and the expected_version from that read — if the site changed in the meantime you get a clear conflict telling you to re-read. Requires site_id + edit_token. Cannot delete files (use deploy to drop a file) and cannot remove index.html.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesThe files to change. Only these are written; all other files on the site survive.
site_idYesThe site id returned at publish time.
edit_tokenYesThe edit token returned at publish time.
expected_versionNoOptional but recommended. The `version` you got from get_site_files. If the site has changed since, the update is rejected with a conflict so you can re-read and re-apply. Omit to force last-writer-wins.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe live URL of the site.
site_idYesThe site's slug / id.
versionYesThe site's new version after the merge.
files_totalYesTotal number of files on the site after the merge.
files_writtenYesPaths of the files written in this update. All other files were left untouched.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, but the description adds critical behavioral details: merge semantics (not a replace), conflict detection via expected_version, the requirement for edit_token, and explicit limitations (cannot delete files, cannot remove index.html). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core action, and each sentence adds unique value (usage, best practice, limitations). No fluff or repetition.

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?

Given the tool's moderate complexity, the description covers all essential aspects: purpose, best practice, prerequisites, limitations, and conflict handling. An output schema exists, so return values need not be described. The description is fully self-contained.

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?

With 100% schema description coverage, the baseline is 3. The description adds value beyond the schema by explaining the purpose of expected_version (conflict protection) and reinforcing the merge behavior of files. This elevates it to a 4.

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 clearly states it changes one or a few files of a published site without touching others, contrasting with deploy which replaces the whole site. The verb 'change' and specific resource 'files of an already-published site' are precise, and the distinction from sibling tools is explicit.

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?

The description explicitly advises when to use (small edits) and when not (cannot delete files). It provides best practice: call get_site_files first and use expected_version for conflict detection. Alternatives are named (deploy for deletion, get_site_files for reading).

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

All Just Publish toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a distinct purpose: deploy for full replacement/publishing, get_site_files for reading current state, and update_site_file for partial edits. No overlap or confusion between them.

Naming Consistency4/5

Two tools follow verb_noun pattern (get_site_files, update_site_file), while deploy is a single verb. This is a minor inconsistency, but the naming is clear and readable overall.

Tool Count4/5

Three tools is slightly small but appropriate for the specific domain of static site deployment. Each tool serves a necessary function, and the number doesn't feel inadequate.

Completeness3/5

Core operations (create/replace, read, and partial update) are covered, but there is no way to delete individual files or list multiple sites. This leaves a notable gap in the tool surface.

Resources