Skip to main content
Glama
dotbrainhq

dotTide

Official

competing_pages

Read-only

Identifies queries where multiple site pages split clicks, revealing keyword cannibalization with each page’s clicks, impressions, position, and top-page click share.

Instructions

Queries where two or more pages of the site each get at least min_impressions, so they split the clicks (cannibalization). For each query: every page with its clicks, impressions and position, the page with most clicks and its share. Biggest overlaps first. Same dates and filters as search_queries.

Input Schema

NameRequiredDescriptionDefault
endNo
daysNo
siteYes
limitNo
startNo
deviceNo
countryNo
search_typeNoweb
min_impressionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint. The description adds meaningful behavioral context: it explains the per-query return shape, includes click/impression/position details, identifies the top page and its share, and states results are ordered by biggest overlap first.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose first, then output structure, ordering, and parameter reuse. Every sentence contributes useful information without repetition.

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

Completeness3/5

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

The description compensates well for the lack of an output schema by explaining returned fields and ordering. However, for a 9-parameter tool with zero schema descriptions, it is incomplete on parameter semantics, especially site and limit.

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

Parameters2/5

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

With 9 parameters and 0% schema description coverage, the description must carry the burden. It explains min_impressions and delegates date/filter parameters to search_queries, but leaves site, limit, and the exact semantics of start/end/days/device/country/search_type unclear.

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 states a specific analytical purpose: finding queries where multiple pages compete and split clicks (cannibalization). It is clear what the tool does, though it does not explicitly distinguish itself from siblings like page_queries or search_queries beyond the cannibalization framing.

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 by the cannibalization definition, and it notes that dates and filters behave like search_queries. However, it gives no explicit when-to-use guidance, no exclusions, and no clear alternative selection criteria versus search_queries or page_queries.

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