Skip to main content
Glama

set_ai_source

Destructive

AI SOURCE (CSV-joined enrichment) — store per-product values that YOU (the client's own model) extracted, as a new 'AI source' attribute — so a feed rule can read the attribute directly without matching free text with contains/conditions. Use this to store values your own model extracted per product. Typical flow: call preview_products to read products, derive ONE value per product with your own reasoning (e.g. the color, gender, or material from the title/description), then call this with values as a JSON OBJECT (not an array) mapping each product's id (the id field from preview_products) to the extracted value. code is the new attribute name (e.g. "ai_color"); once applied it becomes the source attribute custom_ (visible in list_source_attributes). Send large catalogs in BATCHES: first batch mode:"replace", following batches mode:"append". This only STORES the values; after the LAST batch call run_ai_source_import so they land on products (an ASYNCHRONOUS import). VERIFY before using it: poll get_import_status until the newest additional_source run in recentRuns has running:false and status 'ok', and the code appears in list_source_attributes; only THEN attach the attribute to a feed with map_feed_attribute. If that run errors, run_ai_source_import retries without re-sending the values. handle overrides the product key to join on (default header.id, which matches the preview_products id). project_id is OPTIONAL (inferred for a single-project customer). If this feature is not included in this Koongo account, the call is refused with error 'addon_required' (HTTP 403); tell the user it is not available for this account and do not retry. Returns {status:'written', code, url, valueCount, applied:false}. The default mode replace OVERWRITES every stored value of the source.

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": {
      "code": "<code>",
      "values": "<values>"
    },
    "name": "set_ai_source"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes
modeNo
handleNo
valuesYes
project_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / apply
      Removed value: -{
      -  "type": "boolean"
      -}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description explains precisely why: default mode replace OVERWRITES every stored value of the source. It adds further behavior beyond the annotations — asynchronous import, retry-without-resending on error, the 403 addon_required refusal, and the return shape with applied:false.

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 nearly every sentence carries operational information. It is a single dense block with heavy backticking and capitalization, which slightly hurts scanability and makes the ordering constraint on batches easy to miss.

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 destructive five-parameter write tool with nested values, no schema descriptions, and no output schema, the description covers prerequisites, sequencing, verification, error handling, and return shape. An agent has everything needed to invoke 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 description coverage is 0%, so the description must compensate, and it does: `code` becomes source attribute custom_<code>, `values` must be a JSON object (not an array) keyed by preview_products `id`, `handle` overrides the join key (default header.id), `project_id` is optional and inferred, and `mode` controls replace vs append per batch.

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: store per-product values extracted by the client's own model as a new 'AI source' attribute. It also distinguishes itself from the free-text `contains` approach and implicitly from `run_ai_source_import`, which only lands the values on products.

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?

Gives an explicit end-to-end flow: preview_products → derive one value per product → call this → run_ai_source_import → poll get_import_status → map_feed_attribute. It also states batch sequencing (first batch replace, later batches append) and tells the agent not to retry on `addon_required`.

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