Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Update Browser Monitor

updateBrowserMonitor
Destructive

Adds Cloady's browser monitoring script to every HTML page a app serves, or removes it with edge: null, without code changes or redeploys. Settings apply on the next page load.

Instructions

Makes Cloady add the browser monitoring script tag before </head> of every HTML page the app's address and custom domains serve, with no code change or redeploy, or stop adding it with edge: null. The settings are kept in the app variable CLOADY_BROWSER_MONITORING and apply on the next page load; no service restarts. A page whose head already carries the script keeps its own. Answers 400 when the app has no web address, and 502 when the settings were saved but the app couldn't be reconciled, which repeating a request that sets edge retries. Needs the developer role.

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": {
      "workspaceSlug": "<workspaceSlug>",
      "appSlug": "<appSlug>"
    },
    "name": "updateBrowserMonitor"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
regionNo
appSlugYes
requestBodyNoThe JSON request body.
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true) by disclosing where settings persist (the CLOADY_BROWSER_MONITORING app variable), that changes take effect on the next page load with no restarts, that a page already carrying its own script is left alone, and the exact 400/502 failure semantics with retry guidance. Nothing here contradicts the mutation profile declared in annotations; it refines it.

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?

Front-loads the core action and the disable path in the first sentence, then layers persistence, idempotency, and error behavior. It is dense but every clause carries operational value; only the long compound opening sentence costs a little readability.

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 five-parameter nested mutation tool with no output schema, the description covers permissions, persistence, timing of effect, non-destructive edge cases, and failure/retry behavior. The remaining gap is the unexplained scope parameters (env, region) that determine where the change applies.

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 only 20%, and the description compensates mainly for `edge`, explaining that null stops injection and that the object drives tag settings. The nested fields (replay, mask, goal) are already documented in the schema, while `workspaceSlug`, `env`, and `region` receive no explanation anywhere, leaving the compensation incomplete.

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 concrete verb and resource: adds the Cloady browser monitoring script tag before `</head>` on every HTML page the app and its custom domains serve, with no code change or redeploy. The off-switch (`edge: null`) is named in the same sentence, so the agent knows the tool both enables and disables, distinct from the sibling getBrowserMonitor.

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 clear conditions: needs the developer role, requires the app to have a web address (otherwise 400), and repeating a request that sets `edge` retries a 502. It does not name a sibling alternative such as getBrowserMonitor for reading current state, so the when-not-to-use routing is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools