Skip to main content
Glama

SignalPipe

by io.github.AbYousef739
OverviewDiscussionsAdmin

reject_mission

Reject a mission — it was not a real buying signal.

Use this when you want the system to LEARN from the rejection. Each
reason maps to a different RL penalty applied to the source feed's
scoring weight, so the swarm gets smarter about that product's leads
over time.

When to use this vs `delete_mission`:
    - `reject_mission`: the lead was a bad signal — feed it back so the
      scoring weight adjusts. Always prefer this when you have any
      opinion on why the lead was wrong.
    - `delete_mission`: queue cleanup only (duplicates, stale leads,
      things you don't want to teach the system about). NO learning.

DON'T use `reject_mission` when the post is gone (deleted by the
poster, 404'd, removed by mods, or stale beyond your reply window).
The lead wasn't bad — it just disappeared. Use `delete_mission`
instead, which leaves the source station's `rl_weight` untouched.
Reaching for `reject_mission(not_relevant)` here penalises a station
that did nothing wrong.

Valid `rejection_reason` values:
    - `spam`             — bot/promoted/automated post (heaviest penalty)
    - `not_relevant`     — wrong audience or topic
    - `wrong_product`    — relevant signal but wrong product matched it
    - `too_vague`        — signal too weak to act on
    - `sarcasm`          — venting/ironic, not a real buyer
    - `already_customer` — they already bought (no penalty)
    - `no_reason`        — default if you don't have a strong opinion

Pick the most accurate reason — they apply different penalty sizes,
so accuracy directly improves how the system learns.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mission_idYesThe mission's id, from get_missions.
rejection_reasonNoWhy the lead was wrong: spam, not_relevant, wrong_product, too_vague, sarcasm, already_customer or no_reason (the default). The tool description says when to use each.no_reason

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / mission_id / description
      Added value: +"The mission's id, from get_missions."
    • addedInput schema / properties / rejection_reason / description
      Added value: +"Why the lead was wrong: spam, not_relevant, wrong_product, too_vague, sarcasm, already_customer or no_reason (the default). The tool description says when to use each."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations establish the safety profile (not read-only, not destructive, not idempotent) but the description adds substantial behavior: the rejection feeds an RL penalty into the source feed's scoring weight, reason choice changes penalty size, and already_customer carries no penalty. It also warns that misusing not_relevant penalises an innocent station — well beyond annotation coverage.

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 layers alternatives and the reason list. The closing 'Pick the most accurate reason' sentence is mild redundancy, and the reason list is long, but each block earns its place given the enum-like domain knowledge it conveys.

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?

For a two-parameter mutation tool with no output schema, the definition covers the safety profile via annotations, the learning side-effect, the sibling boundary, the failure case, and every reason code. Nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description goes further by annotating each rejection_reason value with its actual semantics and relative penalty weight (spam = heaviest, already_customer = none, no_reason = default). mission_id only gets an implied source ('from get_missions') already in the schema, so it's not a 5.

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+resource ('Reject a mission — it was not a real buying signal') and immediately disambiguates from the closest sibling, delete_mission. An agent can distinguish it from all 22 siblings without opening a 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-vs-delete_mission contrast with a rationale (learning vs queue cleanup), plus a clear when-NOT-to-use clause for disappeared posts and the consequence of getting it wrong. Nothing is left to inference.

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