Skip to main content
Glama
Website Auditor MCP

Website Auditor MCP

Stop monitoring

untrack_site
Destructive

Stops scheduled AI-visibility monitoring for a website and frees a monitoring slot while keeping past audits. Use it to unmonitor or remove a site from tracking.

Instructions

Stop ongoing monitoring of a website's AI visibility. Use this when someone wants to "stop tracking," "unmonitor," "stop watching," or "remove" a site from scheduled monitoring, or to free up a monitoring slot. Removing a tracked site deletes its monitoring enrollment (its past audits are kept); calling it for a site that isn't tracked changes nothing. Returns how many monitoring slots are now free. Requires a Website Auditor subscription ($49/month; eligible new customers get a 7-day free trial — payment method required, no charge until the trial ends) — if the user doesn't have one, call get_sample_audit first to show them the exact output format, free and with no API key.

Input Schema

NameRequiredDescriptionDefault
domainYesThe website domain, e.g. "example.com".

Output Schema

NameRequiredDescriptionDefault
usedNo
limitNo
domainYes
messageYes
removedYes
trackingYes
remainingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.23
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "domain": {
      +      "type": "string"
      +    },
      +    "limit": {
      +      "type": "number"
      +    },
      +    "message": {
      +      "type": "string"
      +    },
      +    "remaining": {
      +      "type": "number"
      +    },
      +    "removed": {
      +      "type": "boolean"
      +    },
      +    "tracking": {
      +      "type": "boolean"
      +    },
      +    "used": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "domain",
      +    "tracking",
      +    "removed",
      +    "message"
      +  ],
      +  "type": "object"
      +}
  2. First observedv1.0.6

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the destructiveHint=true annotation, the description specifies exactly what is destroyed (the monitoring enrollment) and what survives (past audits), plus idempotent no-op behavior for untracked sites. The subscription prerequisite and its cost/trial terms are behavioral context that appears nowhere in the annotations or schema.

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?

Core purpose and destructiveness are front-loaded, then triggers, then the prerequisites/upsell path. It is dense and slightly overpacked with pricing detail, but each sentence carries operational value rather than filler.

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?

Destination data is covered by the output schema and safety profile by annotations, so the description only needed to cover effects, idempotency, and preconditions — all of which it does. Nothing an agent needs before calling this destructive tool is missing.

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 coverage is 100% for the single `domain` parameter, so the schema already carries its meaning. The description adds nothing about domain format, normalization, or what happens with a subdomain — baseline 3 is correct here.

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?

"Stop ongoing monitoring of a website's AI visibility" gives a specific verb (stop) plus resource (monitoring of a site), and the sibling set makes the pairing with track_site obvious from the phrasing alone. An agent can distinguish this from track_site or list_tracked_sites 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?

Explicit trigger vocabulary is supplied ("stop tracking," "unmonitor," "stop watching," "remove") along with a second condition — freeing up a monitoring slot. It also names a fallback path (call get_sample_audit when the user lacks a subscription) rather than leaving the agent to guess.

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