Skip to main content
Glama
competlab

competlab-mcp-server

by competlab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_alerts

Read-only

Retrieve paginated competitive alerts tracking detected changes across dimensions like pricing, tech-trust, and AI visibility. Filter by severity, dimension, or competitor ID.

Instructions

Get paginated competitive alerts — detected changes across all monitored dimensions. Filter by dimension (tech-trust, content, positioning, pricing, ai-visibility, ai-sources), severity (critical, high, medium, info), and/or competitorId. Alerts include change diffs and action hints. AI Visibility alerts report who the AI models recommend, never score movement. Read alertType first: own_standing_changed is the customer's own standing, rival_standing_changed a tracked competitor's, untracked_brand_recommended a company not on the competitor list now named in at least a quarter of answers (even allowing for how few answers there are), prompt_market_changed the prompt-market reading. context.standingChange carries the reading before and after: brand.isOwn and brand.isTracked say whose it is; presence, presenceLow and presenceHigh are whole percents (0–100) of the answers analysed, and the zone is decided on that range, never on presence alone; before is null when the brand was named in no answer of that earlier window — a measured absence, not missing data; the zone token names a condition, not a verdict. Never subtract two presences, and never order two brands whose ranges overlap. context.promptMarketChange.explanation.text is the sentence to quote. An alert is written once and never revised: quote its numbers as of its createdAt, not as the current state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-indexed, default: 1)
limitNoItems per page (default: 20, max: 100)
severityNoFilter by severity level
dimensionNoFilter by dimension
projectIdYesProject ID (from list_projects)
competitorIdNoFilter by competitor ID (from list_competitors)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.0.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
  2. Changed1 schema field changedv3.0.0
    • changedInput schema / properties / dimension / enum
      Previous value: -[
-  "tech-trust",
-  "content",
-  "positioning",
-  "pricing",
-  "ai-visibility"
-]New value: +[
+  "tech-trust",
+  "content",
+  "positioning",
+  "pricing",
+  "ai-visibility",
+  "ai-sources"
+]
  3. First observedv1.0.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint, but the description adds substantial behavioral context beyond that: alerts are immutable ('written once and never revised'), numbers must be quoted as of createdAt, null 'before' is a measured absence rather than missing data, and zones are decided on a range not a point. This is exactly the kind of disclosure the safety annotations cannot carry.

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?

The tool-selection sentence is front-loaded and the filtering options follow compactly. The remaining bulk is dense output-interpretation guidance (alertType, standingChange, presence math) which, because there is no output schema, has to live here — though it reads as a run-on block rather than cleanly structured sections.

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 no output schema, the description must explain the return payload, and it does so thoroughly — alertType semantics, standingChange fields, presence ranges, and the immutability rule. Combined with read-only annotations, an agent has what it needs to call and interpret the tool correctly.

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% with enums for severity and dimension already documented, so the schema carries the parameter semantics. The description restates the same filter values and adds little syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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 ('Get paginated competitive alerts') and immediately scopes it ('detected changes across all monitored dimensions'), which cleanly separates it from the many get_*_dashboard and get_*_history siblings. An agent can tell this is the cross-dimension alert feed rather than a single-dimension dashboard.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description details how to filter (dimension, severity, competitorId) and how to interpret results, but never states when to prefer this tool over list_competitors, the per-dimension dashboards, or the briefings. Usage is implied by the resource rather than contrasted with alternatives.

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