Local SEO Data

Official

Overview Schema Source Related Servers Discussions(1)Admin

apple_maps

Read-only

Check how a business ranks on Apple Maps for a keyword and location, returning rank, listing details, ratings, reviews, and claim status for iPhone/Siri visibility.

Instructions

Checks how businesses rank on Apple Maps for a keyword. Use when the question is about Apple Maps, Siri, Apple Business Connect, or visibility on iPhone — Google local_pack does not cover these. Returns rank, name, address, phone, website, rating, reviews_count, categories, hours, coordinates, and platform_id (Apple's MUID, stable and worth keeping for later lookups). claimed: false means Apple states the listing has never been claimed in Apple Business Connect — report that as a finding, it is usually more actionable than any NAP mismatch. claimed: null means Apple said nothing about claim state; report it as unknown and never as claimed, because Apple only ever reports the unclaimed case. Ratings are normalized to a 5-point scale (Apple mixes 5-point and 100-point scales internally). data_source names who Apple credits for the record ("yelp", "foursquare"; empty when Apple credits no one) — when it is non-empty the record was ingested from that provider rather than supplied by the owner, so website often points at the provider's page and must NOT be reported as a NAP mismatch against the client's domain. A 502 mentioning results outside the requested location means Apple applied the location inconsistently and answered from elsewhere; retry once, and if it persists say Apple Maps data is unavailable for that city right now — never substitute a nearby city's rankings. Costs 3 credits.

Input Schema

Name	Required	Description
`sort`	No	Result ordering. Default: default (best match)
`limit`	No	Results to return. Default: 20
`keyword`	Yes	Search keyword (e.g. "plumber")
`location`	Yes	City and state (e.g. "Orchard Park, NY")

Output Schema

Name	Required	Description	Default
`keyword`	Yes
`results`	Yes
`location`	Yes
`platform`	Yes
`total_results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.0Oct 22, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely valuable operational context (3 credits cost, 502 retry policy, claimed-state semantics, rating normalization, data_source caveats), but much of that is really about interpreting return values rather than how the tool behaves as a call. Solid but not exceptional behavioral disclosure.

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 trigger are front-loaded and every section is information-dense, but the single dense paragraph runs long and some field-by-field detail could be trimmed. Efficient rather than tight.

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?

An output schema exists, yet the description still anticipates the tricky interpretation cases an agent will hit: claimed:false vs claimed:null, provider-ingested records vs owner data, mixed rating scales, and the location-scoped 502. Given the tool's interpretive complexity, the coverage is complete.

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 100% with four documented parameters, so the schema does the heavy lifting. The description mentions location behavior only indirectly, via the warning not to substitute a nearby city, and says nothing about sort or limit; the baseline 3 applies.

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 and resource: 'Checks how businesses rank on Apple Maps for a keyword.' It explicitly contrasts with the Google-oriented sibling local_pack, so an agent can distinguish it from maps, local_pack, and bing_local without opening a 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?

Gives explicit trigger conditions (Apple Maps, Siri, Apple Business Connect, iPhone visibility) and names the alternative that does not cover them (Google local_pack). It also supplies operational guidance for the 502 partial-location failure, including retry once and never substituting a nearby city.

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