Skip to main content
Glama
Unilytics MCP Server

Unilytics MCP Server

Official

watch_competitor

Monitor a competitor’s website on a schedule for meaningful changes, such as pricing, product, messaging, funding, or acquisition updates, while filtering out cosmetic HTML edits.

Instructions

Start monitoring a competitor's website for material changes.

Detects meaningful changes — pricing/plan updates, new product or feature
launches, positioning and messaging shifts, funding or acquisition news —
rather than raw HTML diffs, so it does not fire on cosmetic edits.

Runs on a schedule. Changes are read back with get_competitor_changes(). The monitor
belongs to the user who creates it: only that user can list, read, run or stop it.
Billing: this call covers the first run; every later scheduled run is charged to the
user's credits (5 credits per lite run, 10 per base run), and a monitor stops when
the balance can't cover its runs. A user can have at most 10 active monitors, and
the same settings twice return the existing monitor_id instead of a second monitor.

Args:
    domain: Competitor domain, e.g. "semrush.com".
    frequency: Check interval as '<number><unit>', unit h/d/w. Default "1d".
               Use "1w" to keep costs low, "12h" for fast-moving competitors.
    focus: Optional list of specific things to watch, e.g. ["pricing changes"].
           Omit to watch the default commercial change set.
    processor: "lite" (cheap, fast) or "base" (more thorough, ~2x cost).
    project_id: Optional Unilytics project to label the monitor with (from list_projects;
                needs owner, admin or editor access to that project).

[Provider: Parallel AI]

Input Schema

NameRequiredDescriptionDefault
focusNo
domainYes
frequencyNo1d
processorNolite
project_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the credit cost per run by processor tier (5 lite / 10 base), that the first run is covered by this call, that a monitor stops when credits run out, ownership restrictions on list/read/run/stop, and a 10-monitor cap. It also states the dedupe behavior (same settings return the existing monitor_id), which is useful behavioral context even if slightly at odds with the idempotentHint=false flag, since the net effect described is non-duplication.

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 trigger condition, then scheduling/read-back, then billing/limits, then a clean Args block — every section is scannable and earns its place. The 'meaningful changes' paragraph is slightly expansive but the examples of what does and does not fire are load-bearing for choosing this tool.

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?

There is no output schema, and the description compensates by naming the sibling that returns results and characterizing what those changes will be. Combined with cost, quota, ownership and dedupe behavior, an agent has everything needed to decide to call it and to fill in all five parameters correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does so: it gives a domain example, the '<number><unit>' frequency format with h/d/w units plus cost-motivated recommendations ('1w', '12h'), focus examples and the omit-default behavior, the allowed processor values with a ~2x cost tradeoff, and project_id's source (list_projects) and required role.

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?

Opens with a specific verb + resource ("Start monitoring a competitor's website for material changes") and immediately scopes what counts as a change (pricing, launches, messaging, funding) versus cosmetic HTML diffs. This distinguishes it cleanly from siblings like check_competitor_now (one-off run) and get_competitor_changes (read-back), which are named or implied.

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 explicitly states this creates a scheduled monitor and that results are retrieved via get_competitor_changes(), and it sets prerequisites (ownership, 10-monitor cap, project role requirement). What is missing is an explicit contrast with check_competitor_now for a one-off scan, so the agent must infer that distinction from names alone.

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