Skip to main content
Glama

Change a site's settings

update_site
DestructiveIdempotent

Changes one or more settings of an existing site; anything left out stays as it is. Takes effect on every edge within about a minute, without publishing again. Settings the plan does not include are refused with the reason. Only change what the person asked for — never invent a password or a date.

Input Schema

NameRequiredDescriptionDefault
envNoKeys and settings for the site's functions: each .js file under _functions/ in what is published answers the path it is named after (_functions/api/hello.js answers /api/hello) and reads these as env.NAME. A change reaches every route within about a minute, without publishing again. Anybody who can open a public site can call its functions. Plans without functions refuse a set; a remove always works.
modeNoHow the site serves: `static` answers 404 for a missing path, `spa` falls back to index.html for a client-side router, `docs` reads documents through the viewer. Setting it stops the mode being detected on each publish.
nameNoWhat to call the site in the dashboard. An empty string clears it.
siteYesSubdomain or site id, from list_sites.
formsNoWhether the site's forms (marked data-drop2run) accept submissions.
folderNoFolder to move the site to — a path such as Clients/Acme or an id from list_folders — or `root` for the top level. Never creates a folder.
confirmNoRequired only with `expiryAction: delete`: the site's subdomain, repeated exactly as the person said it. Ask for it rather than filling it in.
commentsNoWho may comment on the site's pages: `off`; `invited` — the people invited with the comment role, on an invite-only site; or `anyone` signed in. Only on plans that include comments.
passwordNoA password visitors must type before seeing the site, as the person gave it. An empty string removes the password. On an invite-only site a password replaces invite-only and shuts out everyone on its list, so check get_site's `invitedOnly` and ask first.
upstreamNoSends the site's /api/* calls to an API of the person's own without putting a key in the page. A route is a line in the site's _redirects ending in 200, pointing at this origin — `/api/* https://api.example.com/v1/:splat 200` — published like any other file. Headers the page sends are filtered to a short list, so anything the provider always needs goes in `headers` here. Anybody who can open a public site can call these routes: suggest a key with the least access, and a password or invite-only for an internal tool. Plans without the proxy refuse it.
expiresAtNoWhen the site should come down, as an ISO 8601 instant in the future such as 2026-12-01T09:00:00Z. An empty string cancels a scheduled takedown.
invitedOnlyNoTrue: only the people on the site's list (invite_people) can open it, each signed in. It replaces a password. False: anybody with the link can open it again. Change it only when the person asked who should see the site.
expiryActionNoWhat the takedown does, read only with `expiresAt`: `pause` (the default) keeps the files and can be resumed; `delete` removes the site and frees its subdomain, and needs `confirm`.

Output Schema

NameRequiredDescriptionDefault
modeYesHow it serves its files.
nameYesWhat it is called, or null.
siteIdYesIdentifier of the site.
commentsYesWho may comment on its pages: nobody, the people invited to comment (only while it is invite-only), or anybody signed in. Null when that could not be read.
folderIdYesThe folder it is filed in, or null at the top level.
expiresAtYesWhen it is scheduled to come down, or null.
invitedOnlyYesWhether only invited people can open it, or null when that could not be read. Null does not mean public.
expiryActionYesWhat the takedown does: `pause` or `delete`, or null when none is scheduled.
formsEnabledYesWhether it accepts form submissions.
passwordProtectedYesWhether visitors must type a password.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / env
      Added value: +{
      +  "description": "Keys and settings for the site's functions: each .js file under _functions/ in what is published answers the path it is named after (_functions/api/hello.js answers /api/hello) and reads these as env.NAME. A change reaches every route within about a minute, without publishing again. Anybody who can open a public site can call its functions. Plans without functions refuse a set; a remove always works.",
      +  "properties": {
      +    "remove": {
      +      "description": "Names of variables to delete.",
      +      "items": {
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "set": {
      +      "description": "Variables to add, or to replace by name. A value is encrypted on arrival and can never be read back — only its last four characters are shown — so take it from the person, never invent one.",
      +      "items": {
      +        "properties": {
      +          "name": {
      +            "description": "Uppercase letters, digits and underscores, such as OPENAI_API_KEY.",
      +            "pattern": "^[A-Z_][A-Z0-9_]{0,63}$",
      +            "type": "string"
      +          },
      +          "value": {
      +            "minLength": 1,
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "name",
      +          "value"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / upstream
      Added value: +{
      +  "description": "Sends the site's /api/* calls to an API of the person's own without putting a key in the page. A route is a line in the site's _redirects ending in 200, pointing at this origin — `/api/* https://api.example.com/v1/:splat 200` — published like any other file. Headers the page sends are filtered to a short list, so anything the provider always needs goes in `headers` here. Anybody who can open a public site can call these routes: suggest a key with the least access, and a password or invite-only for an internal tool. Plans without the proxy refuse it.",
      +  "properties": {
      +    "headers": {
      +      "description": "Headers to attach to every call, such as `authorization: Bearer …` or a fixed `anthropic-version`. A value is encrypted on arrival and can never be read back — only its last four characters are shown — so take it from the person, never invent one. A name given again replaces that header.",
      +      "items": {
      +        "properties": {
      +          "name": {
      +            "minLength": 1,
      +            "type": "string"
      +          },
      +          "value": {
      +            "minLength": 1,
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "name",
      +          "value"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "methods": {
      +      "description": "Methods visitors may send; GET only when a new upstream leaves this out. A method that writes lets anybody who opens the site write with the key — add one only when the person asked, and say so.",
      +      "items": {
      +        "enum": [
      +          "GET",
      +          "POST",
      +          "PUT",
      +          "PATCH",
      +          "DELETE"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "origin": {
      +      "description": "`https://` and a host name, nothing after it, such as https://api.openai.com.",
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "remove": {
      +      "description": "True removes the upstream with all its keys; its routes then answer 502.",
      +      "type": "boolean"
      +    },
      +    "removeHeaders": {
      +      "description": "Header names to drop from this upstream.",
      +      "items": {
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "origin"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare destructive=true and idempotent=true, and the description goes well beyond them: it discloses propagation latency without republishing, that settings outside the plan are rejected with an explanation, and that invented credential values are prohibited. This is the kind of operational context an agent needs before touching a destructive multi-field update.

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?

Four short sentences, each with a distinct job: what it does, propagation, refusal behavior, and the safety guardrail. The patch semantic is front-loaded and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 13-parameter, destructive tool with a full output schema and exhaustive parameter descriptions, the description covers what the schema cannot: patch semantics, latency, plan gating, and a behavioral guardrail. Minor gaps remain around whether existing settings conflict (e.g. password vs invitedOnly interaction is only in the schema), but nothing critical is missing.

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

Parameters3/5

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

Schema coverage is 100% and the nested env/upstream objects are thoroughly documented inline, so the schema carries the parameter burden. The description only echoes the password/date warning already present in the schema and adds no new naming, format, or interaction detail, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Changes one or more settings of an existing site') and adds the crucial patch semantic that omitted fields are untouched. It does not explicitly contrast with siblings like change_subdomain, pause_site, or delete_site, so sibling selection still requires inference, but the scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real operating conditions: changes propagate to every edge in about a minute without republishing, and plan-excluded settings are refused with a reason. The closing instruction 'Only change what the person asked for — never invent a password or a date' plus per-parameter 'change it only when the person asked' rules establish clear usage boundaries, though no alternative tool is named.

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.