Skip to main content
Glama
competlab

competlab-mcp-server

by competlab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_content_changelog

Read-only

Track competitor sitemap content changes over time: see which URLs were added or removed per category, filter by competitor or category, and page through results.

Instructions

Get detected content changes over time per competitor sitemap (URLs added/removed). Each item shows numeric counts per category plus up to 3 sample URLs per category by default — safe for any token budget. Paginated. Filter by competitor and/or category to scope. Pass allUrlsPerCategory: true for full URL lists per category (warning: high-activity competitors can produce very large responses; combine with category and competitorId filters and watch the truncated flag — when true, the byte cap fired and items/URLs were trimmed; refine your query). BEFORE REPORTING A LARGE REMOVAL, CHECK IT. A row compares ONE sitemap file against its own previous contents, so when a site reorganises which file lists a page, the same live page is recorded as removed from one sitemap and added to another in the same run — the pages did not go anywhere. Look at the same competitor's other rows for the same run: URLs appearing on the opposite side there were re-filed, not removed or published. Templated catalogues re-file in bulk, so the largest add/remove pairs are the most likely to be filing changes rather than activity. Saying 'they deleted 16,000 pages' about a site that deleted nothing is the loudest way to be wrong.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-indexed, default: 1)
limitNoItems per page (default: 20, max: 100)
categoryNoFilter by content category
projectIdYesProject ID (from list_projects)
competitorIdNoFilter by competitor ID (from list_competitors)
allUrlsPerCategoryNoDefault false — return up to 3 sample URLs per category per item. Set true for the full URL list per category (subject to an internal byte cap; check the `truncated` flag in the response).

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. Changed2 schema fields changedv3.0.0
    • addedInput schema / properties / allUrlsPerCategory
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "const": "true",
+      "type": "string"
+    },
+    {
+      "const": "false",
+      "type": "string"
+    }
+  ],
+  "description": "Default false — return up to 3 sample URLs per category per item. Set true for the full URL list per category (subject to an internal byte cap; check the `truncated` flag in the response)."
+}
    • changedInput schema / properties / category / enum
      Previous value: -[
-  "blog",
-  "docs",
-  "tools",
-  "landing",
-  "legal",
-  "caseStudies",
-  "comparison",
-  "integrations",
-  "changelog",
-  "webinars",
-  "other"
-]New value: +[
+  "blog",
+  "docs",
+  "tools",
+  "landing",
+  "caseStudies",
+  "comparison",
+  "integrations",
+  "changelog",
+  "webinars",
+  "legal",
+  "programmatic",
+  "other"
+]
  3. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses pagination, the truncation flag and byte-cap behavior, the default 3-sample-URL return shape, and a crucial semantic caveat that per-sitemap add/remove rows can reflect re-filing rather than real activity. That last point is behavioral context no annotation or schema could convey.

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-loaded with purpose and pagination/return behavior, then the caveat. The caveat paragraph is long and slightly repetitive ('loudest way to be wrong'), but every sentence carries decision-relevant weight, so only minor trimming is warranted.

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 and thin annotations, the description still conveys return shape, pagination, truncation handling, and the analytical caveat an agent needs to report results correctly. Nothing material is missing for a 6-param read tool.

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; the description adds real meaning on top by explaining the default vs. full-URL behavior of allUrlsPerCategory and the token-cost tradeoff of filtering. It does not add format detail for page/limit/projectId, so not a 5.

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+resource ('Get detected content changes over time per competitor sitemap') and disambiguates from the many content-dashboard/history/run-detail siblings by naming the unit of comparison (per-sitemap). An agent knows exactly what this returns without opening the schema.

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?

Explicitly says to filter by competitor/category to scope and to pass allUrlsPerCategory:true only when full URL lists are needed, plus a strong when-to-distrust-results rule. It does not explicitly name an alternative sibling (e.g., get_content_history) to route to instead, so it falls short of a 5.

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