Skip to main content
Glama

Rank fixes by traffic impact

prioritize_fixes
Read-onlyIdempotent

Rank SEO fixes by how much traffic they can win, using data from the user's other connected tools. With GA4, also pass each page's organic conversions (key events) or revenue, and fixes are ranked by the money they can bring instead of clicks. Pass clicks_previous (an earlier period of the same length) to catch pages that are losing clicks and need a content refresh. Before calling, look at your available tools: if Google Search Console, GA4, Ahrefs, Semrush or a similar source is connected, fetch the top pages (clicks, impressions, CTR, average position, organic traffic, referring domains) and their top queries (with position and search volume) for the site, at most 10 pages and 20 queries per page, and pass them here. Fields are optional; pass what the source has. Without traffic data it still works and ranks by severity. Pages are scanned by OnPage.dev (3 per call, kept 15 minutes); with more pages it asks you to call again with the same arguments. Pass audit_id from a finished site audit to skip rescanning. Traffic data is used for this answer only and not stored.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pagesYes
sourceNoWhere the numbers come from.
audit_idNoOptional id of a finished site audit, so pages are not scanned again.
currencyNoCurrency of revenue, for example EUR or USD.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
statusYes
actionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / pages / items / properties / clicks_previous
      Added value: +{
      +  "description": "Clicks in an earlier period of the same length, for example the same 3 months a year or 6 months ago. Pages that lost clicks get a refresh fix.",
      +  "minimum": 0,
      +  "type": "number"
      +}
  2. Changed4 schema fields changed
    • addedInput schema / properties / currency
      Added value: +{
      +  "description": "Currency of revenue, for example EUR or USD.",
      +  "maxLength": 3,
      +  "type": "string"
      +}
    • addedInput schema / properties / pages / items / properties / conversions
      Added value: +{
      +  "description": "Conversions (GA4 key events, sales, leads) from this page's organic visits in the same period.",
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / pages / items / properties / revenue
      Added value: +{
      +  "description": "Revenue from this page's organic visits in the same period.",
      +  "minimum": 0,
      +  "type": "number"
      +}
    • changedOutput schema / properties / mode / enum
      Previous value: -[
      -  "traffic",
      -  "severity"
      -]New value: +[
      +  "revenue",
      +  "conversions",
      +  "traffic",
      +  "severity"
      +]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds substantial non-obvious behavior: pages are scanned by OnPage.dev 3 per call and cached 15 minutes, exceeding that count triggers a re-call with identical arguments, audit_id from a finished audit skips rescanning, and traffic data is not stored. This is exactly the operational context annotations cannot convey.

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 with purpose before mechanics, and almost every sentence carries actionable detail (limits, pagination, privacy, prerequisites). It is a dense single block with no visual structure, which costs a point, but there is little waste.

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 tool with an output schema, prerequisites, batch limits, cache/retry behavior, optional audit reuse, and the no-data fallback are all disclosed. Nothing an agent needs to invoke it correctly or interpret the trade-offs is missing.

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 already 75%, so the baseline is high, but the description adds real meaning beyond the schema: it explains why conversions/revenue change the ranking dimension ('ranked by the money they can bring instead of clicks') and frames clicks_previous as a content-refresh signal. It does not add syntax for source/currency, keeping it just below a 5.

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+resource+scope: 'Rank SEO fixes by how much traffic they can win,' and immediately qualifies the ranking basis (traffic/clicks vs. money via conversions/revenue). An agent can tell this apart from siblings like get_fix_pack or measure_impact because the outcome (prioritized fix ranking) is named precisely.

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?

Explicitly prescribes the pre-call workflow (fetch top pages/queries from connected GSC/GA4/Ahrefs/Semrush), states when to add conversions/revenue (GA4 present -> rank by money), when to pass clicks_previous (catch declining pages), and what happens when no traffic data exists. When-and-how guidance is fully covered.

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.