Skip to main content
Glama
localseodata

Local SEO Data

Official

ai_sample_status

Read-only

Poll an AI sample job to track pending, running, complete, or failed status and retrieve per-business AI visibility metrics and individual run results when done.

Instructions

Collects the answer to an ai_sample job. FREE — poll as often as you need.

Returns status "pending" or "running" with progress and total_steps while the samples are still going, "complete" with the full distribution once they are done, and "failed" with an error if the job died (a failed job is refunded in full). Typical completion is 30-60 seconds, tail around 130.

WHAT COMES BACK: per business — appearances, appearance_rate, shortlist_rate, mean_rank, mean_shortlist_rank, best_rank, worst_rank, top_pick_count and runs_seen — plus every individual run.

TWO DIFFERENT RANKINGS, DO NOT MERGE THEM. businesses in a run is the platform's LISTING, in the order it emitted cards. recommended_businesses is the SHORTLIST read out of the answer's own prose, in the order the answer argued for it — that is the recommendation, and the two disagree routinely: a business the prose puts third can sit tenth in the listing. Report shortlist_rank when a client asks where an AI recommends them — it is null for a business the answer named in a sentence rather than listed, and those runs are counted in mention_appearances instead of shortlist_appearances. Each entry's mention quotes what the answer actually said. reader_version says which version of that reader produced the shortlist: it is our reading of the answer, not the platform's own listing, so before comparing this job with an older stored one confirm the versions match -- across a bump the numbers are not comparable and a reader improvement reads as a drop. mean_rank and best_rank are listing positions and are null for a business that was never in a listing.

GEMINI HAS NO LISTING AT ALL. It sends no structured business block, so businesses is empty in every gemini run and every gemini figure comes from the prose shortlist. An empty businesses array on gemini is not evidence that nobody was named.

READING THE RATES: every rate is out of samples_returned, which counts only runs that ANSWERED. A failed run and a refusal are both excluded — a run where the model said "I'm having a hard time fulfilling your request" is not a run where the client was absent. Check samples_refused: a high count means the platform is declining the prompt, not that the client is invisible, and per-run outcome says which runs those were. An answer that named nobody IS counted, because that is a real absence. mean_rank averages only the runs that named the business, so a business named 2nd in 3 of 10 runs reads mean_rank 2 and appearance_rate 0.3; do not collapse the two into one score.

cited_domains says which SOURCE the answers cited for each business and in how many runs, most-used first -- an answer sourcing a business from its BBB listing rather than its own site is telling you which page it treats as authoritative, and that is usually the finding a client wants. Note that domain and website on the same row hold a citation too, under names that read as the business's own site.

A business the answers spelled more than one way ("WNY Snow Removal" and "WNY Snow Removal LLC") is reported as ONE row, with every spelling in name_variants -- on gemini there is no cid behind a prose mention, so without that the same business reports two rows at half its real rate each. Only a legal form (LLC, Inc), a bare connector, or a tradeless corporate suffix (Service, Services, Company, Group, Solutions) merges; any word naming a different trade leaves the rows separate, as does a cid. A cited domain separates rows only when it looks like the business's own site -- a directory citation is not evidence of identity. Two rows can still be one business: where one name is the other plus a trade word and both carry the same own-site domain in cited_domains, that is usually one business split across spellings, and its real rate is the two rates added. The split is deliberate -- a chain's branches ("Smith Dental" and "Smith Dental Downtown") share a domain exactly the same way, and nothing in the answer says which case this is. Merging them is yours to decide with context about the business that we do not have; we leave the seam visible rather than guess, because a wrong merge cannot be undone from the payload.

matched_on says how runs were tied together: "cid" is Google's own identifier and is exact, "domain" is domain plus name, "name" is the string alone and is the weakest. Google labels AI Mode cards editorially, so on google_ai_mode prefer the cid.

BILLING: this poll costs nothing, so its credit line reads 0. What the job cost is credits_charged — the submit's reservation less the refund for samples that never completed. Refusals are NOT refunded: the prompt was run and the model answered, it just declined.

Input Schema

NameRequiredDescriptionDefault
job_idYesThe job_id ai_sample returned.

Output Schema

NameRequiredDescriptionDefault
runsNo
errorNo
job_idYes
statusYes
keywordNo
locationNo
platformNo
progressNo
businessesNo
total_stepsNo
completed_atNo
reader_versionNo
samples_failedNo
credits_chargedNo
samples_refusedNo
credits_refundedNo
credits_reservedNo
samples_returnedNo
samples_requestedNo
samples_unreadableNo
samples_shortlist_readNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, non-destructive, openWorld), and the description layers on non-obvious behavior: this poll costs 0 credits, credits_charged is the submit reservation minus refunds, refusals are not refunded, and failed jobs are refunded in full. It also discloses the returned statuses and their shapes, which no annotation conveys.

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?

Status semantics and the free-to-poll point are front-loaded, and section headers (WHAT COMES BACK, TWO DIFFERENT RANKINGS, GEMINI, READING THE RATES, BILLING) aid scanning. It is nonetheless very long for a single-parameter poll, and the name-merging discussion is a dense paragraph that could be tightened.

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?

Given the complexity of the payload — listing vs. shortlist rankings, gemini's missing listing, rates out of samples_returned, matched_on strength, name merging — the description supplies the interpretive guidance an output schema cannot. Nothing needed to read the result correctly is missing.

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?

Only one parameter and schema coverage is 100%, with the schema itself saying 'The job_id ai_sample returned.' The description adds no syntax or format detail beyond that, so the schema is doing all the work — baseline 3 for a fully covered 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?

States a specific verb and resource — 'Collects the answer to an ai_sample job' — and explicitly ties it to the sibling that creates the job. An agent can tell this is the status/result-fetch counterpart to ai_sample 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 Guidelines4/5

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

'FREE — poll as often as you need' plus the pending/running/complete/failed breakdown makes the polling usage pattern clear, and typical timing (30-60s, tail ~130) implies cadence. It stops short of naming alternatives (e.g. ai_llm_response or ai_visibility) or stating when NOT to call it, so no exclusions.

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