mcp-server

set_api_source

Destructive

API SOURCE (written to the data store) — store per-product values that YOU (the client's own model) computed, as a new 'API source' attribute — written straight into the project's data store (no CSV, no join handle) — so a feed rule can read the attribute directly without matching free text with contains/conditions. Use this to store values computed per product as a new attribute. It fits whenever a rule would otherwise need a long or complex condition tree. 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 computed value. Values keep their JSON type — send a NUMBER for a numeric attribute (so numeric rule operators work), a boolean, or a string; a null clears that product. code is the new attribute name (e.g. "ai_color"); once applied it becomes the source attribute api_source. (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_api_source_import so they land on products (an ASYNCHRONOUS import). VERIFY before using it: poll get_import_status until the newest api_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 or reference api_source. in a rule (create_rule / update_rule). If that run errors, run_api_source_import retries without re-sending the values. code must not collide with an existing source attribute of another class. 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, valueCount, applied:false}. mode=replace clears the attribute on every product; a null value clears it on one.

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_api_source"
  }
}

Input Schema

Name	Required	Description	Default
`code`	Yes
`mode`	No
`values`	Yes
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026
- removedInput schema / properties / apply
```
Removed value: -{
-  "type": "boolean"
-}
```
First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations, which only say destructive/not read-only: it discloses that mode=replace wipes the attribute on every product, null clears a single product, values are stored but not applied until an async run_api_source_import, batches must be replace-then-append, code cannot collide with another class, and the 403 addon_required refusal. It even states the return shape ({status:'written', code, valueCount, applied:false}). Only minor gap is no explicit note on idempotency/replay behavior given idempotentHint=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?

Front-loads the core purpose and workflow, which is right for a multi-step tool, but the em-dash pile-up and a few restatements ('Use this to store values computed per product as a new attribute' repeats the opener) make it a dense wall of text that could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, multi-step, async workflow tool with no output schema, it supplies the return shape, verification loop via get_import_status/list_source_attributes, batch protocol, and error handling. Complete enough to call correctly, though a worked example of `values` shape would remove the last ambiguity.

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%, and the description compensates fully: `code` is the new attribute name that becomes api_source.<code> with a collision constraint, `values` must be a JSON object (not array) keyed by preview_products ids with types preserved and null clearing, `mode` replace vs append batching semantics, and project_id being optional and inferred for single-project accounts.

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: writing per-product computed values as a new 'API source' attribute directly into the data store. It explicitly distinguishes itself from the alternative (no CSV, no join handle, no `contains` matching) and from the AI-source sibling by naming the flow around api_source.<code>.

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 explicit when-to-use criteria ('whenever a rule would otherwise need a long or complex condition tree'), a step-by-step typical flow (preview_products → derive → set_api_source → run_api_source_import → verify → map_feed_attribute/create_rule), and when-not behavior on addon_required errors with an instruction not to retry.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?