Skip to main content
Glama

signal-bureau

by io.github.evolutionlabs-dev
OverviewDiscussionsAdmin

get_signals

Read-onlyIdempotent

START HERE for browsing — the cheap read (500/day, no model work). The full machine-readable signal feed (same payload as GET /api/signals): every entity currently flagged by the attention engine, with trajectory, domains, desk membership, canonical identity (canonicalId sb:e/..., durable; slug may change), self-describing counts (counts.attention.current vs counts.evidence.total, each with unit, window and scope; signalCount/verticalCount are deprecated aliases), and an explicit evidenceStatus (receipted rows carry source-attributed evidence URLs; unreceipted rows are labeled leads). Measured property: Measured association: flagged markets repriced materially at 1.46x the rate of matched unflagged controls (95% CI 1.32-1.62, shock-days excluded, controls reweighted to the flagged cohort; n=2863 flagged vs 120062 controls, window 2026-03-29 to 2026-10-17, as of 2026-10-17). An attention-leads-movement association — never a directional claim.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many signals (default all flagged)
directionNoFilter by trajectory regime: rising|fading|steady|new|insufficient_history. An unknown value is refused, never answered with an empty list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / direction / description
      Previous value: -"Filter by trajectory: rising|fading|steady|new"New value: +"Filter by trajectory regime: rising|fading|steady|new|insufficient_history. An unknown value is refused, never answered with an empty list."
    • addedInput schema / properties / direction / enum
      Added value: +[
+  "rising",
+  "fading",
+  "steady",
+  "new",
+  "insufficient_history"
+]
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds material context: a 500/day rate limit, no model invocation, canonicalId durability ('slug may change'), deprecated count aliases, and the receipted-vs-leads evidenceStatus distinction. It also discloses the interpretive limit of the flagged data ('an attention-leads-movement association — never a directional claim').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loading is good — cost, payload identity, and field inventory come first. But the embedded statistical block (1.46x, 95% CI, n=2863 vs 120062, exact window dates) is disproportionate for a tool description and crowds out more actionable guidance.

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?

There is no output schema, so the description must carry the return contract, and it does: trajectory, domains, desk membership, canonical identity, self-describing counts with units/windows/scopes, and evidenceStatus. An agent knows what shape of data it will get before calling.

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 both parameters (limit, direction) are already documented with an enum and a refusal-on-unknown-value note in the schema itself. The description mentions trajectory as a payload field but adds nothing about how limit or direction behave, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The second clause is precise: 'the full machine-readable signal feed ... every entity currently flagged by the attention engine', which tells an agent exactly what comes back. However, the leading 'START HERE for browsing' collides with the sibling tool literally named start_here, so the opening line actively blurs routing rather than sharpening it.

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?

'the cheap read (500/day, no model work)' frames the cost/benefit tradeoff that distinguishes it from the model-backed ask tool. It never names an alternative or states a when-not condition, so the routing guidance is implied rather than explicit.

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

All signal-bureau 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