Skip to main content
Glama

SignalPipe

by io.github.AbYousef739
OverviewDiscussionsAdmin

preview_station

Check whether a feed has buyers for a product BEFORE adding it as a station.

Which communities you listen to decides results more than any setting, and
a feed full of people talking about your topic can still contain no one
asking to buy. This reads the feed, scores its fresh posts and has the panel
judge the best-matching ones (default 8, one judgement each). Nothing is
saved.

Pass `rss_url`, or `entries` (up to 50 {link, title, summary, author,
published}) that you fetched yourself. Feeds read on the operator's own
machine (read_by: client) must be sent as entries.

Returns a verdict fixed by pre-set thresholds: VIABLE (worth adding),
MARGINAL (a trickle), ON-TOPIC, NOT IN-MARKET (topic talk, no buyers: a
different community will do better), NO BUYERS, or NO DATA (nothing could
be judged; the explanation says why, such as an empty or stale feed or
keywords that blocked every post). Plus a sample of judged posts, each kept
or rejected with the judges' stances.

Presentation: lead with the verdict and its one-line explanation, then how
many of the judged posts were kept. Only suggest add_station for VIABLE or
MARGINAL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sampleNoHow many of the best-matching posts the panel judges, 1 to 12 (default 8). Each costs one judgement.
entriesNoPosts you fetched yourself, up to 50, each {link, title, summary, author, published}. Required for feeds read on the operator's machine (read_by: client).
rss_urlNoThe feed URL to read. Pass this or entries.
product_idYesThe product to check the feed for, from get_products.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / entries / description
      Added value: +"Posts you fetched yourself, up to 50, each {link, title, summary, author, published}. Required for feeds read on the operator's machine (read_by: client)."
    • addedInput schema / properties / product_id / description
      Added value: +"The product to check the feed for, from get_products."
    • addedInput schema / properties / rss_url / description
      Added value: +"The feed URL to read. Pass this or entries."
    • addedInput schema / properties / sample / description
      Added value: +"How many of the best-matching posts the panel judges, 1 to 12 (default 8). Each costs one judgement."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it describes the internal process (reads feed, scores fresh posts, panel judges best-matching), the cost model (each judgement, default 8), the fixed verdict thresholds, and NO DATA failure modes. The 'Nothing is saved' statement plus the judgement consumption also explains the non-readOnly hint.

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-loads the purpose in the first line, then covers inputs, returns, and presentation. It is fairly long, but the length is justified by the tool's complexity and every sentence carries information; minor tightening is possible.

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 compensates fully by enumerating the possible verdicts and describing the returned sample of kept/rejected posts plus how to present the result. Nothing an agent needs to call or interpret this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description mostly restates what the schema already documents (default 8, 1-12 range, entries up to 50, rss_url or entries). Baseline 3 applies when the schema does the heavy lifting and the description adds only marginal detail.

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 ('Check whether a feed has buyers for a product') and frames the scope against a named sibling ('BEFORE adding it as a station'). An agent can immediately distinguish this from add_station 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?

Explicit when-to-use (before adding a station) and when-not (only suggest add_station for VIABLE or MARGINAL). It also routes between the two input modes, noting that feeds read on the operator's machine (read_by: client) must be sent as entries.

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

All SignalPipe 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