mcp-server

preview_products

Read-onlyIdempotent

Get a page of the project's imported products with their real source-attribute values, so you can inspect the data and advise on feed mapping (e.g. see that brand holds "Nike" or color holds hex codes). Use this to inspect real product values before mapping. Returns {products:[{id, type, attributes:{:}}], returned, requested, total, offset, hasMore, nextOffset}. attributes keys are source attribute codes (as in list_source_attributes); only catalogued, non-sensitive attributes are included — cost/margin and internal fields are never returned, and empty values are omitted. sample_size is the page window (default 5, max 100); page through the whole catalog with offset — when hasMore is true, re-call with offset=nextOffset until hasMore is false. project_id is OPTIONAL (inferred for a single-project customer). Data must be imported first (see get_import_status). This tool returns real product data values only after you set acknowledge_sensitive:true. The first call (flag absent/false) returns {sensitiveGate:{confirmationRequired:true, itemCount, fields, kind}} with an EMPTY products array — present that gate to the USER, get their approval, then re-call with acknowledge_sensitive:true to receive the actual values. To review the full generated feed output for every product (not just source attributes), use export_feed, not paging this preview — that is the intended bulk path. Pass attributes (source attribute codes) to return only those attributes, with values up to 20000 chars (otherwise 200); the response then also carries attributes, valueMaxLength and withheldAttributes. With attributes, sample_size x the number of attributes may be at most 100 (default sample_size 5 counts too), so long values cannot flood the conversation; to show a merchant full values keep sample_size <= 10. Next: pick a template (list_feed_templates) and map attributes (map_feed_attribute).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "preview_products"
  }
}

Input Schema

Name	Required	Description
`offset`	No	Number of products to skip (paging); pass the response's nextOffset to get the next page.
`attributes`	No	Only these source attribute codes; values are then returned up to 20000 chars (otherwise 200). sample_size x attributes must be <= 100.
`project_id`	No
`sample_size`	No	Page window: how many products to return per call (default 5, max 100).
`acknowledge_sensitive`	No	Set true only AFTER the user approves seeing real data. When absent/false the tool returns a sensitiveGate with an empty products array; with true it returns the actual attribute values.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / attributes

Added value: +{
+  "description": "Only these source attribute codes; values are then returned up to 20000 chars (otherwise 200). sample_size x attributes must be <= 100.",
+  "items": {
+    "maxLength": 64,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 20,
+  "minItems": 1,
+  "type": "array"
+}

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover read-only/idempotent safety; the description adds substantial extra behavior: the two-phase sensitive-data gate that returns an empty products array until acknowledge_sensitive is true, the redaction rule (cost/margin and internal fields never returned, empty values omitted), and the pagination termination condition via hasMore/nextOffset. None of this is inferable from 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.

Conciseness4/5

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

Front-loaded with purpose and the sibling disambiguation, then gates, then pagination, then next steps — a sensible order. It is dense and somewhat long, with a few items duplicated from the schema (sample_size default/max, 20000-char value cap), but almost every sentence carries operational weight.

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, and the description supplies the full return shape including the sensitiveGate envelope and the attributes/valueMaxLength/withheldAttributes variants. Given the confirmation gate and length caps, an agent has everything needed to call this correctly and safely.

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?

Adds real meaning beyond the 80%-covered schema: project_id is optional and inferred for single-project customers (the schema has no description for it), and the sample_size x attribute-count budget constraint plus the practical advice to keep sample_size <= 10 for full values. Some content merely restates schema text (default 5/max 100, 20000-char limit), which earns no credit.

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 ('get a page of the project's imported products with their real source-attribute values') and gives a concrete example of what that means (`brand` holds "Nike"). It also explicitly separates itself from the overlapping sibling export_feed, so an agent can choose without opening 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 when-to-use ('inspect real product values before mapping'), when-not-to-use with a named alternative ('for the full generated feed output use export_feed, not paging this preview'), and prerequisites ('data must be imported first, see get_import_status'). It even names the follow-on tools (list_feed_templates, map_feed_attribute).

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?