AlphAI

Subscribe to ticker alerts

alphai_alerts_subscribe

DestructiveIdempotent

WRITE operation (creates/updates a saved subscription in the caller's account). Subscribe the caller to ticker news alerts. Optional category_filter (e.g. ['earnings','insider']) restricts which categories trigger; min_relevance_score raises the threshold. This is a partial update: omitting either field on an existing subscription preserves its current value, and a brand-new subscription defaults min_relevance_score to 7. Note the threshold applies to email and telegram delivery; a Pro webhook receives the full matched stream and filters on its own. Raises tier_not_paid / unknown_ticker / limit_reached. Crypto alerts use the -USD ticker (BTC-USD); subscribing to a collider string like BTC binds the stock/ETF that owns it and the response's note field says so. OAuth connections need the alerts.write scope (raises insufficient_scope otherwise); API keys have it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "alphai_alerts_subscribe"
  }
}

Input Schema

Name	Required	Description
`ticker`	Yes	Ticker to subscribe to (active symbol).
`category_filter`	No	Categories that trigger alerts.
`min_relevance_score`	No	Min relevance to alert on.

Output Schema

Name	Required	Description	Default
`note`	No
`ticker`	Yes
`is_active`	Yes
`created_at`	Yes
`delivery_mode`	Yes
`category_filter`	No
`min_relevance_score`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / category_filter / anyOf

Previous value: -[
-  {
-    "items": {
-      "description": "Article category assigned by the enricher. Must match the backend.",
-      "enum": [
-        "earnings",
-        "mergers_acquisitions",
-        "regulation",
-        "macro_economy",
-        "sector_analysis",
-        "market_movers",
-        "technology",
-        "commodities",
-        "crypto",
-        "ipo",
-        "geopolitics",
-        "insider",
-        "corporate_actions",
-        "other"
-      ],
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "The article's news category, one of 14.",
+      "enum": [
+        "earnings",
+        "mergers_acquisitions",
+        "regulation",
+        "macro_economy",
+        "sector_analysis",
+        "market_movers",
+        "technology",
+        "commodities",
+        "crypto",
+        "ipo",
+        "geopolitics",
+        "insider",
+        "corporate_actions",
+        "other"
+      ],
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

Changed2 schema fields changedSep 26, 2026
- addedInput schema / properties / ticker / maxLength
```
Added value: +16
```
- addedInput schema / properties / ticker / pattern
```
Added value: +"^[A-Za-z0-9.\\-]+$"
```

Changed1 schema field changedSep 6, 2026

addedOutput schema / properties / note

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

First observedJun 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Far exceeds what the annotations convey: it explains partial-update semantics (omitting a field preserves the existing value), the default min_relevance_score of 7 for new subscriptions, that the threshold applies only to email/telegram delivery while Pro webhooks receive the full stream, the named error conditions, the required alerts.write OAuth scope, and the collider-string behavior with the response note field. This is exactly the kind of consequence and prerequisite detail annotations cannot express.

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

Conciseness4/5

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

Information-dense and front-loaded with the WRITE designation, with no filler sentences. It is a single long block covering many distinct topics (defaults, errors, auth, ticker quirks), which slightly hurts scannability but does not introduce waste.

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?

For a 3-parameter mutation tool with an output schema, the description covers everything an agent needs before calling: auth scope, defaults, partial-update behavior, failure modes, and input-format edge cases. Return values are appropriately left to the output schema, aside from one useful pointer to the note field.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it exemplifies category_filter values, clarifies that min_relevance_score 'raises the threshold' rather than being an absolute filter toggle, and supplies the default value of 7 plus its delivery-channel scope. The ticker collider/crypto guidance also refines what a valid ticker input means.

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?

Opens with 'WRITE operation (creates/updates a saved subscription in the caller's account)' and then states the specific action: 'Subscribe the caller to ticker news alerts.' The verb+resource combination is unambiguous, and the write/upsert framing distinguishes it immediately from the read/remove siblings such as alerts_list and alerts_unsubscribe.

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?

Gives clear operative conditions: use the <SYM>-USD ticker form for crypto, be aware of tier_not_paid/limit_reached failures, and note that Pro webhooks ignore the threshold. What it does not do is explicitly route the agent to alternatives (e.g., 'use alerts_unsubscribe to remove' or 'use alerts_list to inspect'), so this lands just short of a 5.

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

All AlphAI 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.