Skip to main content
Glama

Update monitor

update_monitor
DestructiveIdempotent

Pause or resume a monitor, or save its brand description. Pausing stops scans and record refreshes but keeps the monitor and its matches. Resuming restarts scanning and needs room in the plan: the active monitors plus this one, and this monitor's active assets, must fit the limits from get_account; otherwise the error names the limit the plan sets. The brand description is optional background about the brand in the user's own words, which assessments read; saving it does not reassess existing matches, and only assessments that run afterwards read it. Deleting a monitor is dashboard-only because it removes its matches too.

Input Schema

NameRequiredDescriptionDefault
statusNoNew status: paused stops monitoring, active resumes it. Omitted, the status stays as it is.
monitor_idYesMonitor id from list_monitors or create_monitor.
brand_descriptionNoBackground about the brand, at most 500 characters: what it sells, to whom and where, and the companies, sites and partners it operates with. null or an empty string clears it; omitted, it stays as it is.

Output Schema

NameRequiredDescriptionDefault
monitorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • removedInput schema / properties / brand_context
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "maxLength": 500,
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "description": "Background about the brand, at most 500 characters: what it sells, to whom and where, and the companies, sites and partners it operates with. null or an empty string clears it; omitted, it stays as it is."
      -}
    • addedInput schema / properties / brand_description
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maxLength": 500,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Background about the brand, at most 500 characters: what it sells, to whom and where, and the companies, sites and partners it operates with. null or an empty string clears it; omitted, it stays as it is."
      +}
    • removedOutput schema / properties / monitor / properties / brand_context
      Removed value: -{
      -  "description": "The user's own background about the brand (what it sells, to whom and where, the companies, sites and partners it operates with); null when not set. Assessments read it; it never limits which subjects are found.",
      -  "type": [
      -    "string",
      -    "null"
      -  ]
      -}
    • addedOutput schema / properties / monitor / properties / brand_description
      Added value: +{
      +  "description": "The user's own background about the brand (what it sells, to whom and where, the companies, sites and partners it operates with); null when not set. Assessments read it; it never limits which subjects are found.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / monitor / required
      Previous value: -[
      -  "id",
      -  "name",
      -  "status",
      -  "next_scan_at",
      -  "brand_context",
      -  "dashboard_url"
      -]New value: +[
      +  "id",
      +  "name",
      +  "status",
      +  "next_scan_at",
      +  "brand_description",
      +  "dashboard_url"
      +]
  2. Changed5 schema fields changed
    • addedInput schema / properties / brand_context
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maxLength": 500,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Background about the brand, at most 500 characters: what it sells, to whom and where, and the companies, sites and partners it operates with. null or an empty string clears it; omitted, it stays as it is."
      +}
    • changedInput schema / properties / status / description
      Previous value: -"New status: paused stops monitoring, active resumes it."New value: +"New status: paused stops monitoring, active resumes it. Omitted, the status stays as it is."
    • changedInput schema / required
      Previous value: -[
      -  "monitor_id",
      -  "status"
      -]New value: +[
      +  "monitor_id"
      +]
    • addedOutput schema / properties / monitor / properties / brand_context
      Added value: +{
      +  "description": "The user's own background about the brand (what it sells, to whom and where, the companies, sites and partners it operates with); null when not set. Assessments read it; it never limits which subjects are found.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / monitor / required
      Previous value: -[
      -  "id",
      -  "name",
      -  "status",
      -  "next_scan_at",
      -  "dashboard_url"
      -]New value: +[
      +  "id",
      +  "name",
      +  "status",
      +  "next_scan_at",
      +  "brand_context",
      +  "dashboard_url"
      +]
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only flag it as a non-read-only, idempotent, destructive-flagged write. The description adds the real behavioral surface: matches survive a pause, resume failure is a plan-limit error that names the limit, and saving a brand description does not reassess existing matches. These are consequences an agent cannot infer from the structured fields.

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?

The action summary is front-loaded in sentence one, followed by one paragraph per operation, each containing only consequence-bearing detail. No sentence restates the title or the schema.

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

Completeness5/5

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

With an output schema present, return values need no explanation, and the description covers the remaining gaps: side effects, the plan-limit failure mode, idempotent semantics of re-saving, and why deletion is absent. Nothing needed to call it correctly is missing.

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 100%, so the baseline is 3, but the description goes further by explaining what brand_description is for (background assessments read), its downstream effect (only future assessments see it), and the resume constraint tied to status. Only the UUID format/limit details are left to the schema.

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?

The first sentence gives three specific verbs on a named resource: pause, resume, save brand description. It also distinguishes this tool from deletion, which it explicitly routes to the dashboard, so an agent can tell it apart from create_monitor/list_monitors without opening a schema.

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?

It states what each operation does and what it costs: pausing keeps matches, resuming requires plan capacity computed against get_account limits, and deleting is not available here. That is explicit when-to-use guidance plus a named precondition tool and an explicit exclusion.

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