OnPage.dev

Local SEO

local

Read-onlyIdempotent

Local search: the site, the Business Profile and the map. Pick with mode: check = LocalBusiness markup, NAP, locations and the Business Profile (default). Needs url. reviews = Reply drafts for Google reviews, unhappy ones first, for the user's GBP connector after approval. Needs reviews[{rating, author, text, date, replied, review_id}]. demand = Business Profile search terms and geo-grid ranks into new service and location pages.

Input Schema

Name	Required	Description
`url`	No	The home page, a location page or the locations overview page.
`city`	No	Main city, left out when matching terms to pages.
`grid`	No	Optional geo-grid rankings.
`mode`	No	Default check.
`pages`	No	The site's page URLs, e.g.
`terms`	No	Search terms from the Business Profile performance report.
`detail`	No	brief = short summary.
`contact`	No	Where unhappy customers can reach you, e.g.
`reviews`	No
`business`	No	Business name to sign with.
`memory_key`	No	site_memory key, records this call.
`gbp_profile`	No	Optional: the Google Business Profile of this location, from the user's GBP connector or typed by the user, to compare with the site.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

removedOutput schema / description

Removed value: -"The result as structured data; fields depend on mode."

Changed2 schema fields changedOct 13, 2026

changedInput schema / properties / detail / description

Previous value: -"brief returns a short summary, default full."New value: +"brief = short summary."

changedInput schema / properties / memory_key / description

Previous value: -"Optional site_memory key, to record this call in the site memory."New value: +"site_memory key, records this call."

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / detail

Added value: +{
+  "description": "brief returns a short summary, default full.",
+  "enum": [
+    "full",
+    "brief"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / memory_key

Added value: +{
+  "description": "Optional site_memory key, to record this call in the site memory.",
+  "maxLength": 80,
+  "type": "string"
+}

AddedOct 12, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower. The description adds real behavioral context beyond them: reviews mode only produces reply drafts routed to the user's GBP connector 'after approval', unhappy reviews are handled first, and GBP profile data is used only for comparison. No contradiction with the readOnly hint.

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-loaded with the domain, then three tight mode clauses each stating purpose and required input. Dense but every clause carries routing information. Slightly compressed notation (e.g. 'Needs reviews[{...}]') costs a little readability.

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

Completeness4/5

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

For a 12-parameter multi-mode tool with an output schema (so return values need not be explained), the description covers all three modes and their key inputs and side effects. It leaves secondary parameters (city, grid, terms, detail, contact, memory_key) unexplained, but those are documented in the schema at 92% coverage.

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 description coverage is 92%, so the baseline is 3, but the description adds value the schema cannot: it maps which inputs each mode requires (url for check, the reviews[] array for reviews) even though every top-level parameter is formally optional (required: 0). That per-mode requirement linkage is genuine added semantics.

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?

The description names a concrete domain (local search: site, Business Profile, map) and decomposes it into three clearly labeled modes with distinct outputs, so an agent can tell what the tool produces. The bare name 'local' is weak, but the description compensates. It differentiates internally by mode rather than from siblings like schema or entity, so it stops just short of 5.

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 explicit mode selection with defaults and prerequisites ('check... (default). Needs url', 'reviews... Needs reviews[...]', 'demand = ...'). That is strong within-tool routing. It does not name when to avoid the tool or which sibling (schema, entity, track_rankings) to prefer instead, so it is clear context without exclusions.

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

All OnPage.dev tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.