Skip to main content
Glama
Website Auditor MCP

Website Auditor MCP

List monitored sites

list_tracked_sites
Read-only

Show which websites are currently monitored for AI visibility, including each domain's cadence, active state, and monitoring slots used and remaining.

Instructions

List the websites currently being monitored for AI visibility on a schedule. Use this when someone asks "what am I tracking," "which sites am I monitoring," "how many monitoring slots am I using," or wants to see their tracked domains. Returns each tracked domain with its cadence and active state, plus slots used and remaining out of the account's limit (3 sites, or 5 for a subscription started before 18 October 2026). 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.

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": "list_tracked_sites"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
usedYes
limitYes
summaryYes
trackedYes
remainingYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.24
    • addedOutput schema / properties / tracked / items / properties / last_audited_at / description
      Added value: +"The date of the last scheduled run, stamped when the scheduler claims it and before the audit runs. It does not say how that run ended: it may still be going, or may have failed, been skipped or measured nothing of the business."
  2. Changed1 schema field changedv1.0.23
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "limit": {
      +      "type": "number"
      +    },
      +    "remaining": {
      +      "type": "number"
      +    },
      +    "summary": {
      +      "type": "string"
      +    },
      +    "tracked": {
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "active": {
      +            "type": "boolean"
      +          },
      +          "cadence": {
      +            "type": "string"
      +          },
      +          "created_at": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "digest_enabled": {
      +            "type": "boolean"
      +          },
      +          "domain": {
      +            "type": "string"
      +          },
      +          "last_audited_at": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "next_run_at": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          }
      +        },
      +        "required": [
      +          "domain"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "used": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "limit",
      +    "used",
      +    "remaining",
      +    "tracked",
      +    "summary"
      +  ],
      +  "type": "object"
      +}
  3. First observedv1.0.6

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds what those annotations cannot: the return fields (domain, cadence, active state), slot accounting, the 3-site limit versus the 5-site grandfathered limit, and a subscription precondition with pricing. The only miss is not mentioning pagination or ordering, which is minor for a bounded slot-limited list.

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?

Purpose and usage triggers are properly front-loaded and the routing sentence about get_sample_audit earns its place. The parenthetical subscription block, however, packs pricing, trial length, and payment-method terms into a single em-dash aside that is heavier than needed for tool selection and slows the read.

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?

All decision-critical facts are present: what is returned, the slot cap, the subscription gate, and the fallback tool. Since an output schema already exists, the sentence describing return fields is somewhat redundant, and the description stops short of noting ordering or empty-state behavior.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. No misleading parameter language is present.

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 — 'List the websites currently being monitored for AI visibility on a schedule' — which cleanly separates it from track_site, untrack_site, and get_monitoring_status. The scheduled-monitoring qualifier tells an agent exactly what population is returned.

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 explicit trigger phrasings ('what am I tracking', 'which sites am I monitoring', 'how many monitoring slots am I using') and an explicit alternative with its own condition: if the user lacks a subscription, call get_sample_audit first. That is a when-to-use plus when-to-switch instruction, not inference.

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