Skip to main content
Glama

Agent Ready Website Audit

Check local SEO details

check_local_seo_details
Read-only

Local SEO check of a business's website: whether the page states the business name, address and phone the person gives (NAP consistency), and whether it has LocalBusiness schema, click-to-call links and an embedded Google map. Use it for local SEO questions about a shop, clinic, restaurant or office's website. result has name, address and phone, each with status match, mismatch, not_found or profile_missing (no value given) and what the site states, localSchema (types and missing fields; null when there is none), telLinks and embeddedMap. It does not read the Google Business Profile itself. These are deterministic checks of public pages fetched by Agent Ready Website Audit, with no AI model and no account. They do not cover rankings, keyword volumes, backlinks or how AI answers mention the brand. Returns JSON: summary (one sentence), reportUrl (a shareable report page for the person, kept 30 days; null for tools that keep none) and result (the details below). Errors come back as one plain sentence. Recorded: the checked domain and path (never the query string), the tool, which checks failed and the app name; never an IP address or page text.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "name": "<name>"
    },
    "name": "check_local_seo_details"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe business's page, usually its home or contact page: an absolute http or https URL, such as https://example.com/pricing.
nameYesThe business name, as on its signage.
phoneNoThe phone number in any format, such as "+1 217 555 0100". Defaults to none, which leaves the phone unchecked.
addressNoThe street address on one line, such as "12 Main St, Springfield, IL 62701". Defaults to none, which leaves the address unchecked.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/destructive annotations, it discloses the execution model (deterministic checks of public pages fetched by Agent Ready Website Audit, no AI model, no account), retention of reportUrl for 30 days, error format (one plain sentence), and a precise data-recording policy (domain and path only, never query string, IP or page text). That is materially more than the annotations supply.

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?

It is front-loaded correctly — purpose first, scope exclusions next, return shape last — and nearly every clause carries information the schema or annotations do not. The single dense paragraph with chained parentheticals (statuses, schema fields, return keys) is harder to scan than it needs to be, costing it a point on structure rather than content.

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 carries the full burden of explaining returns and does so: result structure per field with all four status values, localSchema semantics including null, plus summary and reportUrl. For a four-parameter, open-world read tool with full annotation coverage, nothing an agent needs to invoke or interpret it is missing.

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 real meaning by tying optional parameters to outcome states: omitting a value yields 'profile_missing (no value given)' rather than a failure, which tells the agent optional params genuinely skip checks. It still does not restate URL/name format constraints, but those are already fully documented in 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 opening sentence names a specific verb and resource (local SEO check of a business's website) and enumerates exactly what is examined: NAP consistency, LocalBusiness schema, click-to-call links, embedded map. It explicitly scopes itself away from adjacent territory ('does not read the Google Business Profile itself', 'do not cover rankings, keyword volumes, backlinks'), which separates it from siblings like seo_audit_page or check_agent_readiness.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete when-to-use guidance ('local SEO questions about a shop, clinic, restaurant or office's website') and clear exclusions (no GBP read, no rankings/keywords/backlinks, no AI-answer visibility). It stops short of naming which sibling tool to use for those excluded cases, so routing is implied rather than explicit.

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