Skip to main content
Glama

Organiq GEO

by com.organiqgeo
OverviewDiscussionsAdmin

One page over time

get_page_performance
Read-onlyIdempotent

Daily performance of ONE page (URL) of the property. Returns totals for the period and the comparison with change, the daily (or weekly) series and the top counterparts (queries bringing the page traffic). Exact match (case-insensitive for queries); when nothing matches, the error lists up to 5 candidates containing the text. / Série de uma página exata.

Input Schema

NameRequiredDescriptionDefault
daysNoWindow length in days (default 28). Ignored when startDate and endDate are both given. / Janela em dias.
pageYesThe exact page URL as stored by Search Console (full URL, e.g. https://example.com/blog/post). Required.
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.
queryNoOnly queries containing this text, or a regex as /…/ (e.g. "/^how to/"; no flag = case-insensitive).
deviceNoDevice.
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.
startDateNoStart yyyy-mm-dd. Default: endDate − (days − 1).
searchTypeNoSearch type (default web).
granularityNoSeries grouping (default day).
counterpartsNoTop queries to include (default 10).
pageContainsNoOnly pages whose URL contains this text (case-insensitive), e.g. "/blog/".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's contribution is return-shape and failure behavior: totals, comparison delta, series, counterparts, and the candidate-listing error. It does not mention pagination or result caps, but it adds real context beyond the annotations.

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 and efficient: purpose first, then outputs, then the exact-match rule. The trailing Portuguese echo ('/ Série de uma página exata.') adds no information for an English-reading agent and is mild noise.

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?

With 14 parameters and no output schema, the description carries the burden of describing return values, and it does so at a high level (totals, comparison, series, counterparts). Date defaults and branded-terms error conditions live in the schema, so nothing critical is missing, though the output shape is only sketched.

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 goes slightly beyond by clarifying that 'counterparts' means the queries bringing traffic to the page and that the series can be daily or weekly (granularity). Remaining parameters (device, country, brand, searchType) are covered only by the schema.

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 and resource ('Daily performance of ONE page (URL) of the property') and spells out exactly what comes back — totals with comparison change, daily/weekly series, and top counterpart queries. The capitalized 'ONE page

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?

The description establishes the context (single exact page) and warns that matching is exact, with an error that lists up to 5 candidate URLs containing the text — useful for recovery. However, it never says when to prefer a sibling such as get_query_performance, get_timeseries, or breakdown_by_path instead, so routing is left to inference.

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

All Organiq GEO toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources