Skip to main content
Glama

map_ad_attribute

DestructiveIdempotent

Set where ONE of an ad's output attributes gets its value — the write half of solving the attribute form. Use this to fill or change one ad output attribute. Target the output attribute by code (from get_ad_attributes). Set platform_code to a source attribute (from list_source_attributes) to map it, and/or constant for a fixed value; default_platform_code / default_constant are the fallback used when the primary source is empty. For an IDENTIFIER (sku, gtin/ean/barcode, mpn), first confirm the chosen source is actually populated across the catalog (get_project_profile eanFillRate; page preview_products) — mapping or requiring an identifier the products lack yields an empty, non-functional integration. rule_id attaches an Attribute Rule (from list_rules / create_rule) — the value is then computed by that rule; send rule_id:"" to detach it, and rule_enabled:false to attach it disabled. To re-enable an attached-but-disabled rule, send rule_enabled:true (with or without its rule_id, from get_ad_attributes). rule_enabled on its own applies to whatever rule is already attached; with none attached it is rejected as unknown_rule. Provide at least one field (send an empty string to clear a text field). rule_id together with platform_code/constant in the same call is contradictory and is rejected. Setting a source (platform_code/constant) on an attribute that currently has a rule DETACHES that rule (mutually exclusive; changed then includes rule_id). SAVE + REBUILD: the mapping is written to the integration and its built feed is rebuilt immediately, but reaching the ad platform still needs a re-export/submit — call repair_ad or submit_all_ad_items afterwards (auto-pilot ads re-export on their next sync). Map only attributes returned by get_ad_attributes; hidden ones are internal and cannot be mapped by regular users. Returns {integrationId, code, status, changed:[...], reason, rebuilt, overridesStepField}; status is 'updated' | 'no_changes' | When the attribute was already driven by a wizard step field, the response says so in overridesStepField: the rewrite rule beats that step for good, so a later change in the step has no effect. If the step already sets the right source, change it there, not here. 'rejected' (reason: unknown_attribute | unknown_source_attribute | value_not_allowed | unknown_rule). Category-specific attributes are mapped here too, the same way — but they only exist after a category is mapped, so run refresh_ad_category_attributes first (they then appear in get_ad_attributes). ad_id is from list_ads. project_id is OPTIONAL (inferred for a single-project customer). OVERWRITES the stored override and detaches a rule attached to that attribute.

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": {
      "ad_id": "<ad_id>",
      "code": "<code>"
    },
    "name": "map_ad_attribute"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes
ad_idYes
rule_idNo
constantNo
project_idNo
rule_enabledNo
platform_codeNo
default_constantNo
default_platform_codeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructive and idempotency annotations, it discloses overwrite behavior, automatic rule detachment, contradictory-input rejection, immediate feed rebuilding, and the separate export step required to reach the ad platform. It also explains `no_changes`, rejection reasons, wizard-step precedence, and auto-pilot re-export behavior; none of this contradicts the annotations.

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 purpose is front-loaded and nearly all content is useful, but the definition is an excessively dense single paragraph with repeated overwrite and rule-detachment warnings. The return-status passage is also awkwardly interleaved with the wizard-step explanation, making an otherwise strong description harder to scan.

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 nine-parameter mutation with no documented schema properties or output schema, it covers prerequisites, parameter provenance, validation failures, rule interactions, response fields, and the rebuild/export lifecycle. Identifier-population checks, hidden attributes, category-specific attributes, and wizard overrides address important edge cases needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description successfully documents all nine parameters, including discovery sources for `code`, `ad_id`, and `platform_code`, fallback semantics, and optional `project_id` inference. It also explains empty-string clearing or detachment, `rule_enabled` state transitions, required operational fields, and mutually exclusive parameter combinations.

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 opening sentence precisely identifies the operation and scope: setting the value source for one ad output attribute. References to `get_ad_attributes` and ad-specific category behavior further distinguish it from the feed and marketplace mapping siblings.

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 gives explicit selection and sequencing guidance, including when to use constants, sources, or rules, when to refresh category attributes, and when to call `repair_ad` or `submit_all_ad_items` afterward. It also supplies exclusions and alternatives, such as changing a wizard step instead when that step already sets the correct source.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources