Inspect authorized website tracking, compare consent observations, and get remediation guidance.
Scored across 6 tools
The two inspection tools are clearly split by mechanism (inspect_runtime_consent runs isolated browser sessions vs inspect_site_tracking does a static non-JS GET), and the analysis tools split between comparison of two snapshots and grading of a single observation set. The only mild overlap is that compare_consent_observations and interpret_consent_evidence both perform phase-by-phase analysis of supplied evidence, though their inputs and outputs differ enough to be distinguishable.
All six names follow a snake_case verb_noun pattern (compare_, export_, get_, inspect_, inspect_, interpret_) with no style mixing. Minor deviation: the domain qualifier is placed inconsistently (inspect_runtime_consent vs inspect_site_tracking, which drops 'consent'), but the verb-first convention remains predictable.
Six tools is well within the ideal range and each maps to a distinct step in a coherent pipeline: static recon, runtime observation, comparison, interpretation, remediation lookup, and reporting. No tool appears redundant or filler.
The surface covers the full read-only lifecycle of consent/tracker evidence — gather (static and runtime), interpret, compare, look up remediation, export — which fits a deliberately stateless, no-storage server. The main gap is scope: both inspection tools are limited to a domain's homepage, with no way to target subpages or batch multiple domains, which an agent may need for real audits.
Compares two supplied RegSentry runtime snapshots of the same domain, phase by phase. Marks missing controls and incomplete observations unresolved. Reports newly observed or no-longer-observed tracker attempts without claiming causation, compliance or a verified fix. Stores nothing and makes no network requests.
| Name | Required | Description | Default |
|---|---|---|---|
| current | Yes | ||
| baseline | Yes |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| changes | Yes | |
| currentAt | Yes | |
| baselineAt | Yes | |
| comparable | Yes | |
| conclusion | Yes | |
| unresolved | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description reinforces this with 'stores nothing and makes no network requests' while adding genuinely new behavioral context: missing controls and incomplete observations are marked unresolved, and the output explicitly declines to claim causation, compliance, or a verified fix. That epistemic framing is not derivable from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what is compared, followed by resolution rules and then the explicit non-claims. No filler and nothing restated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and rich annotations, the description need only cover inputs and stance, which it largely does. It stops short of stating what happens if the two snapshots differ in domain or method, or how unresolved phases surface, but the core is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load. It contributes the same-domain constraint and the phase-by-phase comparison model, but leaves baseline-vs-current ordering, the const method/observationWindowMs values, and the required phase triple unexplained beyond the structural schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('compares two supplied RegSentry runtime snapshots of the same domain, phase by phase'), including the important qualifier that the snapshots are supplied rather than fetched, which separates it from the inspection siblings. It never names an alternative tool outright, so an agent must infer that inspect_runtime_consent produces the inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'two supplied ... of the same domain' phrasing implies the precondition (both inputs must be captured from the same domain) but does not say when to reach for this instead of interpret_consent_evidence or export_consent_report. Usage is inferable from the comparison framing rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Formats a supplied RegSentry runtime snapshot as a private plain-text report with its date, method, phase results and limitations. Returns file content without publishing, sharing, or storing it. Does not turn supplied evidence into a compliance certificate or legal opinion.
| Name | Required | Description | Default |
|---|---|---|---|
| snapshot | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| filename | Yes | |
| mimeType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts: output is private plain text, the file content is returned without publishing, sharing, or storing, and the report is explicitly not a compliance certificate — meaningful expectations-setting beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: what it produces first, then the negative guarantees. Every clause carries information and nothing is repeated from the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is not needed, and the description still tells the agent the result is file content rather than a stored artifact. The remaining gap is input provenance and validation — it never says where a valid snapshot comes from (e.g. inspect_runtime_consent) or that the schema enforces a rigid three-phase, fixed-method shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there is one deeply nested required parameter, so the description must compensate. It partially does by naming the snapshot fields the report surfaces (date, method, phase results, limitations), but says nothing about the const method value, the exactly-three-phases constraint, the 2000ms window, or enum statuses — details the agent must dig out of the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Formats a supplied RegSentry runtime snapshot as a private plain-text report') and enumerates what the report contains (date, method, phase results, limitations). It implicitly separates itself from interpretation-style siblings via the disclaimer about not producing a certificate or legal opinion, but never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'supplied ... snapshot' tells the agent it must already hold a snapshot, and the negative clauses rule out certification/legal-opinion use cases. There is no explicit 'use this instead of interpret_consent_evidence when...' routing, nor a pointer to which sibling produces the snapshot input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns deterministic, tracker-specific consent-gating guidance from RegSentry's maintained playbooks. It does not change a website, contact a vendor, or verify that a fix was implemented.
| Name | Required | Description | Default |
|---|---|---|---|
| tracker | Yes |
| Name | Required | Description |
|---|---|---|
| risk | Yes | |
| steps | Yes | |
| docsUrl | No | |
| snippet | No | |
| tracker | Yes | |
| loadedVia | Yes | |
| disclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the description adds useful context by stating the guidance is deterministic and sourced from maintained playbooks. It also explicitly clarifies that the tool does not change a website, contact a vendor, or verify a fix, which goes beyond the annotations and prevents false assumptions about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core behavior before stating limitations. Every sentence earns its place by defining both what the tool returns and what it explicitly does not do.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only, single-parameter lookup with a rich annotation set and an output schema, the description covers the essential behavior and safety boundaries. The remaining gaps are mainly the input semantics for 'tracker' and explicit sibling routing, which are less critical given the output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, 'tracker', but schema description coverage is 0%, so the schema provides only type and pattern constraints. The description says 'tracker-specific' but does not explain expected naming format, matching behavior, case sensitivity, or what happens with an unknown tracker, leaving the parameter semantics substantially undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Returns', and a specific resource, tracker-specific consent-gating guidance from maintained playbooks. It clearly frames the tool as advisory rather than an inspection, export, or mutation tool, though it does not explicitly name or differentiate from any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent should call this when it needs remediation guidance for a known tracker. However, the description gives no explicit when-to-use guidance, no prerequisites, and no alternatives among the sibling tools such as inspect_site_tracking or interpret_consent_evidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visits an authorized public homepage in three isolated browser sessions and records known tracker request attempts before consent and after exact reject-all or accept-all buttons. Uses temporary browser sessions, blocks non-GET requests, supplies no user credentials, and reports missing controls and incomplete runs. Page scripts and consent controls may make public GET requests, which can have remote effects. Bounded observations are not proof of transmission, compliance or a violation.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| authorizationAcknowledged | Yes |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| method | Yes | |
| phases | Yes | |
| observedAt | Yes | |
| limitations | Yes | |
| observationWindowMs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses temporary browser sessions, blocking of non-GET requests, no user credentials, reporting of missing controls and incomplete runs, possible remote effects from public GET requests, and the limitation that observations are not proof of transmission or compliance. These details materially expand the agent's understanding of the tool's behavior and risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core behavior and then adds only high-value operational and limitation details. Every sentence contributes to correct invocation or interpretation, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the annotations, and the presence of an output schema, the description is complete enough for an agent to understand what the tool does and its key caveats. Return-value details are correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It reinforces that the domain is an authorized public homepage, but it does not explain domain format or clarify the required authorizationAcknowledged boolean, leaving meaningful schema interpretation to the parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 visits an authorized public homepage in three isolated browser sessions and records tracker request attempts before and after consent actions. The runtime consent observation scope is concrete enough to distinguish it from sibling tools such as compare_consent_observations and interpret_consent_evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear operational context: an authorized public homepage, three isolated sessions, and exact reject-all or accept-all buttons. It does not explicitly name when to prefer this tool over siblings or when not to use it, so it falls short of full when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| Name | Required | Description |
|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Deterministically grades a redacted set of tracker-request observations by consent phase. It computes from the supplied data only, stores nothing, and returns a technical—not legal—interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| observations | Yes | ||
| consentBannerPresent | Yes |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| summary | Yes | |
| disclaimer | Yes | |
| evidenceGrade | Yes | |
| unresolvedTrackers | Yes | |
| observedAfterReject | Yes | |
| recommendedNextStep | Yes | |
| observedBeforeConsent | Yes | |
| typedValueTransmissionObserved | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the bar is lower; the description still adds real value by disclosing determinism, that it computes only from supplied data, that it stores nothing, and that output is a technical rather than legal interpretation. It does not describe how observations are weighted or what an ambiguous/unknown phase does, but the persistence and safety profile is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with three tight clauses; every clause (deterministic, supplied-data-only, technical-not-legal) carries information the agent cannot get from structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values and the annotations cover safety, but the grading criteria themselves are opaque — the description never indicates what inputs drive an adverse finding or how "unknown" phase observations are treated. Adequate to call the tool, thin for interpreting its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load, and it only gestures at "observations by consent phase." It never explains the phase enum values (before_consent, after_reject, after_accept, unknown), the role of consentBannerPresent, what "redacted" implies about the domain field, or how typedValueTransmitted affects the grade.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ("grades") and a specific resource ("redacted set of tracker-request observations by consent phase"), so an agent can tell it apart from the sibling compare_consent_observations. It stops short of explicitly naming the sibling or stating the precise output of the grade, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus inspect_runtime_consent, inspect_site_tracking, or compare_consent_observations, and no prerequisites or exclusions. The clause "technical—not legal—interpretation" hints at scope but is a disclaimer rather than usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_consent_observationsexport_consent_reportinspect_runtime_consentinspect_site_tracking3 fields changedOutput schema / properties / trackers / items / descriptionAdded value: +"A static HTML tracker reference; runtime firing and violations are not established."Output schema / properties / trackers / items / properties / violatingRemoved value: -{
- "type": "boolean"
-}Output schema / properties / trackers / items / requiredPrevious value: -[
- "name",
- "category",
- "violating"
-]New value: +[
+ "name",
+ "category"
+]get_remediation_playbookinspect_site_trackinginterpret_consent_evidenceCookie consent scanner: GDPR, CCPA, GCMv2. PASS/FAIL compliance checklists with fix recommendations.
EU cookie-consent & tracker audit, run like a real first-time visitor (EU proxies). Free quick check, no account. Finds trackers and tracking cookies before consent, missing first-layer Reject, what still fires after Reject, Google Consent Mode v2 state per signal, plus Google Fonts/YouTube/Maps/reCAPTCHA. Every finding comes with the exact request as evidence and a concrete fix, in 13 languages. Weekly monitoring, white-label PDF for agencies, private share links. Works with any CMP (Cookiebot, Usercentrics, Complianz, CookieYes, Borlabs…).
Check what a site's cookie banner really blocks: CMP, trackers, cookies before consent.
Cookie consent for GDPR/CCPA: scan sites for trackers, configure consent banners, get install code.
Add one secure layer between your agents and this server.
