Skip to main content
Glama

Change a site Pugi built

edit
DestructiveIdempotent

Use this when the person asks to change a Pugi website or app from this conversation: "change the headline", "make the buttons green", "add a menu page". Pass the change in the customer's own words; do not add features the customer did not ask for (no invented sign-up, accounts, subscriptions or payments). Pass the job_id or project_id from the last build result. Do not use to start a new site or app. In hosts that render the build card (MCP Apps or ChatGPT widget), the card tracks progress automatically: do not poll job_status. In hosts without a build card (Claude Code or API), call job_status with the job_id until the job is finished, stopped or failed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "instruction": "<instruction>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
pickNoConsole gallery starter slug.
themeNoConsole theme slug.
job_idNoThe job_id of the build (or of an earlier edit) of the site to change.
localeNoSite language (legacy alias for site_language).
logo_idNoSelected logo_id returned by make_logo.
max_usdNoThe run ceiling in USD; plan edits are included in the subscription. For credit edits, the most this change may cost. Default 2.
languageNoThe language the person is writing in, as a BCP 47 tag such as "ru".
project_idNoOr the project_id of that site.
instructionYesThe change to make, in plain words.
without_logoNoTrue only when the person said this site should not use the logo they picked.
brief_versionNoWith brief_confirmed: the version of the summary the person agreed to, as returned with that summary.
site_languageNoLanguage for the website content; independent of the chat card language.
brandHandoffIdNoBrandHandoff from logo.pugi.io.
brief_confirmedNoTrue only after the person has seen the summary and agreed. In a chat, without it nothing starts and the summary comes back.
idempotency_keyYesA unique string naming this job. The same key returns the same job and is never charged twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / brief_confirmed / description
      Previous value: -"With logo_id: true only after the person has seen the summary from select_logo and agreed. Without it nothing starts and the summary comes back."New value: +"True only after the person has seen the summary and agreed. In a chat, without it nothing starts and the summary comes back."
    • changedInput schema / properties / brief_version / description
      Previous value: -"With brief_confirmed: the version of the summary the person agreed to, from select_logo."New value: +"With brief_confirmed: the version of the summary the person agreed to, as returned with that summary."
  2. Changed4 schema fields changed
    • addedInput schema / properties / brief_confirmed
      Added value: +{
      +  "description": "With logo_id: true only after the person has seen the summary from select_logo and agreed. Without it nothing starts and the summary comes back.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / brief_version
      Added value: +{
      +  "description": "With brief_confirmed: the version of the summary the person agreed to, from select_logo.",
      +  "maxLength": 32,
      +  "type": "string"
      +}
    • addedInput schema / properties / language
      Added value: +{
      +  "description": "The language the person is writing in, as a BCP 47 tag such as \"ru\".",
      +  "maxLength": 35,
      +  "pattern": "^[a-z]{2,3}(-[A-Za-z0-9]{2,8})?$",
      +  "type": "string"
      +}
    • addedInput schema / properties / without_logo
      Added value: +{
      +  "description": "True only when the person said this site should not use the logo they picked.",
      +  "type": "boolean"
      +}
  3. Changed3 schema fields changed
    • changedInput schema / properties / locale / description
      Previous value: -"Site language."New value: +"Site language (legacy alias for site_language)."
    • changedInput schema / properties / max_usd / description
      Previous value: -"The most this change may cost, in USD. Default 2."New value: +"The run ceiling in USD; plan edits are included in the subscription. For credit edits, the most this change may cost. Default 2."
    • addedInput schema / properties / site_language
      Added value: +{
      +  "description": "Language for the website content; independent of the chat card language.",
      +  "type": "string"
      +}
  4. Changed5 schema fields changed
    • addedInput schema / properties / brandHandoffId
      Added value: +{
      +  "description": "BrandHandoff from logo.pugi.io.",
      +  "type": "string"
      +}
    • addedInput schema / properties / locale
      Added value: +{
      +  "description": "Site language.",
      +  "type": "string"
      +}
    • addedInput schema / properties / logo_id
      Added value: +{
      +  "description": "Selected logo_id returned by make_logo.",
      +  "type": "string"
      +}
    • addedInput schema / properties / pick
      Added value: +{
      +  "description": "Console gallery starter slug.",
      +  "type": "string"
      +}
    • addedInput schema / properties / theme
      Added value: +{
      +  "description": "Console theme slug.",
      +  "type": "string"
      +}
  5. Added
  6. Removed
  7. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare this as a non-read-only, destructive, idempotent, open-world operation. The description adds useful behavioral context beyond annotations: no scope creep, progress tracking differs by host, and polling behavior. It doesn't explicitly restate destructiveness or billing nuances, but those are covered by annotations and schema.

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 front-loaded with the primary use case and examples, and every sentence carries operational value. It is slightly dense in the final host-specific polling paragraph, but that information is necessary and not redundant.

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 15-parameter mutation tool with no output schema, the description covers the essential workflow: when to invoke, what instruction text to pass, which identifier to supply, what not to add, and how to follow job progress in different hosts. The schema supplies detailed parameter meanings, and the description completes the operational picture.

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. The description goes beyond the schema by clarifying that the instruction should be in the customer's own words and that job_id or project_id should come from the last build result, which is meaningful routing guidance for two of the most important parameters.

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 states a specific verb and resource ('change a Pugi website or app') and gives concrete trigger examples ('change the headline', 'make the buttons green'). It explicitly distinguishes itself from build_site/build_app by saying 'Do not use to start a new site or app.'

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 explains exactly when to use the tool, provides example customer phrases, states what not to do (no invented features), and names the key identifier to pass (job_id or project_id). It also gives host-specific follow-up guidance: use the build card or poll job_status when no card is available.

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