Skip to main content
Glama

set_category_mapping

DestructiveIdempotent

Map store categories to marketplace/taxonomy categories. Use this to save store-to-target category mappings. Address the taxonomy by feed_id OR explicitly by taxonomy_code (+ optional taxonomy_locale). rules is a list of {store_category_ids:[...], target_hash} — each maps those store categories (ids from list_store_categories / list_unmapped_categories) to one target (hash from search_target_categories); a store category already mapped is re-pointed to the new target. The rule set is SHARED per project+taxonomy+locale, so if OTHER feeds use this taxonomy the call returns status=mapping_exists_requires_confirm (HTTP 409) with affectedFeedIds — re-call with confirm:true to apply. SAVE-ONLY: persists but does NOT regenerate — call export_feed afterwards. Returns {taxonomyCode, taxonomyLocale, status, rulesWritten, reason, affectedFeedIds}; status is 'updated' | 'no_changes' | 'mapping_exists_requires_confirm' | 'rejected' (reason: no_taxonomy | unknown_target | unknown_store_category | empty_rules). project_id is OPTIONAL (inferred for a single-project customer).

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": {
      "rules": "<rules>"
    },
    "name": "set_category_mapping"
  }
}

Input Schema

NameRequiredDescriptionDefault
rulesYes
confirmNoSet true to apply when other feeds share this taxonomy (status=mapping_exists_requires_confirm); default false.
feed_idNo
project_idNo
taxonomy_codeNoTarget taxonomy id (e.g. 'google'); alternative to feed_id for addressing the taxonomy.
taxonomy_localeNoLocale of the taxonomy tree, e.g. 'en_GB' — defaults to the taxonomy's own default when omitted.

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 declare write and destructive behavior, and the description adds well beyond them: an existing mapping is re-pointed, the rule set is shared per project+taxonomy+locale, other feeds trigger a 409 with affectedFeedIds, and nothing is regenerated until export_feed runs. It also enumerates every return status and rejection reason, which no structured field provides.

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?

Front-loaded with the action and the addressing modes, then flows into fan-out/confirm behavior and return shape. It is dense with parentheticals and status enumerations, but nearly every clause carries operational information; a little formatting would aid scanning.

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, yet the description documents the return object's fields and the meaning of each status, including rejected reasons. Combined with the destructive/idempotent semantics and next-step guidance, an agent has everything needed to call it correctly.

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 50%, but the description compensates fully: rules item shape {store_category_ids, target_hash} is given semantic meaning (which tools supply each value), feed_id vs taxonomy_code addressability is clarified, taxonomy_locale defaulting is explained, confirm is tied to the 409 flow, and project_id is identified as optional/inferred.

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: map store categories to marketplace/taxonomy categories, and to save store-to-target mappings. It distinguishes itself from the sibling reader get_category_mapping by emphasizing the write, and spells out the two addressing modes (feed_id or taxonomy_code + taxonomy_locale).

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?

Explains when to use it and what to do next: SAVE-ONLY, so call export_feed afterwards. It also names the source tools for inputs (list_store_categories / list_unmapped_categories for ids, search_target_categories for target_hash) and describes the confirm:true re-call flow when a 409 mapping_exists_requires_confirm is returned.

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