Skip to main content
Glama
Sign In

Quattr

by com.quattr.mcp
OverviewDiscussionsAdmin

ctr_curve_model

Read-only

Model THIS website's own click-through-rate curve by SERP position — "what CTR should we expect at position N?", "which queries over/under-perform their expected CTR?". Fits weighted CTR (clicks÷impressions) per position bucket from your query×page Search Console data with a monotone-decreasing isotonic fit, SEGMENTED by branded vs non-branded, intent and device — because a single blended curve hides the branded/non-branded gap that dominates CTR. Returns the fitted curve(s) plus the biggest over- and under-performers. Use this before striking_distance (which consumes the fitted curve). For raw clicks/impressions use search_performance; for movement use seo_ranking_movement_report.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date_range": "<date_range>"
    },
    "name": "ctr_curve_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandNoRestrict to branded ("Yes") or non-branded ("No") demand. The curve is ALWAYS segmented by brand internally; this just narrows which cells are fitted.
deviceNoRestrict to one device.
intentNoRestrict to one intent (a customer keyword group). Resolve the id with resolve_entity first.
sourceNoWhere Google search performance data is read from. Use "bigquery" ONLY when the user explicitly asks for BigQuery as the source AND describe_data_sources reports it available from live customer configuration — it returns far more granular per-query data (privacy-suppressed impressions appear under "[anonymized by google]").default
date_rangeYesExplicit date range, e.g. "2026-05-01 to 2026-05-31". Both endpoints are INCLUSIVE — the END day is covered (a 7-day range = 7 days). Quattr weeks run Sunday–Saturday; for "last week" use the most recent complete Sun–Sat span.
top_n_performersNoHow many over- and under-performers (actual − expected CTR, ranked by |delta|×impressions) to return.
min_bucket_instancesNoPer-bucket reliability floor — a position bucket fitted from fewer than this many query×page instances is FLAGGED low-confidence (default 5). It is not dropped, but its expected CTR is unreliable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description goes well beyond that by disclosing methodology (monotone-decreasing isotonic fit on weighted CTR), that output is always internally segmented by brand/intent/device, and what is returned (fitted curve(s) plus ranked over/under-performers). It also flags a non-obvious source constraint (bigquery only when explicitly requested and confirmed by describe_data_sources).

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?

Front-loaded with the core purpose and the triggering questions, then methodology and rationale, then return shape, then sibling routing — a clean escalation. Quoted example questions and the branded/non-branded rationale earn their place by giving the agent matching cues; no sentence is filler.

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?

With no output schema present, the description compensates by naming what is returned (fitted curve(s) plus biggest over/under-performers). Combined with the annotation-covered safety profile and the schema's full parameter documentation, an agent has everything needed to invoke this correctly and interpret the result.

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 100%, so every parameter — including the brand, source, min_bucket_instances and top_n_performers semantics — is already documented in the schema. The description's mention of segmentation ('SEGMENTED by branded vs non-branded, intent and device') conceptually frames those filter params but adds no syntax or behavior beyond what the schema states. Baseline 3 applies.

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?

The description states a specific verb and resource (fit/model a CTR curve by SERP position) and immediately grounds it in the two questions it answers. It explicitly distinguishes itself from three named siblings (striking_distance, search_performance, seo_ranking_movement_report), so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

Explicit sequencing instruction: 'Use this before striking_distance (which consumes the fitted curve)' tells the agent both the ordering and the dependency. It also names the correct alternatives for adjacent needs — raw clicks/impressions → search_performance, position movement → seo_ranking_movement_report — leaving nothing to inference.

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

All Quattr 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