Skip to main content
Glama

Send events to a channel

notify_subscribe

Send events to a saved channel as they happen, so the business's own tools hear about them: Slack, Teams, Discord, Google Chat, Telegram, ntfy, Pushover, or a webhook (signed JSON with the event's data; use one to connect Zapier, Make, n8n or your own systems). Replaces the channel's list. Free to send. Costs $0.001 per call; nothing if it fails.

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": {
      "channel": "<channel>",
      "events": "<events>"
    },
    "name": "notify_subscribe"
  }
}

Input Schema

NameRequiredDescriptionDefault
eventsYesEvent names from notify_list_events, "hiring.*", your bots' "custom.*", or "*".
channelYesA short name for the channel, e.g. "sales-alerts" (lowercase letters, numbers, dashes).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior1/5

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

The description is behaviorally rich (destinations, signed JSON webhooks, replacement semantics, pricing, no charge on failure), but it directly conflicts with structured annotations: 'Replaces the channel's list' is an overwrite/non-additive update while destructiveHint=false says only additive updates, and replacement semantics also undercut idempotentHint=false. The internal 'Free to send. Costs $0.001 per call' line is also contradictory, reducing trust in cost behavior.

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

Conciseness3/5

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

The purpose and supported destinations are front-loaded, but the second half is cluttered by the contradictory 'Free to send. Costs $0.001 per call' pair and a dense parenthetical about webhooks/Zapier/Make/n8n. It is not bloated, but the contradictory cost statement and run-on list reduce clarity.

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 simple two-parameter tool with full schema coverage and annotations, the description covers the essential call outcome: event delivery to a saved channel, supported destinations, and replacement behavior. It still leaves out prerequisite/alternative routing (e.g., add_channel before subscribe, unsubscribe to remove), but not enough to prevent a correct call.

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 already 100% for both parameters, so the schema supplies the event-name and channel-name formats. The description adds meaningful semantics the schema lacks: the channel must be 'saved' and the events list is replaced rather than appended. That goes beyond the baseline for a fully documented schema.

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 gives a specific verb and resource ('Send events to a saved channel') and makes the ongoing nature explicit ('as they happen', 'Replaces the channel's list') while enumerating supported destinations. It does not explicitly name notify_send as the one-off alternative, but the subscription behavior is clear enough to separate it from sibling notify_send.

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?

It explains the webhook option can connect Zapier/Make/n8n and implies use when events should be delivered as they happen, but it never states when to use this instead of notify_send, notify_unsubscribe, or notify_add_channel, nor that the channel must already exist. The 'Replaces the channel's list' warning is useful but is a side effect, not usage guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources