Rank Tracking With MCP Using Saved Keyword Data

Rank tracking with MCP lets an AI assistant read saved keyword checks, inspect their history and help explain which changes deserve attention. It works when the assistant retrieves the actual keyword, search settings and dated analysis behind a position. Asking it to summarize “our rankings” without those details can produce a convincing report about the wrong market, device or observation.

Screpy MCP exposes existing Rank Tracker records. Reading them does not run a fresh Google search. A position belongs to the check that collected it, and a missing position needs a different interpretation from a recorded number. Those distinctions become especially important when you automate reporting.

This guide follows a read-only workflow: identify a tracked keyword, select its saved analysis, inspect the returned evidence and compare only compatible observations. It includes a real example from our own Screpy project, retrieved on October 11, 2026, plus a clearly hypothetical calculation. No new keyword checks or website changes were performed for the example.

What rank tracking with MCP actually reads

There are three jobs in this workflow. A rank-tracking service collects search results under configured settings. Its storage records analyses, positions and matching URLs. MCP gives an assistant access to supported tools that read those records. The assistant can then compare evidence and draft an explanation.

Configured rank check → saved analysis → MCP read → reviewable report

The connector does not make a model's existing knowledge into a keyword database. A useful answer needs a returned record. If the keyword has never been tracked, an assistant should say that its history is unavailable rather than produce a plausible position from memory.

Our SEO MCP server guide explains the wider connection between assistants and SEO data. For this task, the useful tools are narrower: list tracked keywords, retrieve one keyword's history and inspect a selected analysis. You do not need to grant website-editing permission to produce a read-only ranking report.

Separate “latest saved” from “current Google results” in your request. The latest saved check might be yesterday's check, especially if collection is weekly or monthly. Reading it again a few minutes later does not refresh its position. A separate live lookup, if you choose to run one, creates different evidence with a different collection time.

That separation also helps troubleshooting. If a report looks stale, first compare the analysis completion time with the project's collection schedule. Repeatedly asking the assistant the same question will not fix missing collection. If the analysis is recent but the response is internally inconsistent, inspect the selected record and supporting results before trusting the narrative.

Define the keyword and search settings first

Start with a small question: “What did our saved desktop checks for this keyword in the US show during the selected period?” It is much easier to verify than “Why did SEO get worse?” The narrower question tells the assistant which records to retrieve and which comparisons to reject.

Use these fields as the identity of an observation:

The Screpy Rank Tracker feature page describes these tracking and history boundaries. A country setting does not, by itself, establish the precise city of the observation. Keep an absent location value visible instead of filling it with your office address.

Define a reporting window before requesting history. “Last seven completed observations” and “last seven calendar days” are different requests. A weekly collector may supply only one observation during a seven-day window. Failed or missing checks can also leave gaps. Report those gaps rather than smoothing them into a daily line.

For a portfolio report, preserve the keyword cohort as well. Adding twenty new phrases can change an average even when every existing keyword keeps its position. Save the included IDs and filters so the next report measures the same set, or explicitly explain why the set changed.

Retrieve a keyword and select its stored analysis

Connect an MCP client using the Screpy MCP setup instructions, then discover the authorized project. Use the tool names and arguments exposed by your connection; a client's display prefix may differ from the underlying tool name.

First call list_rank_tracker_keywords with the project UID, a phrase filter and a device filter. This illustrative argument object searches the saved list; it does not add a keyword or search Google:

{
  "project_uid": "YOUR_PROJECT_UID",
  "search": "seo mcp",
  "device": "desktop",
  "limit": 10
}

Review the returned matches. A search filter may find several related phrases, so confirm the exact text, market and device before choosing an ID. If the response supplies a next cursor, continue with that cursor when you need the complete matching list. One page of records is not necessarily the whole project.

Next call get_rank_tracker_keyword. Replace the illustrative number below with the ID returned for your actual keyword:

{
  "project_uid": "YOUR_PROJECT_UID",
  "keyword_id": 123456,
  "history_limit": 6
}

The response contains keyword metadata, recent analyses and the selected analysis with stored results. The tool defaults to the latest analysis; it also accepts an optional analysis_id to retrieve a particular project-scoped observation. For a reproducible report, record that selected ID and its completion time. If you revisit the report later, explicitly select the same analysis rather than silently replacing it with a newer check.

The current keyword-detail tool supports up to 30 analyses. That limit is a retrieval boundary, not evidence that only 30 checks exist or that the product retains exactly 30 days. Check a supported history endpoint when the required period exceeds what the tool returned.

The MCP tool reference is the place to verify supported operations. Keep this investigation read-only: adding keywords consumes tracking capacity and starts collection, while deleting them changes the project. Neither is necessary to inspect history that already exists.

Interpret missing positions and result coverage

