Skip to main content
Glama

map_marketplace_attribute

DestructiveIdempotent

Set where ONE of a marketplace's output attributes gets its value — the write half of solving the attribute form. Use this to fill or change one marketplace output attribute. Target the output attribute by code (from get_marketplace_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_marketplace_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 sales channel still needs a re-export/submit — call repair_marketplace or submit_all_marketplace_items afterwards (auto-pilot marketplaces re-export on their next sync). Map only attributes returned by get_marketplace_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' | 'rejected' (reason: unknown_attribute 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. | 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_marketplace_category_attributes first (they then appear in get_marketplace_attributes). marketplace_id is from list_marketplaces. 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": {
      "marketplace_id": "<marketplace_id>",
      "code": "<code>"
    },
    "name": "map_marketplace_attribute"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes
rule_idNo
constantNo
project_idNo
rule_enabledNo
platform_codeNo
marketplace_idYes
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 supplied annotations, the description discloses the important mutation semantics: it overwrites the stored override, detaches an attached rule when a source is set, rebuilds the feed immediately, and still requires a separate re-export/submit to reach the sales channel. It also lists rejection reasons and the returned fields, which is substantial behavioral context for a destructive write tool.

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 front-loaded with a clear first sentence, but the rest is a dense run-on with parentheticals, repeated rule explanations, and awkward punctuation around the status/reason list. Most content is relevant, but the structure makes it harder to scan than it should be for a complex tool.

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 nine-parameter destructive mutation tool with no output schema, the description is highly complete: it explains prerequisites, source/rule exclusivity, side effects, rebuild behavior, follow-up actions, rejection reasons, and the shape of the response. An agent has enough context to invoke it correctly and interpret the outcome.

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?

Schema coverage is 0%, so the description carries the full burden and does so well: code identifies the output attribute, platform_code and constant define primary sources, default_platform_code/default_constant define fallbacks, rule_id and rule_enabled control rule attachment, marketplace_id comes from list_marketplaces, and project_id is optional and inferred for single-project customers. It also explains the special empty-string and rule_enabled-only semantics.

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 specific verb and resource: setting where one marketplace output attribute gets its value, explicitly framed as the write half of the attribute-form workflow. It clearly distinguishes this operation from reading attributes via get_marketplace_attributes and from marketplace-level source/rule configuration.

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 when-to-use guidance, prerequisites, and alternatives: target attributes from get_marketplace_attributes, source attributes from list_source_attributes, rules from list_rules/create_rule, and category attributes only after refresh_marketplace_category_attributes. It also warns to confirm identifier fill rates before mapping identifier attributes and explains that repair_marketplace or submit_all_marketplace_items is needed after saving.

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