Skip to main content
Glama
Sign In

AnalyticsProof

by com.analyticsproof
OverviewDiscussionsAdmin

Approve a dataLayer diff into the journey baseline

approve_datalayer_diff
Destructive

Approve a dataLayer diff into the journey baseline (permission: edit)

Fold a single unresolved diff into the frozen expected schema and resolve its open regression. The STORED scan_diffs value is used (the body carries no value). When the diff contradicts scan history and confirmed is not set, responds 409 confirmation_required (error.meta { supporting, total }) instead of approving; retry with confirmed:true to override. Approving a missing event or param removes it from the expected schema; while an element it covers is marked as an error (an open regression at that step) it responds 409 with error code open_regression instead. mode: required (default) makes an added event/param required and removes a missing one from the expected state; optional records it as may-or-may-not-occur.

id is the scan's journeyId; take scanId, stepIndex, elementKey and diffType from a diff of get_scan with include diffs. To approve every diff of a scan use approve_all_datalayer_diffs; to stop reporting an element on every step use ignore_datalayer_element.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "scanId": "<scanId>",
      "stepIndex": "<stepIndex>",
      "elementKey": "<elementKey>",
      "diffType": "<diffType>"
    },
    "name": "approve_datalayer_diff"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesJourney id: from GET /journeys or the POST /journeys answer.
modeNoPresence diffs only (missing/extra event or param): required (default) or optional.required
scanIdYesThe scan whose diff is approved.
diffTypeYesThe diff's diffType; only these types can be approved: missing_event, extra_event, missing_param, extra_param, param_type_changed, event_drifted, consent_value_changed.
confirmedNoApprove even when the diff contradicts scan history (after 409 confirmation_required).
stepIndexYesZero-based journey step of the diff.
elementKeyYesThe diff's elementKey, from GET /scans/{id}?include=diffs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / confirmed / description
      Added value: +"Approve even when the diff contradicts scan history (after 409 confirmation_required)."
    • addedInput schema / properties / diffType / description
      Added value: +"The diff's diffType; only these types can be approved: missing_event, extra_event, missing_param, extra_param, param_type_changed, event_drifted, consent_value_changed."
    • addedInput schema / properties / elementKey / description
      Added value: +"The diff's elementKey, from GET /scans/{id}?include=diffs."
    • addedInput schema / properties / id / description
      Added value: +"Journey id: from GET /journeys or the POST /journeys answer."
    • addedInput schema / properties / mode / description
      Added value: +"Presence diffs only (missing/extra event or param): required (default) or optional."
    • addedInput schema / properties / scanId / description
      Added value: +"The scan whose diff is approved."
    • addedInput schema / properties / stepIndex / description
      Added value: +"Zero-based journey step of the diff."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far beyond the annotations, it discloses that the STORED scan_diffs value is used and the body carries no value, plus two distinct 409 paths: confirmation_required with error.meta { supporting, total } overridable via confirmed:true, and open_regression while a covered element is in error. It also spells out the destructive consequence ('approving a missing event or param removes it from the expected schema'), consistent with destructiveHint=true.

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?

The opening sentence front-loads purpose and permission, then failure modes, then sourcing and alternatives. A few sentences are long and pack conditional clauses, but every sentence carries actionable content with no filler.

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

Completeness5/5

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

For a non-idempotent, destructive mutation with seven params and no output schema, the description covers preconditions, required inputs, both conflict responses and their recovery, the state consequences, and the sibling alternatives. An agent has everything needed to call it correctly and handle its failure paths.

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, but the description adds real meaning: `mode` is explained as making an added event/param required vs. recording it as may-or-may-not-occur, `confirmed` gains a concrete retry-after-409 protocol, and `id` is clarified operationally as the scan's journeyId. The remaining params (scanId, stepIndex, elementKey, diffType) are largely restated from the schema.

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 precise verb and resource ('Approve a dataLayer diff into the journey baseline') and immediately scopes it to 'a single unresolved diff', which cleanly separates it from approve_all_datalayer_diffs. It also names the after-effect on state ('fold into the frozen expected schema and resolve its open regression').

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?

It explicitly routes the agent: use approve_all_datalayer_diffs to approve every diff of a scan, and ignore_datalayer_element to stop reporting an element on every step. It also tells the agent where the ids come from (a diff of get_scan with include diffs), so no inference is required.

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

All AnalyticsProof toolsInspect
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