On October 11, 2026, we retrieved the saved desktop record for seo mcp in our own project, configured for the US and English. Its selected check had finished on October 10 at 05:21:17 UTC. The following is an abbreviated subset of the actual response, with project and record identifiers omitted:

{
  "keyword": {
    "keyword": "seo mcp",
    "device": "desktop",
    "country_code": "US",
    "language_code": "en",
    "location": null,
    "last_position": null,
    "best_position": 24
  },
  "selected_analysis": {
    "analysis": {
      "status": "completed",
      "position": null,
      "owned_results_count": 0,
      "matched_url": null,
      "finished_at": "2026-10-10T05:21:17+00:00"
    },
    "coverage": {
      "organic_results_scanned": 99,
      "scan_complete": true,
      "stored_results": 9
    }
  }
}

The defensible conclusion is that this selected saved check recorded no matching project position. It is not position zero. It does not establish that the website disappeared from Google's index, or that no user in any market could find it. The collection has a scope, a time and a finite result set.

The historical best position, 24, answers a different question from the latest position. Reporting “we rank 24” would substitute a past best for the selected check. Keep those fields separate, even when the older number looks more encouraging.

Coverage also needs care. The tool reported 99 organic results scanned but only nine stored result rows. Nine is the returned storage count, not the full depth of the search. You cannot reconstruct every competitor position or every omitted result from that subset.

Before interpreting any returned analysis, check consistency: does its summary agree with the matching URL and relevant result rows? Are the timestamps and selected IDs what you requested? If a summary says one position while the supporting rows appear to show another, preserve the discrepancy and investigate the data's collection context. An assistant should not resolve it by choosing whichever number makes the report look better.

Compare history without inventing a trend

Use a comparison rule before calculating changes. Both observations should belong to the same tracked keyword and compatible search settings, have completed successfully and contain usable numeric positions. Check the matched page and the analysis evidence as well. A number can be syntactically valid while its supporting record still needs review.

For a hypothetical pair of compatible checks, an older position of 84 and a newer position of 70 represent an improvement of 14 places:

places improved = older position − newer position
                 = 84 − 70
                 = 14

These numbers illustrate the calculation; they are not a measured gain attributed to this workflow. State your direction convention because a signed “change” field is easy to misread. A lower organic position number is better, while the formula above produces a positive improvement.

Do not quietly replace a missing value with 100 or 101. Some products use defined conventions for portfolio metrics, but that does not authorize inventing a raw position for a Screpy analysis. If you report an average of valid observations, disclose how many observations were included and how many were unavailable. Otherwise the average may improve simply because difficult-to-find keywords dropped out of the denominator.

Preserve raw URLs. A trailing slash difference may be a harmless redirect or may matter on a particular website. Inspect the actual response and canonical behavior before merging addresses into one page identity.

For recurring reports, save the filters, selected keyword IDs, observation timestamps and calculation rule. Our keyword ranking report guide covers the wider reporting document. The MCP-specific requirement is that another reviewer can reproduce the records behind every comparison.

Turn the report into a defensible SEO investigation

A changed position tells you where to investigate; it does not identify the cause. Start with the recorded landing page. Is it the page intended for that query? Does it still load, and did its content, canonical, redirects or internal links change during the relevant period? An unexpected URL is a useful lead, but one selected URL does not prove keyword cannibalization.

Compare the tracking observation with Search Console when you need evidence about actual search exposure. Google's position metric documentation explains that average position is calculated from impressions and depends on the report's aggregation. A scheduled rank check is a separate observation under configured settings. Do not expect it to equal a multi-day Search Console average, even after narrowing country and device.

Use Search Console clicks and impressions to ask whether a tracking change coincided with a change in search performance. Coincidence still does not demonstrate that a particular edit caused it. Record relevant site changes and consider competing explanations before prescribing a rewrite. The Google Search Console MCP guide covers accessing that first-party dataset separately.

Give the assistant a reporting contract such as:

Read the existing tracked keywords for the selected project and device. For each included keyword, show its exact market, selected analysis ID, completion time, recorded position and matching URL. Compare only compatible completed observations. Keep missing positions nonnumeric, list incomplete retrieval and contradictory evidence separately, and label possible causes as hypotheses. Do not add keywords, launch checks or edit the website.

Review the resulting report in three passes. First, verify scope and dates against the returned records. Second, check calculations, excluded observations and supporting URLs. Third, evaluate the proposed investigation: does the evidence justify checking a redirect, reviewing intent or waiting for another scheduled observation?

Finish with a specific next step and an owner. “Verify whether the intended page still resolves and appears in the next compatible check” is actionable. “Fix SEO because the model says rankings are down” is not. Rank tracking with MCP is most useful when it makes the evidence easier to inspect and the next decision easier to defend.