Skip to main content
Glama

update_published_template

Sends an UPDATE of one of YOUR templates that is already PUBLISHED (approved) to human review, like the edit button of the website. The update waits parked and the live version stays visible and on sale exactly as it is until a person decides: if it is approved it replaces the live version, if it is rejected the live version simply stays. Send in fixes only the fields that change (same allowed values and limits as when publishing, all in the input schema); everything you do not send is kept from the live version. The licence and the cover image (bannerUrl) cannot be changed ([FIELD_NOT_EDITABLE]). A template with an EXCLUSIVE licence that has already been sold can never be updated ([EXCLUSIVE_SOLD]): the buyer keeps exactly the listing and the file they bought, and an update that was waiting when it sold is not applied. Updating also requires being able to sell, the same as publishing ([MEMBERSHIP_REQUIRED] otherwise). For a new deliverable, upload the ZIP with zip_upload_link and pass it in file: it only replaces the live ZIP if the update is approved, and without it the current ZIP is kept. useDraft: true takes the changes from the edit draft of THIS template. If an update is already waiting it answers [EDIT_PENDING]: wait for the decision, or repeat with replacePending: true to replace it. An update that changes nothing is refused ([NO_CHANGES]). A REJECTED template is fixed with resubmit_for_review instead ([NOT_APPROVED]), and one under review or being published answers [TEMPLATE_IN_PROGRESS]. DRY RUN: with dryRun: true it checks that the template is yours and published and which fields would change, without sending anything and without spending quota. The answer says how long the review usually takes (24 to 72 hours) and how you learn the result: by email for a person, by the template.reviewed webhook or my_templates (hasPendingChanges) for an agent account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoOPTIONAL new deliverable: the ZIP you uploaded with zip_upload_link ({ blobUrl, pathname, filename, sizeBytes, uploadToken }). It waits with the update and only replaces the live ZIP if the update is approved; without it the current ZIP is kept.
slugYesSlug of YOUR published (approved) template (it comes from my_templates).
fixesNoOnly the fields that change; whatever you do not send is kept from the LIVE (published) version. The licence CANNOT be changed and neither can the cover image (bannerUrl): sending a different value is rejected with [FIELD_NOT_EDITABLE]. Same rules and same limits as when publishing. Limits and required fields are the CURRENT ones on the platform: they are read when tools/list is answered and the admin can change them (ask for tools/list again; the validation error always carries the live figure).
dryRunNoDRY RUN. true = exactly the same validation and the same answer, with `dryRun: true` inside, but NOTHING is created, no quota and no code are spent and no previous order or template is touched. It is there to test an integration without spending. It is checked that the template is yours and PUBLISHED (not retired, not under review, without another update waiting unless you replace it), where the changes come from, which fields would change and the aspect ratio of the new images, with the same codes as the real update. NOTHING is sent, the edit draft is not deleted, the family lock is not taken and neither the AI pre-filter nor the provenance of the new ZIP is run, because they have quotas of their own: those are rehearsed with check_before_submit.
useDraftNotrue takes the changes from the EDIT draft of THIS template (the one /vender leaves when you edit it; my_draft shows it with editing = this slug) and discards it once the update is sent; with `fixes` as well, those fields win over the draft. The answer says which one was used.
warrantyNoONLY agent accounts born from a wallet and ONLY with a new file: intellectual property warranty signed over the new ZIP (templateId = id of this template, hash = SHA-256 of the ZIP, signature = EIP-712 TemplateWarranty signature; bond_data with hash returns the message).
replacePendingNotrue REPLACES an update of this template that is already waiting for review (otherwise the call is refused with [EDIT_PENDING]). The waiting update is discarded entirely, its ZIP included: whatever you do not send now is taken from the LIVE version, not from it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesAlways true: a refusal travels as an error.
urlNoOnly in a real call: the public listing, which keeps showing the live version.
slugYesSlug of the template.
dryRunNoOnly in a dry run: nothing was sent.
newFileNoThe update carries a new ZIP, which only replaces the live one if the update is approved.
inReviewYestrue = the update is waiting for human review; false in a dry run.
nextStepNoOnly for an agent account: what to poll while a person decides.
resultByNoHow the result reaches you.
payoutNoteNoOnly for a delegate: where the sales of what it publishes are paid.
reviewNoteNoHow long the review takes and how you learn the result (email for people and delegates, webhook or polling for agent accounts).
pollSecondsNoHow many seconds it makes sense to wait before polling again.
draftDeletedNoThe edit draft that was used was deleted once the update was sent (false in a dry run).
instructionsNoOnly in a dry run: what was checked and what was not.
changedFieldsNoFields of the listing that the update changes compared with the live version (`video` included). In a dry run, those that differ among the ones you sent.
notRunInDryRunNoOnly in a dry run: what was NOT run, by name, so that it is not taken as tested.
correctionsFromYesWhere the changes came from.
fieldsFromDraftNoFields taken from the edit draft.
fieldsFromInputNoFields that arrived in `fixes`.
updateSubmittedNoOnly in a real call: this is an UPDATE of a published template, not a new submission nor a resubmission.
estimatedReviewHoursNoUsual review time, in hours.
liveVersionUnchangedYesAlways true: the published version is still visible and on sale exactly as it was until a person approves the update.
replacedPendingUpdateNoOnly in a real call: there was another update waiting and this one replaced it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so richly: the update waits parked, the live version stays on sale, licence and bannerUrl are immutable, an EXCLUSIVE sold licence can never be updated, MEMBERSHIP_REQUIRED applies, a pending update can be replaced, and review takes 24-72 hours with result delivery via email or webhook/my_templates.

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?

Purpose and the pending-wait behavior are front-loaded, and nearly every sentence carries operational content (error codes, review timeline, alternatives). It is dense and slightly long, but given the tool's complexity it is largely justified rather than padded.

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?

With an output schema present, the description need not explain return values, yet it still covers the result-learning paths (email, template.reviewed webhook, my_templates hasPendingChanges), the review timeline, and the full error-code taxonomy, leaving nothing an agent needs to call correctly.

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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning beyond the schema: `useDraft` fields win over `fixes`, `replacePending` discards the waiting update entirely including its ZIP, `dryRun` does not spend quota, and `file`/`warranty` interactions are clarified.

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 (sends an update) and resource (one of YOUR published/approved templates) plus the human-review flow, and explicitly routes to the right sibling (resubmit_for_review for rejected, update_draft implied). An agent can distinguish this from update_draft, submit_for_review and resubmit_for_review without opening any schema.

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?

Explicit when-to-use and when-not: a REJECTED template must use resubmit_for_review ([NOT_APPROVED]), one under review answers [TEMPLATE_IN_PROGRESS], and a new deliverable should go through zip_upload_link and be passed in `file`. It also names the dry-run rehearsal path and check_before_submit for the pre-filter.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources