Keyword Research With MCP: Search Volumes, SERPs, and Content Gaps

Keyword research with MCP connects an AI assistant to actual keyword and search-result data, then uses that evidence to decide what your website should improve or publish. The useful workflow is to retrieve market-specific search estimates, inspect the current SERP, and compare both with Search Console and existing content. A keyword list without those checks is still only a list of suggestions.

The connection must expose the right data. Search Console impressions are not total market searches, stored rank-tracker results are not live SERPs, and a phrase absent from a provider response has unknown coverage rather than proven zero demand.

We tested a small workflow through DataForSEO's current MCP server on October 1, 2026, and combined its results with a separate Screpy MCP Search Console observation. The keyword task requested six phrases and returned five records. That compact example makes the source limits, interpretation, and content decisions visible without claiming that every provider or AI client behaves identically.

Use separate sources for demand, rankings, and page coverage

The first step is to define which number answers which question. Connecting an assistant to multiple tools is useful only if their outputs retain their original meaning. The SEO MCP server guide explains why the connection does not create data the provider lacks.

Do not merge a US keyword estimate with all-country Search Console impressions and present the result as one shared market metric. They can inform a decision together, but their scopes differ.

For a real research brief, record the website, audience, target country and language, business goal, seed phrases, and constraints. A documentation site seeking relevant developer readers needs different candidates from a local service business seeking inquiries.

Screpy Keyword Research is relevant to market research in the product. However, Screpy's current member MCP tool set does not expose those search-volume operations or live SERP lookup. This worked MCP example therefore uses an additional DataForSEO connection for market data and Screpy MCP for the first-party observation.

This source separation prevents a common failure: the assistant sees a plausible phrase, finds a few impressions somewhere, and assigns a confident volume or traffic forecast. Ask it to identify the provider and definition for each metric. If the requested source cannot supply the field, retain it as unavailable and continue with the evidence you actually have.

Connect a keyword data provider and inspect its tools

Choose a provider whose supported operations supply both the metrics and the search-result evidence your workflow needs. The model cannot retrieve a field simply because it knows the name of an SEO product. The SEO MCP server comparison helps distinguish providers before you connect one.

For the DataForSEO example, the current official MCP repository documents a remote v3 endpoint:

https://mcp.dataforseo.com/v3/mcp

It also documents local stdio operation. Follow the current authentication path for your client and transport; do not paste credentials into a public prompt or shared article.

Our programmatic test used existing API credentials to initialize the remote MCP connection. The server reported version 3.1.1 and exposed these discovered tools:

This is important for anyone following older tutorials with different tool names. Discover the current schema before issuing a call. The data request in this example went through MCP's tools/call with api_request; it was not a direct API call relabeled as an MCP demonstration.

The local and remote setup options are documented, but this test does not establish that we completed every AI client's OAuth flow. Use a compatible client and verify discovery and one small authenticated result before expanding the research.

An illustrative prompt for the first task is:

Inspect the connected keyword provider's tools and documentation. Prepare a US English lookup for the six supplied seed phrases, preserving reported periods and missing records. Do not expand the list or repeat calls automatically. Show the planned request and check the applicable account charges before executing it.

Treat any budget in your prompt as a workflow instruction, not an assumed provider-side spending control. Confirm the endpoint pricing and use your account's actual limits where available. Bounded batches and saved results make the research easier to audit and less likely to repeat paid work.

Pull search volumes without filling gaps with guesses

We requested six phrases through the discovered api_request tool. This is the actual argument structure used for the keyword lookup:

{
  "method": "POST",
  "path": "/v3/dataforseo_labs/google/keyword_overview/live",
  "noAiMode": true,
  "data": [
    {
      "keywords": [
        "seo mcp",
        "google search console mcp",
        "keyword research mcp",
        "ahrefs mcp",
        "semrush mcp",
        "dataforseo mcp"
      ],
      "location_code": 2840,
      "language_code": "en",
      "include_serp_info": true
    }
  ]
}

The authenticated MCP request succeeded and returned five keyword records:

These are observed provider estimates for the United States and English, retrieved on October 1, 2026. They are not global counts or Screpy traffic. The latest monthly observations in this response ended in August; retrieving them in October does not make them October measurements.

DataForSEO's keyword-overview reference describes the estimate and monthly fields. Keep the average separate from an individual month's value. In this sample, labeling 480 as the August value for “google search console mcp” would be wrong.

The missing phrase stays unknown. A separate earlier research batch, made directly through the data API rather than MCP, returned 21 records for 75 requested phrases. Neither batch's return rate is a general accuracy benchmark or proof that absent terms have no demand.

The six-phrase MCP task reported a cost of $0.0126. Save the result before doing further analysis; changing the article outline does not require buying the same metrics again.

Do not add these volumes together as unique people or a guaranteed traffic opportunity. Related phrases can share intent, and a search-volume estimate does not tell you how many clicks one page can win. Use the numbers to prioritize inspection, then check the SERP and your existing coverage.

Read the SERP before calling a keyword an opportunity

Search volume helps decide which terms deserve attention. The result page helps determine what kind of page could satisfy the reader.

