Skip to main content
Glama
scottehastings16

Adobe Target MCP

by scottehastings16
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

getMockupAnalysisInstructions

Fetch the current page structure for a given URL to compare with a mockup and generate experience modifications.

Instructions

Extract detailed page structure to prepare for mockup comparison and experience generation.

MOCKUP-TO-EXPERIENCE WORKFLOW: This tool is the FIRST STEP when a user provides a mockup/screenshot and wants to create an experience.

Workflow:

  1. User provides: mockup screenshot + target URL

  2. LLM calls THIS TOOL with the URL to get current page structure

  3. LLM analyzes mockup image (using vision) vs current page data

  4. LLM identifies differences (layout, colors, text, positioning, etc.)

  5. LLM generates ES5 modification code following ALL Adobe Target coding rules

  6. LLM shows user the proposed changes for approval

  7. LLM calls createActivityFromModifications to deploy

IMPORTANT INSTRUCTIONS FOR LLM: When user provides a mockup/screenshot:

  1. Ask user: "What's the URL of the page this mockup is for?"

  2. Ask user: "Do you have any links or image assets that need to be used in this experience?"

    • If user provides links/images: Use the exact URLs provided

    • If user says "no" or doesn't provide assets: Use placeholder links (e.g., "https://example.com/image.jpg" or "#")

  3. Call THIS TOOL with the URL

  4. Analyze the mockup screenshot carefully:

    • Identify visual differences from current page

    • Note layout changes, color changes, text changes, new elements

    • Look for CSS properties: colors, fonts, spacing, positioning

    • Identify which elements need modification (use specific selectors)

  5. Generate modification code that:

    • Follows ALL Adobe Target code generation rules (ES5 only, at- prefix, etc.)

    • Uses specific selectors (IDs, data attributes, NOT broad classes)

    • Waits for elements to exist before modifying

    • Is well-commented explaining each change

  6. Show user the generated code and explain the changes

  7. After approval, call createActivityFromModifications

KEY ANALYSIS POINTS:

  • Compare mockup colors vs current page colors

  • Compare mockup text vs current page text

  • Compare mockup layout/positioning vs current page

  • Identify new elements in mockup that need to be created

  • Identify hidden elements that need to be shown/hidden

  • Note font changes, size changes, spacing changes

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the page to analyze
focusAreaNoOptional: Specific section to focus on (e.g., "hero section", "navigation", "footer"). If not provided, analyzes entire page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.5/5.0
Behavior3/5

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

There are no annotations, so the description carries the full behavioral disclosure burden. It does say the tool 'get[s] current page structure' and is the 'FIRST STEP', implying a read-only extraction operation. However, it never explicitly states that the tool has no side effects, nor does it mention auth needs, rate limits, failure behavior, or the response format, leaving notable gaps.

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

Conciseness2/5

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

The description is excessively long and mixes tool semantics with a full LLM workflow guide. It repeats similar instructions in the workflow, the 'IMPORTANT INSTRUCTIONS FOR LLM' section, and the 'KEY ANALYSIS POINTS' section, and the numbered list even has two separate '4.' items. It is front-loaded with purpose but far from concise.

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

Completeness2/5

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

There is no output schema, so the description should clarify what the tool returns, yet it only says 'current page structure' without describing the actual shape or fields. While the workflow context is extensive, the description does not fully prepare an agent to interpret the tool's response, especially since focusArea behavior and error cases are unaddressed.

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?

The input schema already provides 100% parameter coverage with descriptions for both 'url' and 'focusArea', so the baseline is 3. The description only mentions calling the tool 'with the URL' and adds no extra meaning for either parameter; in particular, focusArea is never discussed in the description.

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 clear verb and object: 'Extract detailed page structure to prepare for mockup comparison and experience generation.' It also explicitly labels the tool as 'the FIRST STEP' in the mockup-to-experience workflow and distinguishes it from the deployment tool createActivityFromModifications, so an agent can tell what it is and is not for.

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 clearly states when to use the tool: when a user provides a mockup/screenshot and wants to create an experience. It gives a concrete workflow sequence, including asking for a URL before invoking the tool and only calling createActivityFromModifications after user approval. It lacks explicit 'do not use when...' alternatives, which prevents a 5, but the context is strong.

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