Adaga solutions — Data APIs Toolbox

local_presence_monitor

Monitor ONE local business over time: create a persistent baseline, then detect only new public Google reviews, rating changes, website AI-readiness regressions and meaningful score changes. Use when you need historical change detection and optional JSON webhook alerts for one known business. Use local_presence_audit instead for a one-off full audit; use review_radar instead when you only need new-review alerts without website monitoring. Auth: Apify API token required in Authorization: Bearer. Rate limits: 60 calls/min/IP on this facade; results capped at 100 items per call, no pagination. Side effect: when webhookUrl is set and dryRun is false, high-severity changes trigger an HTTPS JSON POST; dryRun never calls the webhook and skips Actor event charges, while Apify platform and proxy usage can still apply. Pricing: $0.25 per run + $0.25 per business monitored + $0.10 per delivered alert.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "local_presence_monitor"
  }
}

Input Schema

Name	Required	Description	Default
`query`	No	Optional business name and city used to find the Google Maps profile. Leave empty for website-only monitoring with no Google proxy usage.
`dryRun`	No	Run the full monitoring workflow but skip pay-per-event charges and webhook delivery. Apify compute and proxy usage can still apply.
`language`	No	Two-letter Google Maps interface language such as fr, en or de.	fr
`maxReviews`	No	Number of recent public Google reviews to compare with persistent state, from 1 to 30.
`webhookUrl`	No	Optional HTTPS endpoint receiving a JSON POST for high-severity changes. Never called during dryRun.
`websiteUrl`	No	Public website URL monitored for JSON-LD, metadata, llms.txt and AI-crawler robots.txt signals.	https://adagasolutions.lu
`proxyConfiguration`	No	Apify proxy used only when query is set. Datacenter is the low-cost default; RESIDENTIAL is optional and billed separately.
`scoreDropThreshold`	No	Create a high-severity alert when the presence score falls by at least this many points.
`ratingDropThreshold`	No	Create a high-severity alert when the public Google rating falls by at least this amount, for example 0.2 stars.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses auth (Apify Bearer token), rate limits (60 calls/min/IP), result capping at 100 items with no pagination, and a concrete side effect (HTTPS JSON POST fired on high-severity changes when webhookUrl set and dryRun false). It also explains the dryRun trade-off (skips Actor event charges and webhook delivery, but compute/proxy still bill) and gives full pricing breakdown.

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 core purpose and sibling routing before the auth/rate-limit/pricing block, and every sentence carries distinct operational information. It is dense and long, but the density is earned; only the pricing sentence edges toward detail an agent rarely needs at selection time.

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 9-parameter, stateful, webhook-firing tool with no output schema, the description covers selection, side effects, limits and cost thoroughly. The remaining gap is return shape: it never says what a run returns (baseline record vs. list of detected changes), which matters because no output schema exists to fill that in.

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 goes beyond it by documenting cross-parameter interactions the schema states only locally — empty query means website-only monitoring with no Google proxy usage, and the webhook only fires when webhookUrl is set and dryRun is false. It does not restate per-parameter ranges, which the schema already covers.

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 with scope: 'Monitor ONE local business over time', then enumerates exactly what is detected (new Google reviews, rating changes, website AI-readiness regressions, score changes). It explicitly contrasts itself with local_presence_audit and review_radar, so an agent can distinguish it from siblings 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 Guidelines5/5

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

Gives an explicit when-to-use clause ('historical change detection ... for one known business') plus two named alternatives with the exact condition that selects each: one-off audit → local_presence_audit, review-only alerts → review_radar. Exclusions are stated, not implied.

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

All Adaga solutions — Data APIs Toolbox tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?