Skip to main content
Glama

get_marketplace_attributes

Read-onlyIdempotent

List a marketplace's OUTPUT attributes and how each is currently sourced — the tool for SOLVING THE ATTRIBUTE FORM (the discipline users struggle with). Use this to find required marketplace attributes that are still unmapped. Returns {integrationId, attributes:[{code, label, required, hidden, valueSource, platformCode, constant, composedValue, defaultPlatformCode, defaultConstant, allowedValues, formatType, ruleId, ruleName, ruleEnabled, priceAttribute, currency, currencyConversionEnabled, configured, stepField}], requiredCount, requiredUnmappedCount, unresolvedCodes}. valueSource is rule|composed|attribute|constant|unmapped (the effective source; a rule attached but ruleEnabled=false does NOT count and the attribute reads 'unmapped'). priceAttribute=true marks a money attribute (formatType price / price_with_delete); for those, currency is its target currency and currencyConversionEnabled whether Koongo converts the value into it (null = not a price attribute). Currency conversion only matters when the price is in a DIFFERENT currency than the store; if the attribute's name already names a currency (e.g. its label/code contains "EUR") the value is ALREADY in that currency, so set currencyConversionEnabled=false to avoid converting it twice. requiredUnmappedCount is the running count of REQUIRED attributes with no working source — 0 means the form is solved and the integration can build/export; unresolvedCodes lists exactly which ones to fix. Pass only_unresolved:true to get just those rows. To fill one, match the user's attribute label to its code, then map_marketplace_attribute. Each row also says WHERE its value comes from: configured=true is a mapping of the customer's own, stepField names a wizard form step field that drives it (change it there with configure_marketplace_step — mapping it here writes an override that beats the step for good), and neither means the value is only the channel definition's default. A default is not a decision: check it against the store's data before trusting it. marketplace_id is from list_marketplaces. project_id is OPTIONAL (project_id_required otherwise — then call list_projects). IF categoryAttributeWarmup IS PRESENT WITH pending:true THIS LIST IS INCOMPLETE: the channel's category-specific attributes are still downloading, so requiredUnmappedCount and unresolvedCodes are PROVISIONAL — a required attribute that is not in the list yet cannot be counted as unmapped, so the form can look solved when it is not. Poll marketplace_status until the block is absent or state is 'ready', then read this again before mapping.

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>"
    },
    "name": "get_marketplace_attributes"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idNo
marketplace_idYes
only_unresolvedNoReturn only REQUIRED attributes that still have no working value source.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare a safe, read-only, idempotent read, and the description still adds substantial behavior: how valueSource resolves (rule with ruleEnabled=false collapses to unmapped), price-only fields and currency conversion double-counting risk, the precedence of overrides over wizard step fields, and the categoryAttributeWarmup pending caveat that makes counts provisional. That warmup warning is the kind of state-dependent caveat annotations can never express.

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?

Purpose is front-loaded and the ordering moves from what-it-does to return shape to how to act on it. It is dense and heavily emphasized with ALL-CAPS, and the currency-conversion paragraph is long enough to slow scanning, but nearly every sentence carries operational information rather than 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?

No output schema exists, so the description documents the return shape (attribute rows, requiredCount, requiredUnmappedCount, unresolvedCodes) and what each notable field means. The warmup/pending caveat and the follow-up tool chain close the remaining gaps for a moderately complex read tool.

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 only 33%, so the description must compensate, and it does: only_unresolved is explained as 'just those rows', marketplace_id is sourced from list_marketplaces, and project_id is flagged optional with the project_id_required fallback. Each of the three parameters gains meaning the schema does not carry.

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?

States a specific verb and resource ('List a marketplace's OUTPUT attributes and how each is currently sourced') and frames the goal ('solving the attribute form'). The OUTPUT/attribute-form framing plus the marketplace-vs-ad distinction lets an agent separate it from siblings like get_ad_attributes and get_attribute_options.

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?

Explicit when-to-use ('find required marketplace attributes that are still unmapped'), explicit next steps (map_marketplace_attribute for a single fill, configure_marketplace_step for step-driven fields, marketplace_status polling during warmup), and prerequisite routing (list_marketplaces for marketplace_id, list_projects when project_id_required). Alternatives and exclusions are named rather than implied.

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