Skip to main content
Glama
Sign In

mcp-server

by com.koongo
OverviewDiscussionsAdmin

get_feed

Read-onlyIdempotent

Get the full detail of one feed: identity + state + the attribute mapping (how each output column is sourced). Use this to read a feed's configuration and attribute mapping. 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).

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>"
    },
    "name": "get_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
feed_idYes
project_idNo
response_formatNoVerbosity 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnly/idempotent/non-destructive; the description adds substantial behavior beyond that — the exact soft-delete error contract and recoverability, the meaning of hidden=true, the valueSource enum, and the surprising ruleEnabled=false case where a rule is attached but does not drive the value. It also flags a real trap (double currency conversion when the attribute name already encodes the currency) that no annotation or schema could convey.

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?

The purpose sentence is front-loaded and every sentence carries real information, but the body is a single dense block that dumps the entire response shape field-by-field and then buries the usage rules (siblings, prerequisites, soft-delete) mid-paragraph. Splitting into short labeled sections or moving the attribute-field enumeration to a second paragraph would cost nothing and improve scanability.

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?

There is no output schema, so the description must carry the return contract itself, and it does — enumerating top-level fields, the nested attributes array, and the settings object including stock and shipping sub-structures. For a read tool requiring an imported project and with a non-obvious soft-delete state, the agent has everything needed to call it and interpret the result.

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 33%: feed_id and project_id have no schema text, and the description compensates by stating feed_id comes from list_feeds/create_feed and that project_id is optional and inferred for single-project customers (yielding project_id_required otherwise). response_format is left to the schema, which already documents it well. Only a minor gap remains — nothing about how feed_id behaves if it belongs to another project.

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?

Opens with a specific verb and resource ('Get the full detail of one feed') and enumerates the three things returned: identity, state, and the attribute mapping. It explicitly separates itself from the nearest sibling ('Use get_feed for configuration/mapping and get_feed_status for run progress'), so an agent can choose between them without reading either schema.

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 concrete when-to-use routing (get_feed for configuration, get_feed_status for run progress), names the follow-up tools (map_feed_attribute, list_source_attributes, set_feed_settings, restore_feed, list_projects), and states a prerequisite (project data imported, dataStatus='ok', see get_import_status). It also handles the ambiguous cases: project_id inference vs. project_id_required, and a soft-deleted feed returning 'feed_deleted' rather than 'not_found'.

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

All mcp-server toolsInspect
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