Skip to main content
Glama
dhawalshah

gsc-mcp

Get Keyword Cannibalization

get_keyword_cannibalization

Identify queries where multiple pages compete for the same keyword in Google Search Console, then resolve cannibalization to improve rankings.

Instructions

Identify queries where multiple pages are competing for the same keyword.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_dateYes
site_urlYesProperty URL
start_dateYes
search_typeNoSearch type filterweb
min_impressionsNoMinimum impressions per row to consider (default: 50)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full behavioral burden, but it only states purpose. It does not disclose that rows are filtered by min_impressions, how results are grouped (query/page pairs), or that a valid date range is required; the competition-detection logic is only implied.

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?

A single active sentence with the verb front-loaded and zero filler or redundancy. It is efficient, though its brevity means it contributes little beyond the purpose statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema lightens the return-value burden, but with zero annotations and 40% of parameters undocumented, an agent must guess at date formats, the notion of a 'row', and the impact of the min_impressions default. It works as a label, not as a complete usage spec.

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 60%: site_url, search_type, and min_impressions carry basic descriptions, but start_date and end_date are typed only as 'string' with no format hint. The description adds slight context by framing the keyword-competition domain, which makes min_impressions meaningful, but it does nothing for the undocumented date parameters.

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 supplies a specific verb ('Identify') and resource ('queries where multiple pages are competing for the same keyword'), translating the jargon title into an operational concept. It is semantically distinct from analytics siblings like get_search_analytics and get_position_band_report, though it never names a sibling explicitly.

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

Usage Guidelines2/5

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

There is no guidance on when to reach for this tool versus the many sibling analytics tools (get_search_analytics, get_performance_overview, compare_periods), and no mention of prerequisites such as the site already being added. No exclusions or alternative conditions are provided, so the agent must infer selection criteria from the name alone.

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