Skip to main content
Glama

Quick wins (positions 4-20)

report_quick_wins
Read-only

Query+page pairs ranking at positions 4-20 with many impressions: the cheapest traffic to gain by improving existing pages. Sorted by potential extra clicks.

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": {
      "site": "<site>"
    },
    "name": "report_quick_wins"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYesSearch Console property or domain (matched automatically).
chartNoAlso return a PNG chart of the result as an image, for clients that can display images.
limitNo
rangeNoPreset period ending yesterday (your local calendar day). Default last_28_days. Ignored when start_date/end_date are given.
end_dateNoYYYY-MM-DD (use together with start_date)
start_dateNoYYYY-MM-DD (use together with end_date)
min_impressionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the ranking logic (sorted by potential extra clicks) and the position band, but says nothing about how results are computed, what fields come back, or limits on volume beyond the schema's limit parameter.

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?

Two tight sentences: the definition and scope first, the sort criterion second. No restated field names, no filler, and the most decision-relevant fact (positions 4-20, high impressions) is front-loaded.

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?

For a 7-parameter analytical report with no output schema, the description does not describe the returned columns (positions, impressions, potential clicks) that an agent would need to interpret results. It is adequate for selecting the tool but thin for understanding its output.

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?

With 71% schema description coverage, the schema already documents site, chart, range, and dates well, so baseline 3 applies. The description only hints at min_impressions via 'many impressions' and adds nothing about limit, sorting, or date interplay beyond what the schema states.

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 concrete resource and scope: query+page pairs ranking at positions 4-20 with many impressions, sorted by potential extra clicks. The notion of 'cheapest traffic to gain' frames the metric distinctly from siblings like report_ctr_outliers or report_content_decay, though it never names an alternative explicitly.

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 phrase 'the cheapest traffic to gain by improving existing pages' implies when this report is useful (prioritizing near-term opportunities), but there is no explicit when-to-use/when-not guidance and no named alternative among the many sibling report_* tools. An agent must infer selection from the concept alone.

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.

Resources