Through the same MCP connection, we requested a live Google organic SERP for “seo mcp,” using the United States, English, desktop, and a depth of ten. The October 1, 2026 response returned a mixture of result types:

This table summarizes the returned sample; it does not establish a stable ranking order or one dominant intent for all users. A provider-retrieved SERP is a dated observation for the specified market and device.

For a new topic, mixed results may justify investigating an educational guide and a product page with different purposes. They do not establish low competition. Forum posts, directories, and strong commercial pages can still be difficult to outrank.

Open relevant competing pages before finalizing the brief. Inspect what they actually answer, whether examples work, which requirements are missing, and how their claims are supported. A title alone is not enough to judge content quality.

Use the provider's live SERP documentation to confirm the request parameters. Preserve the observation date and organic-result scope in your notes. Do not treat keyword-database ranking history as the same thing as this live response.

The useful output is a page-type decision with evidence: explanatory guide, connection instructions, provider comparison, or another specific format. Avoid generating a title for every phrase before you know whether the phrases represent different reader tasks.

Join market data to Search Console and existing pages

Market data identifies candidates. First-party performance and your page inventory help decide whether those candidates need a new page, an update, or further research.

For our worked example, a separate Screpy MCP request returned this row for web search between July 1 and September 28, 2026:

The keyword provider's average estimate was 90 monthly searches in its US dataset. The Search Console row covers our property's impressions across countries and devices over a different window. The numbers belong beside their definitions, not in a formula that pretends they measure the same population.

The existing feature page changes the content decision. “We have no page for this keyword” would be inaccurate. The actual question is whether that page satisfies the reader's product-selection task and whether a separate educational guide has a distinct purpose.

A useful join uses the keyword phrase, observed ranking URL, and page intent:

1. Preserve the raw query and URL from Search Console.
2. Map the URL to the current CMS or site inventory.
3. Check redirects and the intended canonical destination where relevant.
4. Read the current content and identify the task it serves.
5. Compare that task with the dated SERP sample.
6. Record an update, new-page, or defer decision with supporting evidence.

Do not silently remove query strings, combine different hostnames, or discard language folders when normalizing URLs. Those differences can identify different pages. Preserve the original value so mappings can be checked.

Screpy Search Console supplies the own-site performance context. Its returned query rows can be incomplete, so an absent query or page cannot prove no visibility or no existing coverage. The Search Console MCP analysis guide explains the connection, filters, and reporting checks used for that source.

For competitor content gaps, use the external provider's supported ranking or comparison data and label it as estimated index evidence. Then verify that an apparent gap matches a relevant audience need. A competitor ranking for a term your site lacks is a candidate to review, not an automatic instruction to publish.

Build content gaps around intent, not keyword variants

A content gap is a relevant reader need that your current content does not adequately serve. It is not every phrase missing from a title or every term an assistant can generate.

Use an intent-based decision table. The examples below illustrate decisions, not measured results for these phrases:

Compare more than words. Different keywords can share one job, while a broad phrase can contain several legitimate intents. Inspect competing pages, actual query-page relationships, and your existing content before grouping or splitting.

Ask an assistant to propose clusters with the evidence for each grouping. Result-page overlap can support a shared-intent hypothesis, but no universal percentage determines whether two topics must share a page.

Also distinguish a content gap from a technical visibility problem. A useful existing article may be difficult to discover because of internal links, unintended indexing directives, or another verified technical issue. Creating a replacement article could leave the actual problem unresolved.

An actionable gap record names the reader's question, the existing pages checked, the missing answer, and the contribution a new page would provide. The SEO content brief guide can help turn that decision into requirements for a writer.

Review each proposed page individually. A small cluster with distinct purposes is more useful than a large set of client names or keyword variations wrapped around the same tutorial.

Save a reproducible keyword research brief

The final deliverable should explain why each proposed page deserves to exist. Save a concise brief with enough source information that another editor can challenge the decision.

For each recommended topic, retain:

• The primary reader question and intended page type.
• Keyword provider, country, language, average estimate, and latest available monthly observation.
• Missing metrics marked unknown.
• SERP observation date, device, and competing page examples reviewed.
• Existing pages checked and their distinct intents.
• First-party query-page evidence with its property, dates, and filters.
• The proposed contribution, source requirements, and contextual internal links.
• A decision to create, update, combine, or defer, with a reason.

Do not turn rough opportunity scores into traffic forecasts. If you use a prioritization formula, label its weights as editorial choices and retain the underlying evidence. Search demand, business relevance, achievable scope, and existing coverage can inform the ranking without promising a particular number of visits.

An illustrative final prompt is:

Use only the recorded keyword metrics, SERP sample, Search Console rows, and existing-page inventory. Propose distinct content decisions, cite the evidence for each, preserve unknown fields, and identify overlap risks. Do not fetch more paid data, create articles, or change the website.

Use the existing guide to keyword cannibalization when a proposed page overlaps current coverage. Recheck volatile provider requirements and SERP evidence before acting on an older brief.

Keyword research with MCP works best when the assistant connects evidence to decisions. Preserve the sources and limits, inspect the actual reader need, and create a page only when you can explain what useful answer it adds.