mcp-server

tickerbot_enable_webhook

Re-enable a disabled webhook and start it clean. Clears match-state, so the next eval treats every currently-matching ticker as new.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Webhook id.

Output Schema

TableJSON Schema

Name	Required	Description
`q`	Yes	The stored predicate. Custom signals appear expanded: the SQL is frozen at creation.
`id`	Yes	The webhook id — `wh_…`, the handle for every other call on this record.
`dir`	Yes	Sort direction for that list; `null` means the default (`desc`).
`name`	Yes	Your label for the subscription.
`as_of`	Yes	Server time this response was assembled (ISO 8601).
`order`	Yes	Sort signal for the payload row list; `null` means the evaluator default (`market_cap`).
`fields`	Yes	Extra signals carried on each fired match row; `null` means the standard set.
`source`	Yes	Which API version created the record; `v2` for anything you create today.
`status`	Yes	`active` or `disabled`. Auto-disable follows repeated delivery failure.
`cadence`	Yes	How often the trigger is evaluated — `realtime`, `hourly`, or `nyse_open`.
`channel`	Yes	Where deliveries go: `webhook`, `discord`, `in_app`, or `mobile_push`.
`event_q`	No	Event-trigger webhooks only: the payload filter, or `null`.
`rule_id`	Yes	Legacy link to a v1 alert rule; `null` on everything created through v2.
`delivery`	Yes	Legacy alias of `channel`, kept aligned for older readers.
`created_at`	Yes	Creation timestamp.
`last_error`	No	The last evaluation error; `null` on a healthy hook. The answer to "why is my webhook not firing?".
`last_fired`	Yes	When a delivery last went out; `null` if it never has.
`target_url`	Yes	Your HTTPS endpoint; `null` on every channel except `webhook`.
`updated_at`	Yes	Last modification timestamp.
`event_kinds`	No	Event-trigger webhooks only: the kinds subscribed (`split`, `dividend`, `insider`, `analyst`, `earnings`).
`universe_id`	Yes	Universe the trigger is scoped to, or `null` for the whole market.
`next_eval_at`	Yes	When the evaluator will next consider this subscription.
`trigger_kind`	No	Event-trigger webhooks only: `event`.
`event_tickers`	No	Event-trigger webhooks only: the symbols the trigger is scoped to, or `null` for the universe / whole market.
`last_match_set`	Yes	Tickers matching at the last evaluation — the set the next run is diffed against, which is what makes firing edge-triggered.
`last_evaluated_at`	Yes	When it was last evaluated; `null` until the first run.
`last_eval_error_at`	No	When the last evaluation error happened; `null` on a healthy hook.
`subscription_origin`	Yes	Which door created it — `type` (`ticker`/`signal`/`scan`/`event`), its `ref`, and the `condition` in display form.
`last_predicate_value`	Yes	The trigger's value at the last evaluation; `null` until it has run.

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"
+    },
+    "cadence": {
+      "description": "How often the trigger is evaluated — `realtime`, `hourly`, or `nyse_open`.",
+      "type": "string"
+    },
+    "channel": {
+      "description": "Where deliveries go: `webhook`, `discord`, `in_app`, or `mobile_push`.",
+      "type": "string"
+    },
+    "created_at": {
+      "description": "Creation timestamp.",
+      "type": "number"
+    },
+    "delivery": {
+      "description": "Legacy alias of `channel`, kept aligned for older readers.",
+      "type": "string"
+    },
+    "dir": {
+      "description": "Sort direction for that list; `null` means the default (`desc`).",
+      "type": "string"
+    },
+    "event_kinds": {
+      "description": "Event-trigger webhooks only: the kinds subscribed (`split`, `dividend`, `insider`, `analyst`, `earnings`).",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "event_q": {
+      "description": "Event-trigger webhooks only: the payload filter, or `null`.",
+      "type": "string"
+    },
+    "event_tickers": {
+      "description": "Event-trigger webhooks only: the symbols the trigger is scoped to, or `null` for the universe / whole market.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "fields": {
+      "description": "Extra signals carried on each fired match row; `null` means the standard set.",
+      "type": "string"
+    },
+    "id": {
+      "description": "The webhook id — `wh_…`, the handle for every other call on this record.",
+      "type": "string"
+    },
+    "last_error": {
+      "description": "The last evaluation error; `null` on a healthy hook. The answer to \"why is my webhook not firing?\".",
+      "type": "string"
+    },
+    "last_eval_error_at": {
+      "description": "When the last evaluation error happened; `null` on a healthy hook.",
+      "type": "number"
+    },
+    "last_evaluated_at": {
+      "description": "When it was last evaluated; `null` until the first run.",
+      "type": "number"
+    },
+    "last_fired": {
+      "description": "When a delivery last went out; `null` if it never has.",
+      "type": "number"
+    },
+    "last_match_set": {
+      "description": "Tickers matching at the last evaluation — the set the next run is diffed against, which is what makes firing edge-triggered.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "last_predicate_value": {
+      "description": "The trigger's value at the last evaluation; `null` until it has run.",
+      "type": "string"
+    },
+    "name": {
+      "description": "Your label for the subscription.",
+      "type": "string"
+    },
+    "next_eval_at": {
+      "description": "When the evaluator will next consider this subscription.",
+      "type": "number"
+    },
+    "order": {
+      "description": "Sort signal for the payload row list; `null` means the evaluator default (`market_cap`).",
+      "type": "string"
+    },
+    "q": {
+      "description": "The stored predicate. Custom signals appear expanded: the SQL is frozen at creation.",
+      "type": "string"
+    },
+    "rule_id": {
+      "description": "Legacy link to a v1 alert rule; `null` on everything created through v2.",
+      "type": "string"
+    },
+    "source": {
+      "description": "Which API version created the record; `v2` for anything you create today.",
+      "type": "string"
+    },
+    "status": {
+      "description": "`active` or `disabled`. Auto-disable follows repeated delivery failure.",
+      "type": "string"
+    },
+    "subscription_origin": {
+      "description": "Which door created it — `type` (`ticker`/`signal`/`scan`/`event`), its `ref`, and the `condition` in display form.",
+      "type": "object"
+    },
+    "target_url": {
+      "description": "Your HTTPS endpoint; `null` on every channel except `webhook`.",
+      "type": "string"
+    },
+    "trigger_kind": {
+      "description": "Event-trigger webhooks only: `event`.",
+      "type": "string"
+    },
+    "universe_id": {
+      "description": "Universe the trigger is scoped to, or `null` for the whole market.",
+      "type": "string"
+    },
+    "updated_at": {
+      "description": "Last modification timestamp.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "as_of",
+    "id",
+    "name",
+    "q",
+    "rule_id",
+    "fields",
+    "order",
+    "dir",
+    "universe_id",
+    "cadence",
+    "channel",
+    "target_url",
+    "delivery",
+    "status",
+    "source",
+    "subscription_origin",
+    "last_predicate_value",
+    "created_at",
+    "updated_at",
+    "last_fired",
+    "last_match_set",
+    "next_eval_at",
+    "last_evaluated_at"
+  ],
+  "type": "object"
+}

AddedJun 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full disclosure burden. It openly reveals the non-obvious side effect that match-state is cleared, so the next eval treats matching tickers as new. It stops short of describing behavior for already-enabled webhooks or error cases, but the core destructive side effect is transparent.

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?

Two sentences, both information-denseched. The primary action is stated first Ia and the important side effect follows immediately. No filler or repetition exists.

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?

For a single-parameter tool with an output schema, the description covers the action and the critical state-reset behavior. It could clarify behavior if the webhook is not currently disabled, but the provided information is otherwise sufficient for an agent to invoke it correctly.

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?

The schema already fully documents the only parameter, 'id', as the webhook id. The description adds no extra semantic detail about the id beyond that, so it does not meaningfully increase parameter understanding.

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 uses a specific verb and resource: 'Re-enable a disabled webhook and start it clean.' This clearly distinguishes it from create/delete/test/update webhook operations, and the state-changing intent is explicit.

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 description gives clear context for when to use this tool: when re-enabling a disabled webhook. It does not explicitly name alternative tools or state when not to use it, but the use case is unambiguous from the operation described.

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.