RegSentry Website Tracking Inspector

Inspect site tracking setup

inspect_site_tracking

Read-onlyIdempotent

Performs a bounded, non-persisting GET of an authorized public domain's homepage and reports tracker markup, consent setup signals, and runtime-verification gaps. It does not run JavaScript, submit forms, create a RegSentry record, or make a legal determination.

Input Schema

Name	Required	Description	Default
`domain`	Yes	Public domain only, such as example.com. Do not include a path or query.
`authorizationAcknowledged`	Yes	Must be true to confirm the user owns or is authorized to inspect this domain.

Output Schema

Name	Required	Description	Default
`scope`	Yes
`domain`	Yes
`trackers`	Yes
`disclaimer`	Yes
`httpStatus`	Yes
`limitations`	Yes
`finalHostname`	Yes
`consentSignals`	Yes
`dynamicLoaders`	Yes
`consentManagers`	Yes
`consentSetupState`	Yes
`runtimeVerificationRequired`	Yes
`trackersRequiringRuntimeVerification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 2, 2026

addedOutput schema / properties / trackers / items / description

Added value: +"A static HTML tracker reference; runtime firing and violations are not established."

removedOutput schema / properties / trackers / items / properties / violating
```
Removed value: -{
-  "type": "boolean"
-}
```

changedOutput schema / properties / trackers / items / required

Previous value: -[
-  "name",
-  "category",
-  "violating"
-]New value: +[
+  "name",
+  "category"
+]

First observedSep 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, but the description adds material behavior beyond that: the operation is 'non-persisting', limited to the homepage, requires an authorized public domain, performs no JavaScript execution or form submission, and deliberately makes no legal determination. These are the exact limits an agent needs before calling an open-world fetch.

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?

Two sentences, zero filler: the first front-loads what the tool does and reports, the second front-loads what it will not do. Every clause carries distinct information about scope or exclusions.

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 an output schema present and full parameter documentation, the description doesn't need to explain return values, and its scope/exclusion coverage is strong. The only loose end is 'bounded', which signals a fetch limit without stating it, leaving the agent unsure how large or slow a target page can be.

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 both `domain` and `authorizationAcknowledged` are already documented, establishing a baseline of 3. The description adds meaning by framing the target as an 'authorized public domain's homepage', reinforcing that `domain` is homepage-level and authorization-gated, which is slightly more than the schema states on its own.

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 names a specific verb and resource ('bounded, non-persisting GET of an authorized public domain's homepage') and enumerates the three outputs it reports: tracker markup, consent setup signals, and runtime-verification gaps. The explicit negations ('does not run JavaScript') carve out the boundary with the sibling inspect_runtime_consent, so an agent can distinguish the tools without opening the 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?

Usage scope is clearly implied by the 'does not run JavaScript, submit forms, create a RegSentry record, or make a legal determination' clause, which tells the agent when this tool is insufficient and that a runtime tool or record-creation path is needed instead. However, no sibling is named explicitly (e.g., 'use inspect_runtime_consent for JS execution'), so the routing is left to inference rather than stated.

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

All RegSentry Website Tracking Inspector tools Inspect

Try in Browser

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?