Skip to main content
Glama

Mencoro

Rank tracking by keyword cluster

get_cluster_breakdown
Read-onlyIdempotent

Rank-tracking metrics broken down per keyword cluster for a project over a date window: one row per cluster with its positions, share of voice and sentiment. Dates must fall within the data retention window. Answers questions like "which keyword clusters are strongest or weakest" or "how does my niche compare to my generic queries".

Input Schema

NameRequiredDescriptionDefault
dateToYes
enginesNoallowed values: chatgpt, claude, perplexity, google_ai_overview, google_ai_mode, google_serp, google_shopping
dateFromYes
countriesNoISO-3166 alpha-2 country codes (e.g. "US", "GB", "DE"); a project's configured codes are listed by get_available_filters
projectIdYes
organizationIdYes
queryClusterIdsNorestrict to these keyword clusters
includeUngroupedQueriesNoSent alone, returns only the ungrouped row: the tracked queries that belong to no cluster (refused if there are none). Sent with queryClusterIds, adds that row to those clusters. Omit both for every cluster plus the ungrouped row.

Output Schema

NameRequiredDescriptionDefault
rowsYes
dataDirtySinceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / rows / items / properties / checkedQueryCountByFamily
      Added value: +{
      +  "properties": {
      +    "ai": {
      +      "type": "integer"
      +    },
      +    "serp": {
      +      "type": "integer"
      +    },
      +    "shopping": {
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "ai",
      +    "serp",
      +    "shopping"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / rows / items / properties / lastCheckedAtByEngine
      Added value: +{
      +  "additionalProperties": {
      +    "anyOf": [
      +      {
      +        "type": "string"
      +      },
      +      {
      +        "type": "null"
      +      }
      +    ]
      +  },
      +  "type": "object"
      +}
    • addedOutput schema / properties / rows / items / properties / trackedQueryCountByFamily
      Added value: +{
      +  "properties": {
      +    "ai": {
      +      "type": "integer"
      +    },
      +    "serp": {
      +      "type": "integer"
      +    },
      +    "shopping": {
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "ai",
      +    "serp",
      +    "shopping"
      +  ],
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / includeUngroupedQueries / description
      Added value: +"Sent alone, returns only the ungrouped row: the tracked queries that belong to no cluster (refused if there are none). Sent with queryClusterIds, adds that row to those clusters. Omit both for every cluster plus the ungrouped row."
  3. Changed2 schema fields changed
    • changedInput schema / properties / engines / description
      Previous value: -"allowed values: chatgpt, perplexity, google_ai_overview, google_ai_mode, google_serp, google_shopping"New value: +"allowed values: chatgpt, claude, perplexity, google_ai_overview, google_ai_mode, google_serp, google_shopping"
    • changedInput schema / properties / engines / items / enum
      Previous value: -[
      -  "chatgpt",
      -  "perplexity",
      -  "google_ai_overview",
      -  "google_ai_mode",
      -  "google_serp",
      -  "google_shopping"
      -]New value: +[
      +  "chatgpt",
      +  "claude",
      +  "perplexity",
      +  "google_ai_overview",
      +  "google_ai_mode",
      +  "google_serp",
      +  "google_shopping"
      +]
  4. Changed2 schema fields changed
    • changedOutput schema / properties / rows / items / properties / mentionRate / description
      Previous value: -"Percentage 0-100 of tracked queries with a result in the period; higher is better."New value: +"Percentage 0-100 of AI checks (one per tracked query x engine x UTC day) in the period that mentioned the brand, each check counted as the share of its passes that did; higher is better."
    • changedOutput schema / properties / rows / items / properties / serpRate / description
      Previous value: -"Percentage 0-100 of tracked queries with a result in the period; higher is better."New value: +"Percentage 0-100 of traditional-search checks (one per tracked query x engine x UTC day) in the period in which the brand ranked; higher is better."
  5. Changed26 schema fields changed
    • addedOutput schema / properties / dataDirtySince / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / dataDirtySince / type
      Removed value: -[
      -  "string",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / avgLinkPosition / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / avgLinkPosition / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / avgMentionCount / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / avgMentionCount / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / avgMentionPosition / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / avgMentionPosition / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / avgSerpPosition / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / avgSerpPosition / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / clusterId / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / clusterId / type
      Removed value: -[
      -  "string",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / mentionRate / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / mentionRate / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / positivityIndex / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / positivityIndex / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / sentimentNegative / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / sentimentNegative / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / sentimentNeutral / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / sentimentNeutral / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / sentimentPositive / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / sentimentPositive / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / serpRate / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / serpRate / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / rows / items / properties / shareOfVoice / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / rows / items / properties / shareOfVoice / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
  6. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuine beyond-schema context: a data-retention constraint on dates and the shape of the result (per-cluster rows). It does not cover pagination or default engine/country scope, which keeps it from a 5.

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 core payload, grain and date constraint are front-loaded in the first two sentences, with the example questions last. It is efficient and free of filler, though the third sentence is arguably optional given how self-explanatory the tool name is.

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?

An output schema exists, so the description need not explain return values, and annotations carry the safety profile. The description still supplies the key operational constraint (retention window) and the per-cluster grain. Missing details are minor – e.g. what happens when a cluster has no data, or defaults for engines/countries.

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 description coverage is 50%, with engines, countries, queryClusterIds and includeUngroupedQueries documented in the schema itself. The description only adds meaning to the date pair via the retention-window rule; organizationId, projectId and the filter arrays get no elaboration. Baseline 3 is appropriate given the partial compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely ('rank-tracking metrics broken down per keyword cluster') and even states the output grain – one row per cluster with positions, share of voice and sentiment. That clearly separates it from get_sentiment_breakdown, get_share_of_voice_formula and get_rank_tracking_time_series. It stops short of naming a sibling alternative explicitly, so it is clear but not fully differentiating.

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?

Usage is implied through example questions ('which keyword clusters are strongest or weakest', 'how does my niche compare to my generic queries'), which helps an agent recognize the right scenario. However, there is no explicit when-not guidance and no named alternative for the adjacent time-series or single-query tools, so routing remains partly inferential.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.