Skip to main content
Glama

Update a site

update_site
DestructiveIdempotent

Update a site. Writable fields of a site. For PATCH, provide at least one; only the fields present are changed.

Input Schema

NameRequiredDescriptionDefault
idYesSite identifier.
nameNoUser-chosen name; null clears it.
labelsNoIDs of labels to assign.
limitsNoVisit caps; null means no limit.
pausedNoPause or resume visit delivery.
actionsNoAuto-actions performed during visits.
cookiesNoCookies to set before each visit; replaces the stored list.
devicesNoDevice targeting split, as percentages summing to 100.
browsingNoBrowsing options.
scheduleNoActive-hours scheduling.
visit_durationNoVisit duration range, in seconds.
blocked_domainsNoDomains blocked during visits.
traffic_qualityNoTraffic quality controls.
traffic_sourcesNoIDs of traffic sources to assign; an empty list assigns the default "Direct visits" source.
location_targetingNoCountry/continent targeting.
visit_distributionNoHow visits are paced — "even" spreads them across the day, "asap" delivers as fast as possible.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / properties / actions / properties / items / items / properties / cookie
      Removed value: -{
      -  "description": "Present for cookie actions.",
      -  "properties": {
      -    "domain": {
      -      "description": "Domain to set the cookie on.",
      -      "type": "string"
      -    },
      -    "name": {
      -      "description": "Cookie name.",
      -      "type": "string"
      -    },
      -    "value": {
      -      "description": "Cookie value.",
      -      "type": "string"
      -    }
      -  },
      -  "type": "object"
      -}
    • changedInput schema / properties / actions / properties / items / items / properties / type / description
      Previous value: -"What the app does — click a link, click an RSS or sitemap link, set a cookie, scroll, or refresh."New value: +"What the app does — click a link, click an RSS or sitemap link, scroll, or refresh."
    • changedInput schema / properties / actions / properties / items / items / properties / type / enum
      Previous value: -[
      -  "click",
      -  "click_rss",
      -  "click_sitemap",
      -  "cookie",
      -  "scroll",
      -  "refresh"
      -]New value: +[
      +  "click",
      +  "click_rss",
      +  "click_sitemap",
      +  "scroll",
      +  "refresh"
      +]
    • addedInput schema / properties / cookies
      Added value: +{
      +  "description": "Cookies to set before each visit; replaces the stored list.",
      +  "items": {
      +    "description": "A cookie set on the browser session before the visit begins.",
      +    "properties": {
      +      "domain": {
      +        "description": "Domain to set the cookie on (a leading dot is dropped; subdomains are covered either way); null sets it on the visited site's host.",
      +        "maxLength": 256,
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "name": {
      +        "description": "Cookie name.",
      +        "maxLength": 256,
      +        "type": "string"
      +      },
      +      "value": {
      +        "description": "Cookie value.",
      +        "maxLength": 256,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "value"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 10,
      +  "type": "array"
      +}
  2. First observed

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the mutation/safety profile is covered. The description adds the merge semantics ("only the fields present are changed"), which is genuinely useful beyond the annotations, but it omits any warning that some fields (cookies, traffic_sources) replace rather than merge.

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

Conciseness3/5

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

Three short fragments with the core action front-loaded. "Writable fields of a site" is a verbless fragment that reads like a header left over from a doc and does not clearly earn its place, and the phrase "For PATCH" is confusing without a method parameter in the schema.

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

Completeness3/5

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

For a 16-parameter mutation tool with nested objects, no output schema, and 100% schema coverage, the description is minimally adequate — the schema carries the field-level detail. It still lacks any note on the response shape or error behavior, and the leftover "PATCH" framing may confuse an agent that sees no HTTP method parameter.

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 description coverage is 100%, so the baseline is 3; the rich per-property descriptions already carry the semantics. The description contributes only the cross-parameter minimum of at least one writable field, which is a small addition over the schema.

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 ("Update a site"), which is enough to separate it from update_label, update_proxy, and update_traffic_source by resource name. However, it does nothing to distinguish itself from the closely-related update_site_template, and the second fragment ("Writable fields of a site") adds no independent purpose information.

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

Usage Guidelines2/5

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

The only guidance is the PATCH-like rule "provide at least one" field. There is no indication of when to use update_site versus create_site, restore_site, or update_site_template, nor any prerequisite or permission context. The stated rule is really a parameter constraint rather than usage guidance.

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