mcp-server

verify_feed_attributes

Read-onlyIdempotent

File-level check of a feed's attribute mapping (reads the generated feed file). Use this to check the exported attribute values after export_feed. 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 items to verify a deeper page of the feed; page by increasing offset in steps of sample_size). Returns deterministic findings against the generated feed file: missingSource (required attributes with no source in the config), emptyInOutput (required attributes empty in the sampled items), specViolations (values outside the channel's allowed set), plus the feed spec (required + allowedValues per attribute) and a sample of items {field: value}. After reading the deterministic findings, YOU do the semantic pass: over sample vs spec, judge whether open-ended values (titles, descriptions, urls, prices, categories) look correct/plausible for the channel, then summarise the problems and suggest concrete config fixes in the feed. status is ok | issues_found | file_missing (file_missing = the feed hasn't been generated yet). The sampled feed rows and violation values are real data returned only after you set acknowledge_sensitive:true. The first call (flag absent/false) returns {sensitiveGate:{confirmationRequired:true, itemCount, fields, kind}} with the sample rows / violation values EMPTY — present that gate to the USER, get their approval, then re-call with acknowledge_sensitive:true to receive the actual values. To fix findings: map_feed_attribute for each, then export_feed, then re-run this tool.

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": "verify_feed_attributes"
  }
}

Input Schema

Name	Required	Description
`offset`	No	Skip this many items to verify 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 items to sample and verify (default 20, max 20).
`response_format`	No	Verbosity of the result. 'full' (default) includes the sampled rows and the full spec; 'compact' asks for the findings + status only (omit sample and spec) to save context.
`acknowledge_sensitive`	No	Set true only AFTER the user approves seeing real data. When absent/false the tool returns a sensitiveGate with empty sample rows / violation values; with true it returns the actual values.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations cover read-only/idempotent safety, but the description adds substantially more: the two-phase sensitive-data gate (first call returns an empty sensitiveGate with itemCount/fields/kind, second call with acknowledge_sensitive:true returns real values), the status enum including file_missing meaning the feed hasn't been generated, and the split between deterministic findings and the agent's own semantic pass.

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, then inputs, then returns, then the fix workflow — a sensible order for a complex tool. It is long and repeats the sample_size max/default and the offset meaning that the schema already states, but almost every sentence carries operational information an agent cannot get from structured fields.

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 six parameters, no output schema, and a non-obvious confirmation handshake, the description supplies the return shape (missingSource, emptyInOutput, specViolations, spec, sample), the status values, and the gate flow — everything needed to call and interpret it correctly without trial and error.

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 67%, and the description compensates: project_id is explained as optional with inference for single-project customers and an explicit project_id_required fallback, offset is framed as a pagination cursor over sample_size steps, and acknowledge_sensitive is described with its exact return-value semantics. Only response_format is left entirely to the schema, which documents it well.

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?

"File-level check of a feed's attribute mapping (reads the generated feed file)" names a specific verb, resource, and scope, and immediately separates it from adjacent tools such as get_feed_output or get_feed_status by stating it validates the generated file rather than fetching config or status.

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?

It states explicitly when to use it ("after export_feed") and gives a full remediation chain: map_feed_attribute per finding, then export_feed, then re-run this tool. The error branch (project_id_required → call list_projects) is also routed, leaving nothing to inference.

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?