Local SEO Data

Official

Overview Schema Source Related Servers Discussions(1)Admin

history_search

Read-only

Search past API calls by endpoint, date, keyword, location, business or domain to see what was already paid for and avoid buying the same data twice.

Instructions

Finds calls this account has already made, with what was asked and what it cost. Free (0 credits).

USE THIS BEFORE BUYING DATA AGAIN. Every response this API has returned is kept, so "has this changed since last month?", "what did we see last time?" and "did we already check this?" are answerable from what has been paid for once. Running the original endpoint again to answer them charges full price for a second copy.

Filter by endpoint, by date range, and by what was asked: keyword, location, business_name and domain match the parameters of the original call, so "every AI Mode call for this keyword" is one search. Note that a sandbox key sees only sandbox calls, and if the account turned response logging off then params were not stored either and these filters find nothing. Values match exactly, not as substrings — "best plumber" and "best plumber near me" are different questions and are not merged.

Returns entries with request_id, endpoint, params, credits_used, status_code and created_at, newest first, but NOT the response bodies — they are large and a search is for finding the call. Pass a request_id to history_get for the answer itself.

Building a trend: search for the calls, then history_get each one. A month of daily AI Mode calls is 30 cheap reads instead of 30 paid ones.

Input Schema

Name	Required	Description
`to`	No	Latest date, ISO.
`from`	No	Earliest date, ISO (e.g. "2026-08-01").
`page`	No	Page number, from 1.
`sort`	No	Default created_at.
`limit`	No	Entries per page, max 100. Default 25.
`order`	No	Default desc, newest first.
`domain`	No	Exact domain the original call was made with.
`status`	No	Only successful calls, or only failed ones.
`keyword`	No	Exact keyword the original call was made with.
`endpoint`	No	Endpoint path, matched as a substring (e.g. "/v1/serp/ai-mode" or just "ai-").
`location`	No	Exact location the original call was made with.
`business_name`	No	Exact business_name the original call was made with.

Output Schema

Name	Required	Description	Default
`page`	Yes
`limit`	Yes
`pages`	Yes
`total`	Yes
`entries`	Yes
`total_is_exact`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.0Oct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, non-destructive, closed-world, so the description correctly spends its words elsewhere: zero-credit cost, full response retention, the sandbox-key scoping caveat, the logging-disabled caveat that silently empties all param filters, and the fact that response bodies are deliberately excluded. These are exactly the behavioral traps an agent could otherwise fall into.

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?

Front-loads the cost-saving instruction before any mechanics, and each paragraph covers a distinct concern (why, filters, return shape, composition). It runs long for a search tool and the 'did we already check this?' example list is slightly padded, but nothing is genuinely wasted.

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?

For a 12-parameter search tool with an output schema, the description supplies the pieces structured data cannot: free-vs-paid framing, retention guarantees, account-state caveats, matching semantics, and the request_id handoff to history_get. Nothing an agent needs in order to call it correctly 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; the description earns above that by explaining the conceptual semantics — filters match the parameters of the original call, values match exactly rather than as substrings ('best plumber' ≠ 'best plumber near me'), and endpoint is the one substring field. It doesn't touch from/to, sort, order, page or limit, but the schema handles those.

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 ('finds calls this account has already made') and immediately scopes it to request history rather than response bodies, explicitly routing to history_get for the payload. An agent can distinguish it from the dozens of live-endpoint siblings 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 an explicit imperative ('USE THIS BEFORE BUYING DATA AGAIN'), names the concrete question shapes it answers, states the cost consequence of the alternative (re-running the original endpoint charges full price), and names the complementary tool (history_get) with the exact composition pattern. Both when-to-use and when-not-to-use are covered.

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