mcp-server

tickerbot_create_custom_signal

A named boolean predicate you can reference anywhere a built-in signal goes.

Input Schema

TableJSON Schema

Name	Required	Description
`expr`	Yes	Boolean SQL predicate. May reference built-in signals and other custom signals you own. Must evaluate to true/false. Max 4000 chars. Stricter grammar than scan `q`: comparisons, `AND`/`OR`/`NOT`, `IN`, `BETWEEN`, `IS [NOT] NULL`, arithmetic, and the functions `abs`/`coalesce`/`round`/`least`/`greatest` only — no `LIKE`/`ILIKE`, no `CASE`, no `::` casts, no other functions. An expression that scans fine can still be rejected here with `compile_failed`. What you send is what you read back: responses echo your expression VERBATIM, not its expansion. A signal referencing another custom of yours returns the reference as you typed it — the inlined SQL exists only internally, and is what a subscribe endpoint freezes into a webhook.
`name`	Yes	Slug — `^[a-z][a-z0-9_]{0,63}$`. Must not collide with any built-in signal name, and 15 names are reserved outright: `columns`, plus the `/v2/series` OHLCV aliases `open`/`high`/`low`/`close`/`volume`/`vwap`/`trades` and `o`/`h`/`l`/`c`/`v`/`vw`/`n` (those resolve to bars before custom lookup). This is the signal's API handle: it's what you reference in `q` and in the CRUD path.
`description`	No	Free-form notes. Max 500 chars. Absent or empty comes back as `""` rather than null.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`as_of`	Yes	Server time this response was assembled (ISO 8601).
`signal`	Yes	The stored signal: `name`, `kind` (`custom`), `description`, `expr` (your predicate as stored), `created_at`, `updated_at`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "as_of": {
+      "description": "Server time this response was assembled (ISO 8601).",
+      "type": "string"
+    },
+    "signal": {
+      "description": "The stored signal: `name`, `kind` (`custom`), `description`, `expr` (your predicate as stored), `created_at`, `updated_at`.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "as_of",
+    "signal"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedSep 17, 2026

changedInput schema / properties / description / description

Previous value: -"Optional human description."New value: +"Free-form notes. Max 500 chars. Absent or empty comes back as `\"\"` rather than null."

changedInput schema / properties / expr / description

Previous value: -"SQL WHERE expression. Same grammar as scan `q`."New value: +"Boolean SQL predicate. May reference built-in signals and other custom signals you own. Must evaluate to true/false. Max 4000 chars. Stricter grammar than scan `q`: comparisons, `AND`/`OR`/`NOT`, `IN`, `BETWEEN`, `IS [NOT] NULL`, arithmetic, and the functions `abs`/`coalesce`/`round`/`least`/`greatest` only — no `LIKE`/`ILIKE`, no `CASE`, no `::` casts, no other functions. An expression that scans fine can still be rejected here with `compile_failed`. What you send is what you read back: responses echo your expression VERBATIM, not its expansion. A signal referencing another custom of yours returns the reference as you typed it — the inlined SQL exists only internally, and is what a subscribe endpoint freezes into a webhook."

changedInput schema / properties / name / description

Previous value: -"Snake_case identifier."New value: +"Slug — `^[a-z][a-z0-9_]{0,63}$`. Must not collide with any built-in signal name, and 15 names are reserved outright: `columns`, plus the `/v2/series` OHLCV aliases `open`/`high`/`low`/`close`/`volume`/`vwap`/`trades` and `o`/`h`/`l`/`c`/`v`/`vw`/`n` (those resolve to bars before custom lookup). This is the signal's API handle: it's what you reference in `q` and in the CRUD path."

First observedJun 11, 2026

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only defines what a custom signal is. It says nothing about creation semantics such as compile_failed validation, naming conflicts, or how expressions are echoed back; those details live only in parameter descriptions, not the tool description.

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 a single sentence with no filler: it defines the entity and its intended usage in one pass. Information is front-loaded and every word contributes.

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

Completeness3/5

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

The one-line definition plus detailed schema properties and an output schema is adequate for an agent to attempt a call, but the tool description alone does not state the create action, error behavior, or permissions. Given the tool has no annotations, some important operational context is missing from the description itself.

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 the schema already thoroughly documents expr, name, and description. The top-level description adds no parameter-level meaning beyond pointing out that a custom signal can be referenced wherever built-in signals are used, leaving the schema to carry semantic weight.

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 description clearly identifies the created entity as a 'named boolean predicate' and explains its reuse 'anywhere a built-in signal goes,' so an agent can tell it apart from plain scan expressions. It stops short of using an explicit performative verb like 'creates,' relying on the tool name to convey the create action.

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 phrase 'reference anywhere a built-in signal goes' implies the main use case: define a custom signal once and reuse it. It does not explicitly say when to choose this over inline expressions, update/delete operations, or the sibling create_universe/create_webhook tools, so guidance is mostly implied.

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.