Skip to main content
Glama

SignalPipe

by io.github.AbYousef739
OverviewDiscussionsAdmin

record_reply

Record what a prospect wrote back, and let the brain read it.

Call this whenever a tracked prospect replies (a comment reply, a DM, an
email). The brain reads the reply and updates their temperature, mode and
objections, and returns:
  - intent: buy / interested / objection / not_now / unsubscribe / neutral ...
  - mode: the prospect's new stage (nurture / sales / closing / recovery / dead)
  - do_not_contact: true when they asked not to be contacted. Stop: never
    message them again (get_message_prompt will refuse).
  - invites_private_contact: true only when THIS reply explicitly asks to
    continue in private ("DM me"). Reddit and X require that consent before
    an app sends a private message, so never suggest a DM without it.

Presentation: tell the operator the intent, the new mode, and any new
objection in one line. If do_not_contact is true, say so plainly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
channelNoOptional. Where they replied: "reddit", "twitter" or "email".
reply_textYesWhat the prospect wrote back, word for word.
prospect_idYesThe prospect's id, from get_pipeline.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / channel / description
      Added value: +"Optional. Where they replied: \"reddit\", \"twitter\" or \"email\"."
    • addedInput schema / properties / prospect_id / description
      Added value: +"The prospect's id, from get_pipeline."
    • addedInput schema / properties / reply_text / description
      Added value: +"What the prospect wrote back, word for word."
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond annotations, which only declare a non-destructive, non-idempotent, closed-world write. The description discloses that the brain updates temperature/mode/objections, that do_not_contact blocks all future messaging via get_message_prompt, and that invites_private_contact gates DM consent on Reddit/X.

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?

The core purpose and return semantics are front-loaded in the opening lines, and the bulleted return-value list is scannable. The trailing presentation instruction is useful but slightly beyond the tool's own behavior; overall still tight.

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 by enumerating the returned fields (intent, mode, do_not_contact, invites_private_contact) and their operational meaning. Annotations cover idempotency/safety, and the two required params are schema-documented, so nothing essential 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 description coverage is 100%, so prospect_id, reply_text and channel are already documented in the schema. The description adds channel context indirectly ("a comment reply, a DM, an email") but no syntax or format detail beyond the schema, 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?

States a specific verb+resource ("Record what a prospect wrote back") and immediately clarifies the downstream effect ("let the brain read it"). This distinguishes it from the near-name sibling record_message, which records outbound messages rather than inbound replies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ("Call this whenever a tracked prospect replies") with concrete channels enumerated (comment reply, DM, email). It also names a downstream dependency (get_message_prompt will refuse after do_not_contact), but does not explicitly route to an alternative tool for other cases.

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