mcp-server

tickerbot_update_custom_signal

Update a custom signal you own — its expression, description, or name.

Input Schema

TableJSON Schema

Name	Required	Description
`expr`	No	New SQL expression. Re-validated and re-inlined against your other custom signals. Same strict grammar as create — no `LIKE`/`ILIKE`, `CASE`, `::` casts, or functions beyond `abs`/`coalesce`/`round`/`least`/`greatest`. The response echoes your expression verbatim, not its expansion.
`signal`	Yes	Custom signal slug (the signal name). A built-in name answers 404 — built-ins are read-only.
`new_name`	No	New slug — renames the signal and changes its API handle everywhere (same validation as create). Refused while other custom signals reference the current name. `name` is accepted as an alias (new_name wins when both are sent), but new_name is the unambiguous spelling since the URL already carries the current name.
`description`	No	New description. Not derived from `expr` — change both if the prose describes a threshold you are moving.

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"
+}

Changed6 schema fields changedSep 17, 2026

changedInput schema / properties / description / description

Previous value: -"New description."New value: +"New description. Not derived from `expr` — change both if the prose describes a threshold you are moving."

changedInput schema / properties / expr / description

Previous value: -"New SQL WHERE expression. Re-validated on save."New value: +"New SQL expression. Re-validated and re-inlined against your other custom signals. Same strict grammar as create — no `LIKE`/`ILIKE`, `CASE`, `::` casts, or functions beyond `abs`/`coalesce`/`round`/`least`/`greatest`. The response echoes your expression verbatim, not its expansion."

removedInput schema / properties / name

Removed value: -{
-  "description": "CURRENT slug — identifies which signal to edit.",
-  "type": "string"
-}

changedInput schema / properties / new_name / description

Previous value: -"Rename the signal to this slug (snake_case, must not collide with a built-in signal or another of your signals)."New value: +"New slug — renames the signal and changes its API handle everywhere (same validation as create). Refused while other custom signals reference the current name. `name` is accepted as an alias (new_name wins when both are sent), but new_name is the unambiguous spelling since the URL already carries the current name."

addedInput schema / properties / signal

Added value: +{
+  "description": "Custom signal slug (the signal name). A built-in name answers 404 — built-ins are read-only.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "name"
-]New value: +[
+  "signal"
+]

Changed1 schema field changedSep 15, 2026

changedInput schema / properties / new_name / description

Previous value: -"Rename the signal to this slug (snake_case, must not collide with a built-in column or another of your signals)."New value: +"Rename the signal to this slug (snake_case, must not collide with a built-in signal or another of your signals)."

Changed2 schema fields changedAug 7, 2026

changedInput schema / properties / name / description

Previous value: -"Custom signal slug."New value: +"CURRENT slug — identifies which signal to edit."

addedInput schema / properties / new_name

Added value: +{
+  "description": "Rename the signal to this slug (snake_case, must not collide with a built-in column or another of your signals).",
+  "type": "string"
+}

AddedJun 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

No annotations exist, so the definition carries full behavioral burden. The parameter descriptions disclose important side effects: expression re-validation and re-inlining, rename changing the API handle everywhere, refusal while other signals reference the current name, and built-ins answering 404. This is strong behavioral disclosure for a mutating tool.

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 opening sentence is concise and front-loaded with the action, resource, and editable fields. Each parameter description earns its place with a meaningful rule or caveat, with no filler or redundant information.

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?

Given the rich parameter descriptions and an output schema, the definition covers ownership, built-in read-only behavior, rename side effects, expression grammar restrictions, and the relationship between description and expression. An agent has the needed information to call this tool correctly and safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 parameter descriptions add substantial extra meaning: allowed SQL grammar, forbidden constructs, exact allowed functions, alias behavior for 'name', and rename/reference constraints. These go well beyond basic type or format documentation.

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 specifies a clear action ('Update'), a specific resource ('a custom signal you own'), and the mutable fields (expression, description, or name). This clearly distinguishes it from create/delete variants and from update_universe/update_webhook without requiring the agent to open the schema.

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 'you own' implies the tool is only for user-created custom signals, and the schema adds a built-in read-only exclusion via 404 behavior. However, it does not explicitly say when to prefer this over create/delete or mention alternatives for updating other resource types, leaving some usage routing implicit.

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.