mcp-server

tickerbot_get_signal

The state of a signal is the set of tickers matching it right now, or with asof, as of any moment. One name, the whole market, one call. Booleans need no condition; every other type needs one, typed like the signal: ">70" (numeric), "<YYYY-MM-DDTHH:MM:SSZ" (timestamp), ">=YYYY-MM-DD" (date), "=ETF" (string). Sorted by signal value desc for non-booleans.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`asof`	No	Optional. Target moment as `YYYY-MM-DD` (that day's close) or an ISO timestamp (that intraday moment) — the same read as it stood then, unlimited depth. Full contract under As of a past date.
`limit`	No	Page size. Max 200.
`cursor`	No	Opaque cursor from the previous response.
`signal`	Yes	A signal name. Booleans (e.g. `golden_cross`, `above_sma_50`) are detected automatically; every other type (numeric `rsi_14`, timestamp `price_asof`, date `earnings_date`, string `asset_class`) requires a `condition`.
`sort_by`	No	Row order: `default` (alphabetic for booleans, highest-value-first for numerics) or `market_cap` (desc NULLS LAST; adds `market_cap` to each row). Live only — with `asof` it is a 400 (the snapshot's order is fixed).	default
`interval`	No	Grain the past state is reconstructed at: `1m`, `1h`, `1d`, or `auto` (default). Only valid alongside `asof` — a live read with `interval` is a 400. Details under As of a past date.	auto
`universe`	No	Optional. Scope to a system or caller-owned universe slug.
`condition`	No	Required for every non-boolean signal; the shape follows the signal's `type` in the catalog. Single bound, `<op><value>`. numeric: `>70`, `<=200`, `!=0` (operators `>`, `>=`, `=`, `!=`, `<`, `<=`). timestamp: an ISO instant, `<YYYY-MM-DDTHH:MM:SSZ` or `>=YYYY-MM-DD` (a bare date is midnight UTC). date: `>=YYYY-MM-DD` or `=YYYY-MM-DD`. string: `=ETF` or `!=ETF` (`=` and `!=` only; quotes optional). A relative window ("older than 15 minutes") is a `/v2/scan` query: `price_asof < now() - interval '15 minutes'`. Sending a condition with a boolean or custom signal returns 400 (it does not apply).
`include_active_since`	No	Built-in booleans only: adds `active_since` and `days_live` per row — the first day of the current true streak, from daily state (the day after the last false day; if the boolean has never been false since it first computed, the first true day). Looks back five years, so a boolean true for longer reports the window edge as a lower bound. Live only — a 400 with `asof`.

Output Schema

TableJSON Schema

Name	Required	Description
`_meta`	No	With `asof` only: how the read was resolved — interval served and requested, blending, sources, frozen fields. See the as-of read below.
`as_of`	Yes	Server time this response was assembled (ISO 8601).
`count`	Yes	Rows in this page.
`signal`	Yes	The signal you asked for.
`results`	Yes	Matching tickers with the signal value.
`universe`	Yes	The universe you scoped to, echoed; `null` when unscoped.
`condition`	Yes	The bound you passed, echoed; `null` for boolean and custom signals.
`next_cursor`	Yes	Opaque token for the next page; `null` on the last page. Pass it back as `cursor`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 23, 2026

changedInput schema / properties / condition / description

Previous value: -"Required for numeric signals. Single bound, format `<op><value>`. Operators: `>`, `>=`, `=`, `!=`, `<`, `<=`. Examples: `>70`, `<=200`, `!=0`. Sending one with a boolean or custom signal returns 400 (it does not apply)."New value: +"Required for every non-boolean signal; the shape follows the signal's `type` in the catalog. Single bound, `<op><value>`. numeric: `>70`, `<=200`, `!=0` (operators `>`, `>=`, `=`, `!=`, `<`, `<=`). timestamp: an ISO instant, `<YYYY-MM-DDTHH:MM:SSZ` or `>=YYYY-MM-DD` (a bare date is midnight UTC). date: `>=YYYY-MM-DD` or `=YYYY-MM-DD`. string: `=ETF` or `!=ETF` (`=` and `!=` only; quotes optional). A relative window (\"older than 15 minutes\") is a `/v2/scan` query: `price_asof < now() - interval '15 minutes'`. Sending a condition with a boolean or custom signal returns 400 (it does not apply)."

changedInput schema / properties / signal / description

Previous value: -"A signal name. Booleans (e.g. `golden_cross`, `above_sma_50`) are detected automatically; numerics (e.g. `rsi_14`, `market_cap`, `pe_ratio`) require a condition."New value: +"A signal name. Booleans (e.g. `golden_cross`, `above_sma_50`) are detected automatically; every other type (numeric `rsi_14`, timestamp `price_asof`, date `earnings_date`, string `asset_class`) requires a `condition`."

Changed1 schema field changedSep 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "_meta": {
+      "description": "With `asof` only: how the read was resolved — interval served and requested, blending, sources, frozen fields. See the as-of read below.",
+      "type": "object"
+    },
+    "as_of": {
+      "description": "Server time this response was assembled (ISO 8601).",
+      "type": "string"
+    },
+    "condition": {
+      "description": "The bound you passed, echoed; `null` for boolean and custom signals.",
+      "type": "string"
+    },
+    "count": {
+      "description": "Rows in this page.",
+      "type": "number"
+    },
+    "next_cursor": {
+      "description": "Opaque token for the next page; `null` on the last page. Pass it back as `cursor`.",
+      "type": "string"
+    },
+    "results": {
+      "description": "Matching tickers with the signal value.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "signal": {
+      "description": "The signal you asked for.",
+      "type": "string"
+    },
+    "universe": {
+      "description": "The universe you scoped to, echoed; `null` when unscoped.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "as_of",
+    "signal",
+    "condition",
+    "universe",
+    "count",
+    "next_cursor",
+    "results"
+  ],
+  "type": "object"
+}

AddedSep 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses key behaviors: condition requirements for non-boolean signals, sorting by signal value desc for non-booleans, and the asof historical option. It does not mention errors, pagination, or live-only constraints, but those are covered in the schema. It adds value beyond the schema by summarizing condition syntax.

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

Conciseness5/5

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

The description is three sentences with no filler. It front-loads the purpose, includes concrete examples, and states the sort behavior. Every sentence earns its place, making it efficient and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters) and the rich input schema, the description provides sufficient context for an agent to understand the tool's core function. It does not cover all edge cases (e.g., live-only restrictions on sort_by and interval), but those are explicitly documented in the parameter descriptions. The output schema further reduces ambiguity. The description is complete enough when combined with the schema.

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?

The description adds meaning beyond the input schema by providing a quick summary of condition types and sorting rules. While the schema has detailed per-parameter descriptions (100% coverage), the description condenses the essential logic into a few examples, making it easier for an agent to grasp the condition parameter without reading the full schema.

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 description clearly states that the tool returns the set of tickers matching a signal, either currently or as of a past moment. It uses a specific verb ('get') and resource ('signal'), and the phrase 'One name, the whole market, one call' conveys scope. It distinguishes itself from siblings like get_bars and get_series by focusing on signal state.

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

Usage Guidelines3/5

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

The description implies usage (for retrieving tickers matching a signal) but does not explicitly compare to alternatives or state when not to use it. It does not mention sibling tools like scan or subscribe_signal, so an agent must infer appropriateness. The guidance is implicit 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 mcp-server tools Inspect

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.