Skip to main content
Glama

Ranking changes between periods

get_ranking_changes
Read-onlyIdempotent

Classifies each query (or page) of the property by what happened between the comparison period and the current one: new (appeared), lost (disappeared), improved (position better by >= minPositionChange), declined (worse) or stable. Rows carry clicks/impressions/ctr/position for both periods, positionChange (negative = improved) and clicksChange; summary counts every status plus clicks gained from new and lost keys. Sorted by impressions then by size of the move. Use for "what did we gain or lose in rankings", "which queries fell off", "new queries this month". / Queries ou páginas novas, perdidas, que subiram ou caíram entre dois períodos.

Input Schema

NameRequiredDescriptionDefault
daysNoWindow length in days (default 28). Ignored when startDate and endDate are both given. / Janela em dias.
siteYesProperty: displayName ("example.com"), Search Console siteUrl ("sc-domain:example.com", "https://www.example.com/") or numeric id. A unique substring among visible properties also works ("exam"). list_sites shows the options. / Propriedade por nome, siteUrl ou id.
brandNoall (default); branded = only queries containing one of the property's branded_terms; non-branded = the rest. Needs branded terms set on the property in the Organiq panel, otherwise invalid_argument with the panel URL. / Marca × sem marca.
limitNoRows (default 50).
queryNoOnly queries containing this text, or a regex as /…/ (e.g. "/^how to/"; no flag = case-insensitive).
deviceNoDevice.
statusNoOnly this status (default all = every status except stable).
compareNoComparison: previous (default) = same-length window immediately before; year = same dates one year earlier; none. / Comparação.
countryNoCountry as ISO-3166-1 alpha-3, as in Search Console: bra, usa, prt, arg.
endDateNoEnd yyyy-mm-dd. Default: last synced date of the property (Search Console lags ~3 days; never "today"). Every response states the period used. / Fim; padrão = última data sincronizada.
dimensionNoquery (default) or page.
startDateNoStart yyyy-mm-dd. Default: endDate − (days − 1).
searchTypeNoSearch type (default web).
pageContainsNoOnly pages whose URL contains this text (case-insensitive), e.g. "/blog/".
minImpressionsNoIgnore keys with fewer impressions than this in both periods (default 10).
minPositionChangeNoPositions a key must move to count as improved/declined (default 1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description still adds substantial behavior: row payload fields, summary aggregation, default sort order (impressions then move size), the minImpressions filter, and the sign convention (negative positionChange = improved).

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?

Purpose and status definitions are front-loaded and every clause carries information, but the fully duplicated Portuguese translation roughly doubles length without adding new meaning for most readers.

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?

For a 16-parameter analytical tool with no output schema, the description still conveys the shape of the return (per-row metrics for both periods, changes, summary counts) and the sorting, which is everything an agent needs to call it correctly.

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 3 is the baseline, but the description adds real semantics: minPositionChange defines the improved/declined threshold and status=all excludes stable by default. It doesn't elaborate on the date-window interaction (days vs startDate/endDate) beyond what the schema already says.

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: classifies each query (or page) of a property into new/lost/improved/declined/stable between two periods. The status taxonomy makes it clearly distinct from siblings like get_query_performance or detect_change_points.

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?

Provides concrete triggering questions ("what did we gain or lose in rankings", "which queries fell off", "new queries this month"), which is strong context for selection. It stops short of naming alternatives or stating when not to use it (e.g. versus detect_change_points or get_query_performance).

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.