Skip to main content
Glama

Change site settings

update_site_settings
DestructiveIdempotent

Change site settings. Send only the fields to change: name, timezone (IANA, e.g. Europe/Berlin), currency (ISO code), kpi ("revenue", "mrr" or "goal:"), color (#RRGGBB), cookieless, weekly_report, spike_alert, the usage controls excluded_paths, excluded_hostnames, drop_pings and pageview_sample_rate (they lower the data recorded; ask the user first), the exclusion lists excluded_ips, excluded_countries and hidden_countries (each replaces the whole list; to add or remove one entry use update_exclusions), and attack_mode / attack_mode_auto (attack mode filters spam during a bot attack: new visits count only after a click, scroll or key press, fast repeat hits and referrer spam are dropped; real visitors who do not interact are left out too, so ask the user first), and count_cloud_visits (true counts visits from cloud and hosting networks such as AWS, Google Cloud and Azure as people; by default they are likely bots and left out of people, reports and usage). is_public and public_slug publish the dashboard at /share/ for anyone; they need the admin scope, so ask the user first. list_sites shows the current values.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_site_settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
kpiNo
nameNo
siteNoSite domain (example.com), id or public id (tb_…). Optional with a site key, or when the account has one site.
colorNo
currencyNo
timezoneNo
is_publicNo
cookielessNo
drop_pingsNotrue = do not record ping events (time on the last page). Visit durations get shorter.
attack_modeNotrue = attack mode on: stricter rules against a bot attack (see /docs/privacy#attack-mode). list_sites shows attack_mode_since.
public_slugNo
spike_alertNo
excluded_ipsNoReplaces the list. IP addresses and ranges not to record: 203.0.113.7, 203.0.113.0/24, 2001:db8::/48.
weekly_reportNo
excluded_pathsNoReplaces the list. Paths not to record, like /admin/** (* = one segment, ** = any depth).
attack_mode_autoNotrue = turn attack mode on when a traffic spike starts, and off after 24 hours of normal traffic. The owner gets an email each time.
hidden_countriesNoReplaces the list. Countries whose past data every report leaves out (nothing is deleted); each is excluded too. Ask the user first.
count_cloud_visitsNotrue = count browser visits from cloud and hosting networks (AWS, Google Cloud, Azure, Oracle, DigitalOcean, Linode, Hetzner, OVHcloud, GitHub Actions) as people. Default false: they are likely bots, so people, reports, conversion rates and usage leave them out, and the bot card shows them under Cloud networks. Turn it on only when real visitors use cloud desktops or VPNs in data centres. Applies to new visits.
excluded_countriesNoReplaces the list. ISO codes or English names whose new visits are not recorded.
excluded_hostnamesNoReplaces the list. Hosts not to record, like staging.example.com.
pageview_sample_rateNoPercent of visitors whose page views are kept: 100, 50, 25, 10. 100 = off (default). Only for very high traffic; see get_usage.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say destructive/idempotent; the description adds the real consequences: exclusion lists replace the whole list, usage controls lower recorded data, attack mode also drops non-interacting real visitors, count_cloud_visits changes people/reports/usage for new visits only, and publishing needs the admin scope. This is exactly the context a caller needs for a destructive mutation that annotations alone cannot convey.

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?

Everything stated is useful and the update contract is front-loaded, but it is delivered as a single run-on sentence with deeply nested parentheticals, which makes scanning hard. Some of the attack-mode and cloud-visit prose duplicates the schema descriptions verbatim rather than earning its place twice.

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?

For a 21-parameter destructive mutation with no output schema, the description covers partial-update semantics, destructive side effects, prerequisites, and alternatives. Minor gaps: it never says what the response looks like or how invalid values are handled, and cookieless/weekly_report/spike_alert are named but not explained.

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

Parameters5/5

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

At 52% schema description coverage, the description does the compensating work: IANA timezone example, ISO currency, the kpi enum values spelled out inline, #RRGGBB, and behavioral meaning for attack_mode, attack_mode_auto, count_cloud_visits, pageview_sample_rate and the three exclusion lists. The remaining parameters (booleans, name) are self-explanatory.

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 and resource ('Change site settings') and then enumerates exactly which settings are updatable, so the agent knows the tool's surface without opening the schema. It also names the sibling it is not (update_exclusions) and the sibling that reads current values (list_sites).

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?

Gives an explicit partial-update contract ('Send only the fields to change'), routes list-entry editing to update_exclusions, points to list_sites for current values, and repeats 'ask the user first' for the risky fields. That is when-to-use, when-not-to-use, and alternatives all in one place.

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