mcp-server

get_feed_output

Read-onlyIdempotent

Read the CURRENT output of a feed's already-generated file WITHOUT regenerating it — so it works on a read-only connection (unlike export_feed, which regenerates the file and is a write action). Use this to see what a feed currently contains: its live download URL, product count and a sample of the actual rows, without downloading the file and counting it yourself. Inputs: feed_id (the feed's id from list_feeds / create_feed), project_id (OPTIONAL — inferred for a single-project customer; project_id_required if they have several, then call list_projects), sample_size (default 20, max 20), offset (default 0 — skip this many rows to read a deeper page; page by increasing offset in steps of sample_size). Returns {feedId, projectId, feedCode, fileFormat, feedUrl, fileExists, fileSize, productsCount, lastGeneratedAt, sampleRowCount, sample:[{field: value}, ...]}. feedUrl is the public download URL of the current file; productsCount is exactly the number of rows in that file; lastGeneratedAt is when it was last generated. fileExists:false means the feed has not been generated yet — call export_feed, then poll get_feed_status until it is generated. The sample rows are real feed data returned only after you set acknowledge_sensitive:true. The first call (flag absent/false) returns {sensitiveGate:{confirmationRequired:true, itemCount, fields, kind}} with sample EMPTY (all the metadata is still returned) — present that gate to the USER, get approval, then re-call with acknowledge_sensitive:true to receive the rows.

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

Input Schema

Name	Required	Description
`offset`	No	Skip this many rows to read a deeper page of the feed; page by increasing offset in steps of sample_size (default 0).
`feed_id`	Yes
`project_id`	No
`sample_size`	No	How many feed rows to return in the sample (default 20, max 20).
`acknowledge_sensitive`	No	Set true only AFTER the user approves seeing real data. When absent/false the tool returns a sensitive gate with an empty sample (metadata still included); with true it returns the actual rows.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes beyond them by explaining the read-only-connection constraint, the fileExists:false recovery flow, and the authenticate-then-confirm sensitive-data gate with its exact two-phase return shape. The only gap is that paging bounds (offset max 5000) and behavior at the sample_size/offset boundary are left to the schema.

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 the core distinction before any detail, and every paragraph carries decision-relevant information. Slight redundancy: the sample_size default/max and offset paging are stated in the description and again in the schema, and the return-shape enumeration is dense, though it is justified given there is no output schema.

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 five-parameter tool with no output schema, the description covers inputs, the full return payload, the sensitive-gate protocol, and the not-yet-generated recovery path. Remaining gaps (which fields appear in the gate's `fields`, behavior when offset exceeds row count) are minor.

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 60%, so the description has to compensate, and it does: it explains the provenance of feed_id (from list_feeds/create_feed), that project_id is optional and inferred for single-project customers but may raise project_id_required, and the paging idiom of stepping offset by sample_size. acknowledge_sensitive is described with its consequence (empty sample vs. real rows), far beyond the schema text.

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 ("Read the CURRENT output of a feed's already-generated file WITHOUT regenerating it") and immediately names the sibling it is not (export_feed). An agent can distinguish this from export_feed, get_feed, and get_feed_status without opening any 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 explicit when-to-use (inspect live URL, product count, sample rows without downloading), an explicit when-not/alternative (export_feed regenerates and is a write action), and a recovery path: on fileExists:false call export_feed then poll get_feed_status. Also names list_projects as the fix when project_id is ambiguous.

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?