AgentSEO MCP Server

AgentSEO Local Audit

agentseo_local_audit

Destructive

Audit one Google Maps business listing by providing its business name and city/state/country; do not pass a website URL or domain.

Instructions

Audit one Google Maps business listing. Provide its business name and city/state/country; do not pass a website URL or domain. Uses AgentSEO credits; repeating the call can create new charged work.

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": {
      "business_name": "<business_name>",
      "location": "<location>"
    },
    "name": "agentseo_local_audit"
  }
}

Input Schema

Name	Required	Description	Default
`sync`	No	Request a bounded wait for completion when true. The API can still return a pending job; retain its job ID and poll agentseo_job_status instead of repeating this charged call. False returns a queued job without waiting. Type: Boolean. Default: true.
`language`	No	Supported search language code, for example en for English. Type: String. Default: "en".	en
`location`	Yes	Business city, state/region and country as a human-readable place name, for example Austin, Texas, United States. Type: String. Required.
`business_name`	Yes	Business name as shown in its Google Maps listing, not a website domain or URL. Type: String. Required.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.1.5Nov 5, 2026

changedInput schema / properties / business_name / description

Previous value: -"Business name as shown on Google Maps, not a domain or URL"New value: +"Business name as shown in its Google Maps listing, not a website domain or URL. Type: String. Required."

addedInput schema / properties / language / description

Added value: +"Supported search language code, for example en for English. Type: String. Default: \"en\"."

changedInput schema / properties / location / description

Previous value: -"City, state, and country of the business"New value: +"Business city, state/region and country as a human-readable place name, for example Austin, Texas, United States. Type: String. Required."

addedInput schema / properties / sync / description

Added value: +"Request a bounded wait for completion when true. The API can still return a pending job; retain its job ID and poll agentseo_job_status instead of repeating this charged call. False returns a queued job without waiting. Type: Boolean. Default: true."

First observedv0.1.4Nov 4, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description reinforces the non-idempotent profile with the concrete consequence: credits are consumed and repeating the call can create new charged work. That cost/duplication warning is exactly the kind of context annotations cannot express. It does not say how long an audit takes or what a result looks like, so it is not a full behavioral picture.

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?

Two sentences, no filler, with the resource scope and required inputs front-loaded before the cost caveat. Every clause carries actionable information.

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

Completeness3/5

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

For a charged, non-idempotent, open-world call the description covers scope, inputs and cost, which is the critical part. However, with no output schema there is no indication of what an audit returns or how results are shaped, and the polling fallback lives only in the sync parameter description rather than the tool description.

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 both required fields and the sync/language defaults are already documented in the schema, including the "not a website domain or URL" note the description repeats. The description does add the city/state/country shape for location, but it says nothing about sync or language that the schema has not already covered. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Audit one Google Maps business listing" gives a specific verb and a narrowly scoped resource, so an agent can distinguish it from the many domain/site/backlink siblings. It stops short of naming a sibling such as agentseo_local_visibility_track, so the differentiation is implicit rather than explicit.

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

Usage Guidelines3/5

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

It tells the agent what to supply and adds a negative constraint ("do not pass a website URL or domain"), which prevents a common misuse. It never says when to pick this over agentseo_local_visibility_track or the other local/site tools, so selection guidance is only implied.

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

Deploy Server