Skip to main content
Glama

FeedShine: Shopify Google Shopping Feed

Override one product's attributes

set_product_override
DestructiveIdempotent

Set one product's attribute overrides and/or include state, for every feed (omit feedId) or for one feed. Overrides replace mapped attribute values on every item of the product, and a feed's own override wins over the store-wide one per attribute. An empty string sends nothing for that attribute, and omitting one the product already has returns it to its mapped value. The map you send REPLACES the product's whole override map, so send every attribute you want kept. The preview lists the ones it would drop under removes, and current shows what is stored today. This tool previews by default: called without confirm, it returns the proposed change and applies NOTHING. Show the merchant the proposal, then call again with confirm: true to apply.

Input Schema

NameRequiredDescriptionDefault
feedIdNoFeed id from list_feeds. Omit to write the override every feed inherits.
confirmNoOmit or false to preview. True applies the change.
includedNoInclude this product. Omit to keep its current state.
overridesNoFull replacement override map for this product (max 50 attributes). Include every attribute that should stay, since anything left out goes back to its mapped value.
productIdYesProduct id from list_products

Output Schema

NameRequiredDescriptionDefault
feedNoThe feed's id and name, on a feed-scoped call
noteNoPlain-language result or next step, safe to read out to the merchant.
scopeNoWhich override layer the call addressed: one feed's row, or the row every feed inherits
errorsNoReasons the save was refused
appliedNoTrue when the change was saved
currentNoThe row this call replaces, as stored before the call
previewNoTrue when this call only proposed the change
productNoThe product's id and title
removesNoAttributes overridden today that this call drops, because the map replaces the stored one
settingNoThe saved override row, on the confirm call
proposedNoOverrides this call would store, or stored
effectiveNoWhat the feed emits today after merging the store-wide and feed rows, when they differ
overriddenByNoOn a store-wide call, the feeds holding their own row for this product. Their values win over this write.
validationErrorsNoProblems that must be fixed before confirming

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: the sent map REPLACES the entire override map (send every attribute you want kept), empty string sends nothing, omitting an existing attribute reverts it to mapped value, and a feed-level override wins over the store-wide one per attribute. It also discloses the preview-by-default safety behavior, which is not expressible via the destructiveHint/idempotentHint annotations alone.

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?

Scoping is front-loaded and every sentence carries operational weight, with the confirm workflow placed last as the closing action. It is dense but slightly long; the destructive replacement warning is repeated in spirit across two clauses.

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?

With an output schema present, the description need not detail return values, yet it still tells the agent what the preview contains ('removes' and 'current'). Combined with the replacement, precedence, and confirm semantics, an agent has everything needed to call this correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuinely new semantics: empty-string behavior, the per-attribute feed-vs-store precedence rule, and the fact that omitted attributes revert rather than persist. These are not spelled out in the schema.

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 ('Set one product's attribute overrides and/or include state') and immediately scopes it by feed ('for every feed (omit feedId) or for one feed'). The singular 'one product' framing cleanly distinguishes it from the plural sibling set_product_overrides and set_products_included.

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?

Gives explicit operational workflow: previews by default, show the merchant the proposal, then re-call with confirm:true. It does not, however, name sibling alternatives (e.g. bulk set_product_overrides) or state when to prefer this tool over them, so routing relies on inference from 'one product'.

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