Skip to main content
Glama

score_signal

Score arbitrary text for buying-intent / competitor-mention / churn / noise.

Use this when your agent encounters content from any channel it has
access to — email, Slack, Discord, Telegram, LinkedIn, WhatsApp, a
YouTube comment, a blog post — and you want to know whether it's a
real signal worth acting on, before drafting a reply.

SignalPipe doesn't connect to the source channel. Your agent reads
the text (via whatever plugin gives it that access) and passes the
text here. We run the same scoring engine the scout uses on Reddit
and HN: keyword gate, multilingual semantic scoring (EN/ES/FR/DE/PT/FI),
3-judge swarm pattern, sarcasm detection, and competitor-intent
classification.

Returns: score (0-100), role (closer/advisor/educator), classification
(buying_intent / competitor_mention / borderline / noise), sub-scores
(urgency, specificity, keyword_density), competitor info if matched,
and a `drafting_context` block when the score is high enough to act
on.

When the borderline band triggers a panel review you also get
`swarm_ran: true` and a `swarm` block: each judge's stance
("convinced" / "on the fence" / "unconvinced") and `split: true` when
they disagreed materially. A split panel is worth flagging to the
operator — it usually means the post is genuinely ambiguous rather
than clearly a lead or clearly noise. You write the reply yourself using the context — same pattern as
`draft_mission`, no server-side LLM call required.

⚠️ CHECK `degraded` BEFORE YOU TRUST A LOW SCORE. There is a per-tenant
daily budget for panel reviews. `degraded: true` means this text WAS
borderline but the panel did not get to judge it — either the budget ran
out (`swarm_skipped: "daily_cap_reached"`) or the panel errored
(`"panel_failed"`). The score you are holding is the content-only score,
which is exactly the score the panel exists to correct: it under-reads
real buyers as `noise`. Do NOT tell the operator a `degraded` post is not
a lead. Say the verdict is provisional and offer to re-score it later.

`degraded: false` with `swarm_skipped: "not_borderline"` is the normal,
healthy case — the text was clear-cut and did not need a panel. That
verdict is trustworthy.

`swarm_budget_remaining` tells you how many panel reviews are left today.
If you are scoring in bulk, watch it and pace yourself rather than
spending the budget on obvious noise.

`panel_verdict` says what the judges concluded: "kept", "rejected", or
"not_run". The judges can raise a score but never lower it, so a post they
rejected can still read "borderline". Treat `panel_verdict: "rejected"` as
not a lead, whatever the score.

Scoring a reply or comment? Pass the post or thread it answers as
`context`. The judges see it as background, and the score stays about the
reply's own author.

Presentation: if classification is `buying_intent` or
`competitor_mention`, surface the lead to the operator with score,
role, classification, and the drafting context. If classification is
`noise` or `borderline`, mention it briefly so the operator knows you
looked but don't bother them with a draft.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe content to score: an email body, chat message, comment or post excerpt. Up to 4,000 characters are used.
contextNoOptional. The post, thread or email the text replies to (up to 2,000 characters). The judges see it as background; the score stays about the text's own author.
product_idYesThe product to score against, from get_products.
source_hintNoOptional channel label, such as "gmail", "slack", "discord", "telegram", "linkedin", "whatsapp", "facebook" or "youtube_comment". It tunes the tone of the drafting context and never changes the score.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / context / description
      Added value: +"Optional. The post, thread or email the text replies to (up to 2,000 characters). The judges see it as background; the score stays about the text's own author."
    • addedInput schema / properties / product_id / description
      Added value: +"The product to score against, from get_products."
    • addedInput schema / properties / source_hint / description
      Added value: +"Optional channel label, such as \"gmail\", \"slack\", \"discord\", \"telegram\", \"linkedin\", \"whatsapp\", \"facebook\" or \"youtube_comment\". It tunes the tone of the drafting context and never changes the score."
    • addedInput schema / properties / text / description
      Added value: +"The content to score: an email body, chat message, comment or post excerpt. Up to 4,000 characters are used."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations are sparse (readOnlyHint=false, non-idempotent, non-destructive), so the description carries most of the burden — and it does, disclosing the budget-limited panel, the `degraded`/`swarm_skipped` states, `panel_verdict` semantics (judges can raise but never lower), and that scoring consumes a per-tenant daily budget. This is well beyond what annotations convey. It stops short of the absolute top only because it never explicitly reconciles readOnlyHint=false against the description's framing of the tool as non-mutating.

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?

It is long, but organized into clearly front-loaded sections (purpose, when-to-use, mechanism, return shape, degraded handling, presentation). The `degraded` warning is emphasized with repeated framing that borders on redundant, but almost every sentence carries operational instruction rather than filler.

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 fully specifies the return payload (score, role, classification, sub-scores, competitor info, drafting_context, swarm block) and explains the conditional edge cases an agent must handle before trusting a verdict. Nothing needed to invoke and correctly interpret the result 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 adds genuine meaning: it explains that scoring a reply should pass the answered post/thread as `context` so judges treat it as background, matching the schema's intent, and pinpoints `product_id` (from get_products) and the tone-only effect of `source_hint`. This goes beyond the schema text.

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 sentence states a specific verb (score) and resource (arbitrary text) plus the four classification targets it produces (buying-intent / competitor-mention / churn / noise). It also distinguishes itself from the drafting sibling by naming the `draft_mission` pattern, so an agent can tell it apart from other tools without reading 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?

It gives explicit when-to-use conditions ('when your agent encounters content from any channel it has access to... before drafting a reply') and enumerates channels. It also provides a downstream decision rule: surface a lead for buying_intent/competitor_mention, stay quiet on noise/borderline. Alternatives and exclusions are effectively covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.