Skip to main content
Glama

Update AI visibility settings

update_visibility_settings
DestructiveIdempotent

Saves the AI Visibility settings of a site, the same as the settings on the AI Visibility page: the AI platforms to check and the UTC run days. Send every value the settings must have; the save replaces them. Both must fit the limits of the plan (the overview section of get_visibility), else the call gives tier_limit_exceeded. The save also makes sure the site has its check schedule. It starts no check.

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": {
      "projectId": "<projectId>",
      "enabledPlatforms": "<enabledPlatforms>",
      "runDays": "<runDays>"
    },
    "name": "update_visibility_settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
runDaysYesUTC days of the scheduled checks, each once, such as ["mon", "thu"].
projectIdYesSite to act on, from list_sites.
enabledPlatformsYesAI platforms to check, each once.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description spells out that existing values are overwritten, that the call may fail with tier_limit_exceeded, that it ensures the site has a check schedule as a side effect, and that it does not start a check. This is exactly the mutation-side-effect detail an agent needs and that annotations 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.

Conciseness4/5

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

The definition is front-loaded with the one-line purpose, then effects, constraints, and error mode in short declarative sentences. A few phrasings ("the save replaces them", "the call gives tier_limit_exceeded") are slightly clipped, but nothing is redundant.

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 three-parameter destructive settings write with no output schema, it covers replace semantics, plan-limit validation, the schedule side effect, and the fact that no check is started. It does not describe what the response contains on success, a minor omission given there is no output schema.

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 already 100%, so the baseline is 3, but the description adds real meaning: acceptable values are bounded by the plan's limits (not merely the schema's maxItems), and all values must be supplied each time rather than merged. That plan-dependent constraint is not expressible in the schema and materially affects how the agent fills the arrays.

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?

The opening clause names a specific verb and resource ("Saves the AI Visibility settings of a site") and enumerates the exact fields affected (platforms to check, UTC run days). This clearly separates it from generic settings siblings like update_project_settings, though it does not name those siblings directly.

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?

It gives a concrete operational rule — "Send every value the settings must have; the save replaces them" — which tells the agent this is a full-replace, not a patch. It also redirects to get_visibility for plan limits and implicitly steers away from expecting a run via "It starts no check." There is no explicit named alternative for triggering checks, but the exclusion is stated.

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