mcp-server

map_feed_attribute

DestructiveIdempotent

Set where one feed attribute's value comes from. Use this to change where a feed column gets its value. Target the output attribute by code (from get_feed). Set platform_code to a source attribute (from list_source_attributes) to map it, and/or constant for a fixed value; default_platform_code / default_constant are the fallback used when the primary source is empty. rule_id attaches a product rule (Attribute Rule, from list_rules / create_rule) — the attribute's value is then computed by that rule; send rule_id:"" to detach it (revert to platform_code/constant), and rule_enabled:false to attach it disabled. To re-enable an attached-but-disabled rule, send rule_enabled:true (with or without its rule_id, from get_feed). rule_enabled on its own applies to whatever rule is already attached; with none attached it is rejected as unknown_rule. Provide at least one field (send an empty string to clear a text field). rule_id together with platform_code/constant in the same call is contradictory and is rejected. Setting a source (platform_code/constant) on an attribute that currently has a rule DETACHES that rule (source and rule are mutually exclusive; changed then includes rule_id). SAVE-ONLY: persists the mapping and bumps the revision but does NOT regenerate the feed — call export_feed afterwards for the change to reach the output. Map only attributes returned by get_feed. Returns {feedId, code, status, changed:[...], reason, revisionBefore, revisionAfter}; status is 'updated' | 'no_changes' | 'rejected' (reason: unknown_attribute | unknown_source_attribute | value_not_allowed | unknown_rule). (rule_id together with platform_code/constant is a request-level invalid_request/400, not a 'rejected' reason.) project_id is OPTIONAL (inferred for a single-project customer). Attributes flagged hidden in get_feed are internal plumbing and cannot be mapped by regular users; skip them. PRECEDENCE: a feed value is resolved rule → composed → platform_code → constant (valueSource 'rule' is a Rule). If an attribute's valueSource (from get_feed) is 'composed', its value comes from a composed rule, so a platform_code/constant you set here is silently overridden — change composed values in the Koongo UI (the feed's editUrl). A 'rule' value source (a Rule), however, is settable here via rule_id. OVERWRITES the stored mapping and detaches a rule attached to that attribute.

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": {
      "feed_id": "<feed_id>",
      "code": "<code>"
    },
    "name": "map_feed_attribute"
  }
}

Input Schema

Name	Required	Description	Default
`code`	Yes
`feed_id`	Yes
`rule_id`	No
`constant`	No
`project_id`	No
`rule_enabled`	No
`platform_code`	No
`default_constant`	No
`default_platform_code`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses save-only semantics, that the stored mapping is overwritten, that setting a source detaches an attached rule, the resolution precedence (rule -> composed -> platform_code -> constant), and the full status/reason taxonomy including the request-level 400 case. All of this is consistent with destructiveHint=true and idempotentHint=true; nothing contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and information-dense, but delivered as one undifferentiated block of text with no structure. Several points are repeated: the rule_id/platform_code contradiction is stated twice, and the overwrite/detach behavior is asserted in the middle and again in the closing sentence.

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 9-parameter mutation tool with no output schema and no annotation detail, this covers returns ({feedId, code, status, changed, reason, revisionBefore/After}), failure reasons, side effects on rules, and the required follow-up call. An agent can invoke it correctly without consulting anything else.

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?

With 0% schema description coverage across 9 parameters, the description compensates fully: it explains code, platform_code, constant, both default_* fallbacks, rule_id (including rule_id:"" to detach), rule_enabled (attach-disabled, re-enable, standalone behavior, unknown_rule rejection), project_id optionality, and the mutual-exclusion rule between rule_id and platform_code/constant.

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 where one feed attribute's value comes from') and immediately clarifies the intent ('change where a feed column gets its value'). It also pins down the targeting key (`code` from get_feed), so an agent knows exactly what object it operates on.

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 about when and how to use it, and about paths it does not cover: composed-value attributes must be changed in the Koongo UI, hidden attributes must be skipped, and export_feed must be called afterwards because the tool is save-only. It also names the exact sibling/helper calls that supply its inputs (get_feed, list_source_attributes, list_rules).

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?