Skip to main content
Glama
scottehastings16

Adobe Target MCP

by scottehastings16
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

generateDataLayerEvent

Generate ES5-compatible event tracking code for Adobe Target conversion elements. Supports multiple tag managers and configurable firing conditions to prevent duplicate conversions.

Instructions

Generate ES5-compatible event tracking code for Adobe Target activity conversions. Supports multiple tag managers with configurable event structures and firing conditions.

SUPPORTED TAG MANAGERS:

  • gtm: Google Tag Manager (dataLayer.push)

  • adobeLaunch: Adobe Experience Platform Tags (_satellite.track)

  • tealium: Tealium iQ (utag.link)

  • segment: Segment Analytics (analytics.track)

  • customDataLayer: Custom dataLayer implementation

USAGE: When creating or modifying Target experiences with conversion elements (buttons, links, forms), use this tool to generate click tracking code.

WORKFLOW:

  1. User creates an experience with a button/link/conversion element

  2. LLM identifies the conversion element selector

  3. LLM asks: "What should I name this activity?" (if not already provided)

  4. LLM asks: "What experience name should I use?" (e.g., "Experience A", "Control", "Variant B")

  5. TAG MANAGER SELECTION:

    • If full-page extraction was done earlier, check context for tagManagers.summary.recommendedForTracking

    • If tag manager was auto-detected, use that (inform user: "I detected {name} on the page")

    • If NOT detected or no full-page extraction in context, ask: "Which tag manager are you using?" (default: adobeLaunch)

  6. LLM MUST ASK: "When should this conversion event fire?" and present these options:

    1. Every time (no limit) - DEFAULT - Track every interaction 2. Once per session - Track only once per session (prevents duplicate conversions) 3. Once per page - Track only once per page load 4. Once ever - Track only once, stored permanently 5. Throttle - Limit frequency (e.g., max once per second) 6. Debounce - Wait for user to stop interacting

    Default is "always" (every time). User can override if needed.

  7. LLM calls this tool with selector, activity_name, experience_name, tag_manager (auto-detected or selected), and firing_condition

  8. Tool returns ES5-compatible click event listener code with firing condition logic

  9. LLM includes this code in the activity modifications

FIRING CONDITIONS:

  • always: No limit, fires every time - DEFAULT

  • once_per_session: Fires once per session (uses sessionStorage) - For preventing duplicate conversions

  • once_per_page: Fires once per page load (uses flag)

  • once_ever: Fires once ever (uses localStorage)

  • throttle: Limits frequency (requires interval parameter in ms)

  • debounce: Waits for user to stop (requires delay parameter in ms)

IMPORTANT:

  • ALWAYS ask about firing conditions - don't assume

  • Default is "always" (fires every time) - user can override if needed

  • Attach to ALL conversion elements (buttons, CTAs, forms, etc.)

  • Attach to the most specific selector possible

  • Attach to negative user actions aswell, like ignoring a popup or closing a modal

  • activity_name should match the Target activity name

  • experience_name should be descriptive (e.g., "Control", "Variant A", "Green Button Test")

  • Generated code is ES5-compatible (no template literals, arrow functions, const/let)

  • Code includes defensive check for element and tag manager object existence

  • NO polling/setInterval - Target fires after DOM ready, so elements should already exist

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
selectorYesCSS selector for the conversion element (button, link, etc.) - e.g., "#cta-button", ".at-signup-btn"
event_nameNoCustom event name (optional). If not provided, uses tag manager default (e.g., "target_conversion" for GTM, "target-conversion" for Adobe Launch)
event_typeNoType of DOM event to track (default: "click"). Can be "click", "submit", "change", etc.
tag_managerNoTag manager to use: "adobeLaunch" (Adobe Launch), "gtm" (Google Tag Manager), "tealium" (Tealium iQ), "segment" (Segment), or "customDataLayer" (Custom implementation). Default: "adobeLaunch"
activity_nameYesThe name of the Adobe Target activity (should match activity name in Target)
firing_paramsNoParameters for throttle/debounce conditions. For throttle: { interval: 1000 }. For debounce: { delay: 500 }. Values in milliseconds.
experience_nameYesThe experience name/variant (e.g., "Experience A", "Control", "Variant B", "Green Button")
firing_conditionNoWhen should the event fire? Options: "always" (every time - DEFAULT), "once_per_session" (prevents duplicate conversions), "once_per_page", "once_ever", "throttle", "debounce". Default: "always"
include_commentsNoInclude explanatory comments in the generated code (default: true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.5/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. It discloses important behavioral traits: output is ES5-compatible, code includes defensive checks, no polling/setInterval is used, firing conditions are configurable, and defaults are specified. This gives the agent a realistic expectation of the generated behavior and constraints.

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

Conciseness3/5

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

The description is well-structured with clear headings, but it is quite verbose and contains redundancy. Firing condition options are repeated in multiple sections, and the default 'always' is emphasized repeatedly. A more condensed version would retain clarity while removing repetition.

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 complex code-generation tool with 9 parameters and no output schema, the description is remarkably complete. It covers supported tag managers, workflow steps, firing condition options, required parameters, code constraints, and important edge-case guidance. An agent has enough context to invoke it correctly.

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 baseline is 3. The description adds meaningful context beyond the schema: how tag manager is selected, which parameters to pass in the workflow, firing condition semantics, and guidance like 'Attach to the most specific selector possible.' This enriches parameter understanding.

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 opens with a specific verb and resource: 'Generate ES5-compatible event tracking code for Adobe Target activity conversions.' It clearly distinguishes this tool from siblings like generatePreviewScript by focusing on conversion event tracking across multiple tag managers.

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?

The description provides explicit usage context: 'When creating or modifying Target experiences with conversion elements (buttons, links, forms), use this tool to generate click tracking code.' It also gives a detailed workflow for when to invoke the tool and what questions to ask. However, it does not explicitly mention alternatives or when not to use this tool.

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

Deploy Server

Other Tools