Skip to main content
Glama

Free Google visibility scan

scan_google_visibility

Free check of whether Google can index a website well: Googlebot access in robots.txt and on the server, noindex, canonical, http-to-https and www redirects, the sitemap and whether its URLs answer 200, titles, meta descriptions, H1, structured data, mobile viewport, hreflang and Core Web Vitals from real Chrome users. Takes about 15-60 seconds. Returns the grade (A-F), the score and the list of problems, without fixes. When available, it also returns an Ahrefs estimate of the domain in Google (ranking keywords, monthly organic traffic, Domain Rating, referring domains). These numbers are estimates, not Search Console data, they do not affect the grade, and they are sometimes temporarily unavailable. The report is in Polish. The full report with step-by-step fixes and a PDF is sent by JustIdea Agency to the user's e-mail. Use only details the user gave you: never invent or guess an e-mail address. Before calling, tell the user the report goes to their e-mail and ask for consent under the privacy policy (https://justidea.agency/en/privacy-policy/); set zgoda to true only after they agree. At most 2 scans per e-mail address per day. If it returns status "running", call get_scan_result with the scan_id after 30-60 seconds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe website to scan: a domain or URL, e.g. "mystore.com". Only the home domain is used.
nameNoOptional. The user's first name, only if they gave it.
emailYesThe user's own e-mail address. The full report with fixes is sent there, and only there.
phoneNoOptional. The user's phone number, only if they gave it and want a call about the results.
zgodaYesMust be true: the user agreed to receive the report by e-mail, to be contacted by JustIdea about the results, and to the processing of this data under the privacy policy.
languageNoReport language. Use "pl" for Polish-speaking users, "en" for everyone else.pl

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, and the description adds rich context well beyond them: 15-60s runtime, email delivery of the full report, Polish-language output, rate limits, privacy-consent requirement, and that Ahrefs figures are estimates that can be temporarily unavailable and do not affect the grade. No contradiction with annotations.

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?

Purpose and core behavior are front-loaded, and the operational/consent/async rules are grouped logically. It is long, but nearly every sentence carries actionable information; minor tightening of the Ahrefs and delivery sentences would make it cleaner.

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?

With no output schema, the description still covers return values (grade A-F, score, problem list, optional Ahrefs estimates) and the asynchronous 'running' flow. An agent has everything needed to call correctly, handle consent, and follow up.

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 100%, so the baseline is 3, but the description adds meaning the schema lacks: zgoda is consent-gated by the privacy policy step and must only be set after the user agrees, and language maps to Polish vs. everyone else. It adds value without needing to restate field formats.

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 (a free Google visibility/indexing scan) and enumerates the exact checks performed (robots.txt, noindex, canonical, redirects, sitemap, titles, structured data, CWV, etc.). It is instantly distinguishable from scan_ai_visibility and scan_analytics.

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?

Explicit when-to-use and operational guidance: obtain consent before calling, set zgoda=true only after agreement, use only user-supplied details and never invent an e-mail, respect the max 2 scans per e-mail/day, and if status is 'running', call get_scan_result with the scan_id after 30-60s. Names the sibling tool to use for async retrieval.

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