mcp-server

get_feed

Read-only

Get the full detail of one feed: identity + state + the attribute mapping (how each output column is sourced). Returns {feedId, projectId, feedCode, name, feedType, fileFormat, channelCode, status, enabled, taxonomyCode, taxonomyLocale, feedUrl, exportOutOfStock, attributeCount, requiredUnmappedCount, attributes:[{code, label, platformCode, constant, composedValue, required, hidden, valueSource, defaultPlatformCode, defaultConstant, allowedValues, formatType, ruleId, ruleName, ruleEnabled, priceAttribute, currency, currencyConversionEnabled}]}. hidden=true means the attribute is internal and must NEVER be mapped or surfaced in output; valueSource is rule|composed|attribute|constant|unmapped; allowedValues is the closed value set (empty = open). ruleId/ruleName/ruleEnabled describe an attached Attribute Rule (null when none); valueSource is 'rule' only when the rule is ENABLED — an attribute with ruleId set but ruleEnabled=false has a rule attached-but-disabled that does NOT drive its value (it reads as its other source, or 'unmapped'), so surface it and offer to enable it. priceAttribute=true marks a money attribute (formatType price / price_with_delete); currency is its target currency and currencyConversionEnabled whether Koongo converts the value into it (null = not a price attribute) — only relevant when the price is in a DIFFERENT currency than the store; if the attribute's name already names a currency (label/code contains "EUR") the value is ALREADY in it, so set currencyConversionEnabled=false to avoid double conversion. requiredUnmappedCount is how many REQUIRED attributes still have no working source (valueSource='unmapped'); 0 means the attribute form is solved and the feed can export. Map source attributes with map_feed_attribute (see list_source_attributes). The response also includes settings (the feed's channel output settings): currency/number-format (read-only here) plus stock {stockInValue, stockOutValue, stockAvailabilityAttribute} and shipping {shippingDependentAttribute, shippingMethodName, shippingIntervals:[{from,to,cost}]} — the stock and shipping settings are EDITABLE via set_feed_settings. feed_id is the id from list_feeds / create_feed. project_id is OPTIONAL (inferred for a single-project customer; project_id_required otherwise — then call list_projects). A soft-deleted feed returns error 'feed_deleted' (not 'not_found') — the id is still valid and the feed can be brought back with restore_feed; it just won't appear in list_feeds while deleted. Use get_feed for configuration/mapping and get_feed_status for run progress. Requires the project's data imported (dataStatus='ok', see get_import_status).

Input Schema

TableJSON Schema

Name	Required	Description
`feed_id`	Yes
`project_id`	No
`response_format`	No	Verbosity of the returned feed. 'full' (default) includes the complete attribute mapping; 'compact' asks for identity + state only (omit the attributes list) to save context when you just need the feed's status/config.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description's behavior aligns with that. It adds substantial behavioral context beyond annotations: soft-deleted feeds return 'feed_deleted' rather than 'not_found', hidden attributes must never be mapped, ruleEnabled=false means a rule is attached-but-disabled and does not drive the value, and currencyConversionEnabled should be set false to avoid double conversion when the value is already in the target currency. This gives an agent real insight into subtle edge cases.

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?

The description is long, but it is dense with necessary edge-case information and every sentence earns its place. It is front-loaded with the core purpose and return shape before diving into semantic caveats. It could be better organized with bullets, but the single-paragraph structure is acceptable given the complexity.

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 no output schema, the description must fully explain the return values and behavior, and it does so thoroughly: it enumerates the return fields, explains the attribute mapping semantics, notes editable settings, describes the soft-delete error path, identifies sibling tools for follow-up actions, and states prerequisites. Nothing critical appears missing for an agent to correctly invoke and interpret this tool.

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 only 33%, so the description carries most of the parameter burden. It explains that feed_id comes from list_feeds/create_feed and that project_id is optional/inferred for single-project customers or required otherwise, with a pointer to list_projects. The response_format parameter is already well described in the schema with an enum and default, so the description doesn't need to repeat it.

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?

The description opens with a specific verb and resource: 'Get the full detail of one feed: identity + state + the attribute mapping'. It then lists the exact shape of the return object, making the tool's responsibility unambiguous. It also differentiates itself from get_feed_status by explicitly scoping this tool to configuration/mapping rather than run progress.

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?

The description gives explicit routing guidance: 'Use get_feed for configuration/mapping and get_feed_status for run progress.' It also explains when project_id is required and to call list_projects, and mentions the prerequisite that the project's data must be imported (dataStatus='ok', see get_import_status). These are concrete, actionable conditions for correct invocation.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Tools are organized around distinct resources (ads, marketplaces, feeds, orders, rules, sources) with clear action verbs, and descriptions explicitly disambiguate near-pairs like get_feed_status vs ad_status or set_feed_filter vs set_feed_attribute_filter. A few similarly named status/action pairs (e.g. ad_status vs get_ad, run_ad_item_action vs run_ad_operation) require careful reading, but overall the purposes are separable.

Naming Consistency4/5

The overwhelming majority follow a consistent verb_noun snake_case pattern (list_*, get_*, create_*, set_*, run_*, test_*). Minor deviations like ad_status and marketplace_status (noun-based status tools) and koongo_knowledge break the pattern slightly, but the convention is clearly recognizable and predictable.

Tool Count1/5

At 105 tools, the surface is extreme and far beyond the 50+ threshold, even for a complex e-commerce integration domain. Much of the bloat comes from systematic triplication across ads, marketplaces, and feeds (e.g. three nearly identical map_*_attribute tools, three list_*_items, three get_*_report) that a generic resource parameter could have consolidated.

Completeness4/5

The toolset covers the full lifecycle of feeds, ads, marketplaces, order connections, rules, and imports, including create/read/update/delete, status monitoring, item-level actions, validation, repair, and restore. Minor gaps exist, such as no delete for standalone order connections and limited update capabilities for some entities, but these are workable and do not create dead ends for the core workflows.

Resources

Need Help?