Skip to main content
Glama

SignalPipe

by io.github.AbYousef739
OverviewDiscussionsAdmin

mark_sent

Idempotent

Mark a mission as sent by hand — "I already messaged this person myself."

Use this when YOU sent the outreach manually (via the Reddit/X UI, a
public comment, or a DM) instead of letting an autonomous sender do it.
Many leads are surfaced on the `manual` channel precisely so the operator
reviews and sends them personally — and first contact is often a public
reply rather than a DM. Without telling the system the send happened, the
mission sits unfinished, no prospect is created, and a later follow-up
draft has no record of what you already said.

What this does:
    - marks the mission as sent,
    - records the outreach so follow-up drafts know the conversation
      history (creates/updates the prospect and starts its lifecycle),
    - counts as a positive endorsement for the source feed (same learning
      signal as `approve_mission`).

When to use this vs the others:
    - `mark_sent`: you sent it yourself, by hand. Records the send +
      starts the prospect. Use this the moment you've actually messaged
      or replied to the person.
    - `approve_mission`: queue it for an autonomous sender to deliver
      (you are NOT sending it yourself right now).
    - `reject_mission` / `delete_mission`: you are NOT reaching out.

Idempotent: if you already called `approve_mission` on this lead, calling
`mark_sent` afterwards will not double-count anything — it just records
the actual send.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mission_idYesThe id of the mission you replied to yourself, from get_missions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / mission_id / description
      Added value: +"The id of the mission you replied to yourself, from get_missions."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover readOnly/idempotent/destructive, but the description adds substantial context beyond them: it enumerates side effects (records outreach, creates/updates the prospect, starts its lifecycle, counts as a positive endorsement for the source feed) and explains the idempotency behavior concretely, including interaction with a prior approve_mission call. The consequences of NOT calling it (mission sits unfinished, no prospect created) are also disclosed.

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?

Purpose is front-loaded in the first sentence, and the 'What this does' and 'When to use this vs the others' sections are cleanly structured. It is somewhat long for a one-parameter tool, but nearly every sentence carries distinct routing or behavioral value.

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?

No output schema exists, so the description appropriately covers both sides: what the call changes (send recorded, prospect lifecycle started) and how to choose it over alternatives. An agent has everything needed to invoke it correctly.

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 description coverage is 100% and the single mission_id param is fully documented in the schema (including where to get it: get_missions). The description adds no new syntax or format detail for the parameter, so the baseline 3 applies.

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?

The opening line gives a specific verb (mark) and resource (mission), and immediately scopes it as 'sent by hand.' It explicitly contrasts itself with approve_mission, reject_mission, and delete_mission, so the agent can distinguish it from siblings 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?

Provides an explicit when-to-use section that names the three sibling alternatives and the condition selecting each ('you sent it yourself' vs 'queue for autonomous sender' vs 'not reaching out'). It also states the timing ('the moment you've actually messaged or replied'). 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