Skip to main content
Glama
Akxan

google-seo-mcp

by Akxan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Answer coverage: can an AI lift an answer off the page

geo_answer_coverage
Read-onlyIdempotent

Check whether page content visibly answers real search questions, flagging missing, weak, buried, or thin passages and extracting the answer text for AI relevance.

Instructions

Per question, what to write. Reads the page body (not just its headings, which is all gsc_question_queries checks) and for each question users actually search, finds the passage meant to answer it and judges whether an AI could extract it: missing (nothing covers it), weak (the terms appear in prose but no heading is aimed at the question), buried (the answer starts more than 60 words into the passage), thin (nothing concrete to lift), ok (returns the extracted answer, so you can judge relevance yourself - the match is lexical, not semantic). Also flags when the question shape demands something the passage lacks - a figure for 'how much', steps for 'how to', a list for 'best/which'. Questions come from Search Console unless you pass your own with pages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pagesNoPages to read. Default: the page Search Console shows for each question.
endDateNoEnd of the window; Search Console lags 2-3 days.3daysAgo
siteUrlNoSearch Console property, e.g. 'sc-domain:example.com'. Only omit it when you pass both questions and pages.
faqDraftNoInclude a FAQPage JSON-LD draft built from the passages that pass. Publish it only for answers visible on the page.
maxPagesNoHow many distinct pages to fetch.
questionsNoCheck these questions instead of pulling them from Search Console. Requires pages.
startDateNoStart of the Search Console window.90daysAgo
maxQuestionsNoHow many questions to check, most impressions first.
minImpressionsNoIgnore questions below this many impressions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description reveals behavior not visible in schema: it returns five judgment categories, explains the match is lexical not semantic, notes a 60-word buried threshold, and describes question-shape checking for figures/steps/lists. It is consistent with readOnlyHint; even the faqDraft is only a draft, not a publish action.

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?

The description is dense but every sentence carries information: the purpose, the key statuses, the lexical-match caveat, the shape flags, and the data-source rule. The most important scoping detail (reads page body, not headings) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return semantics, and it does well by enumerating statuses and the extracted-answer behavior. It only slightly under-specifies the exact response structure an agent should expect, but for a complex multi-status tool this is a minor gap.

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 coverage is 100%, so the schema already documents all 9 parameters. The description reinforces the relationship between questions and pages and the Search Console source, but adds little parameter-specific meaning beyond the schema.

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 clear verb + resource: it reads the page body and judges, per question, whether an AI can extract an answer, listing the exact statuses. It also distinguishes itself from gsc_question_queries, so an agent can tell them apart without opening schemas.

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?

The description names the sibling alternative (gsc_question_queries) and states the difference: that check only looks at headings, while this tool reads the body. It also clarifies when questions come from Search Console vs. when to pass custom questions with pages, giving concrete invocation context.

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

Deploy Server

Other Tools