SiteVerdict

Official

by siteverdict

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Audit tracking & cookie consent (GDPR / Consent Mode v2)

audit_tracking_consent

Read-only

Detect tracking tags and cookies firing before consent or after rejection, plus broken GA4/GTM tags and duplicate page views, to verify GDPR cookie compliance and diagnose inaccurate analytics data.

Instructions

Loads the site in a real browser three ways (no click, Reject, Accept all) and reports which tags fire before consent or after Reject, tracking cookies set without consent, Google Consent Mode v2 signals, broken GA4/GTM tags, duplicate page_views and missing conversions. Returns a score, prioritised plain-English fixes and a link to the full HTML report. Use for GDPR/UK GDPR/PECR/ePrivacy cookie compliance and "why is my analytics data wrong" questions. Runs on the caller's own Apify account (APIFY_TOKEN) and is billed by Apify pay-per-event; nothing is charged by this server.

Input Schema

Name	Required	Description	Default
`url`	Yes	Public website URL, e.g. "https://example.com" (https:// is added if missing). Private/internal addresses are rejected.
`locale`	No	Browser language, e.g. en-GB, de-DE, fr-FR (banners are often localised).	en-GB
`scanMode`	No	"full" = 3 visits (no click / Reject / Accept all). "quick" = 1 visit, cheaper: tag inventory, pre-consent tracking and broken tags only.	full
`waitSecs`	No	How long to wait for results before returning status "running" with a runId (the scan keeps going; use get_audit_results). Default 240.
`maxCostUsd`	No	Spend cap for this run on YOUR Apify account (forwarded to Apify as maxTotalChargeUsd). Default from server config ($2).
`timezoneId`	No	IANA time zone, e.g. Europe/London, Europe/Berlin, America/New_York.	Europe/London
`internalPages`	No	Extra internal pages to check per scenario (0 = home page only).

Output Schema

Name	Required	Description
`run`	Yes
`check`	Yes
`grade`	Yes
`score`	Yes
`dryRun`	Yes	true = sample data from the built-in mock, NOT a real scan
`status`	Yes	"running" = the Actor is still working; call get_audit_results with run.runId later
`target`	Yes
`metrics`	Yes
`summary`	Yes
`findings`	Yes
`reportUrl`	No	Full report (HTML/JSON) in the Apify key-value store
`datasetUrl`	No
`findingsTotal`	Yes
`severityCounts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Oct 29, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses that the scan runs in a real browser, uses three consent scenarios, returns a score/fixes/report link, requires the caller's APIFY_TOKEN, and is billed by Apify pay-per-event with no charge from this server. This adds important operational and cost context not captured by annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core behavior and then supplies outputs, use cases, and billing context without filler. Despite being information-dense, every sentence contributes to selecting or correctly invoking the tool.

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?

With annotations and an output schema available, the description covers purpose, use cases, external account requirements, and billing well. The main remaining gap is that async behavior and retrieval via get_audit_results are documented in the waitSecs schema field rather than the description, but the definition is still largely 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%, so the schema already documents all seven parameters in detail. The description reinforces the three-visit scenario behind full scan mode, but it does not add parameter-level meaning beyond the schema, such as guidance on maxCostUsd, waitSecs, locale, or internalPages.

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?

The description states a specific verb and resource: it loads a site in a real browser three ways and audits consent/tracking behavior. It distinguishes itself from generic website-audit siblings by naming concrete outputs such as pre-consent tags, cookies, Consent Mode v2 signals, GA4/GTM issues, duplicate page_views, and missing conversions.

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 clearly says to use this for GDPR/UK GDPR/PECR/ePrivacy cookie compliance and for questions about why analytics data is wrong. It does not explicitly compare against siblings like full_website_audit or check_ai_search_readiness, so there is no when-not/alternatives guidance, but the intended context is clear.

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

Deploy Server