Skip to main content
Glama

SEO GSC Wizard MCP

Inspect a URL

inspect_url

Use this when the user asks whether one specific URL is indexed by Google and why. Runs the Google URL Inspection API for one URL and stores the result in the GSC Wizard inspection history. Returns the verdict, coverage state, robots.txt state, last crawl time, the fetched/crawled-as info, the Google-selected canonical (googleCanonical), the user-declared canonical (userCanonical), and a link to the result in Search Console (inspectionResultLink). A canonical field is null when Google did not report it for this URL (common for pages it has not indexed); it is never inferred from the page. GSC enforces a daily per-property quota, so call get_inspection_quota first if you plan to inspect many URLs. Not for many URLs: use bulk_inspect_urls (up to 25) or add_tracked_urls for scheduled checks; for stored past results use list_url_inspections.

Input Schema

NameRequiredDescriptionDefault
siteUrlYes
inspectionUrlYesThe fully-qualified URL to inspect. Must belong to siteUrl.

Output Schema

NameRequiredDescriptionDefault
messageNo
siteUrlNo
verdictNo
nextStepNo
crawledAsNo
coverageStateNo
indexingStateNo
inspectionUrlNo
lastCrawlTimeNo
referringUrlsNo
userCanonicalNo
pageFetchStateNo
quotaExhaustedNo
robotsTxtStateNo
googleCanonicalNo
inspectionResultLinkNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedOutput schema / additionalProperties
      Previous value: -falseNew value: +true
    • addedOutput schema / properties / message
      Added value: +{
      +  "$ref": "#/properties/siteUrl"
      +}
    • addedOutput schema / properties / nextStep
      Added value: +{
      +  "$ref": "#/properties/siteUrl"
      +}
    • addedOutput schema / properties / quotaExhausted
      Added value: +{
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
  2. Changed3 schema fields changed
    • addedOutput schema / properties / googleCanonical
      Added value: +{
      +  "$ref": "#/properties/siteUrl"
      +}
    • addedOutput schema / properties / inspectionResultLink
      Added value: +{
      +  "$ref": "#/properties/siteUrl"
      +}
    • addedOutput schema / properties / userCanonical
      Added value: +{
      +  "$ref": "#/properties/siteUrl"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false, and the description confirms the write side effect clearly ('stores the result in the GSC Wizard inspection history'), so there is no annotation contradiction. It goes further than the annotations by disclosing the daily per-property Google quota and the null-canonical semantics ('never inferred from the page'), which materially affect how an agent interprets results.

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?

The description is front-loaded with the trigger condition and alternatives are placed at the end where they belong, so an agent can stop reading early. It is somewhat long, and the enumeration of return fields (verdict, coverage state, robots.txt state, canonicals, inspectionResultLink) partly duplicates the output schema rather than adding new information.

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 two-parameter, open-world inspection tool with an output schema, the description covers everything needed to call it correctly: the single-URL constraint, the storage side effect, the quota caveat with a prerequisite tool, and the sibling alternatives. No operational gap remains despite the thin siteUrl documentation.

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 description coverage is 50%: inspectionUrl is documented in the schema ('Must belong to siteUrl') while siteUrl is undocumented in both schema and description. The description reinforces single-URL scoping but adds no format or relationship detail for siteUrl, so it only marginally compensates for the gap.

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 names a specific verb and resource ('Runs the Google URL Inspection API for one URL') and scopes it to exactly one URL. It explicitly separates itself from bulk_inspect_urls, add_tracked_urls, and list_url_inspections, so an agent can route between them without opening any schema.

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?

It states the triggering condition ('when the user asks whether one specific URL is indexed by Google and why'), the negative case ('Not for many URLs'), and the concrete alternatives with their own constraints (bulk_inspect_urls up to 25, add_tracked_urls for scheduled checks, list_url_inspections for past results). It also prescribes calling get_inspection_quota first when volume is expected.

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