Skip to main content
Glama
Sign In

Visual Sentinel

by com.visualsentinel
OverviewDiscussionsAdmin

Create an alert channel

vs_channels_create
Destructive

Add an email or WhatsApp alert channel, or get the dashboard page that finishes a channel needing a secret (Slack, Discord, Teams, PagerDuty, Opsgenie, webhook, Telegram, Prometheus, push). Your plan sets which channel types are available. New email recipients get a confirmation email.

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": {
      "name": "<name>",
      "type": "<type>"
    },
    "name": "vs_channels_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesDisplay name (up to 100 characters).
typeYesChannel type: EMAIL, WHATSAPP, SLACK, DISCORD, TEAMS, PAGERDUTY, OPSGENIE, WEBHOOK, TELEGRAM, PROMETHEUS, PUSH. EMAIL and WHATSAPP are created here; the other types answer with the dashboard page where their secret is entered.
configNoWhere to send: { recipients } for EMAIL, { phoneNumbers } for WHATSAPP. On update, only the keys sent change. Secret settings of other channel types are entered in the dashboard.
enabledNofalse stops alerts going to this channel.
isDefaultNotrue adds this channel to new monitors automatically.
alertTypesNoWhich alerts this channel gets: any of DOWNTIME, SLOW_RESPONSE, VISUAL, PERFORMANCE, SSL, DNS, DOMAIN, CONTENT. An empty list gets every type except PERFORMANCE, which a channel gets only when listed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false. The description adds real value beyond that: the non-obvious return-a-dashboard-page path for most enum values, plan-based availability limits, and the side effect that new email recipients receive a confirmation email. It does not clarify whether a partial channel record is persisted for the secret types, leaving a meaningful ambiguity.

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?

Front-loaded with the core action, then the branching rule, then the plan constraint and the email side effect. Reasonably tight, though the nine-item parenthetical channel list is slightly heavy given the same list appears in the `type` schema description.

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?

With 6 params, a nested config object, and no output schema, the description covers the essentials an agent needs: which types actually create, what the others return, and the plan gate. The remaining gap is that the caller is not told what to do after receiving the dashboard URL or whether a channel entry already exists at that point.

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%, including the config nested object and the alertTypes enum semantics (empty list gets everything except PERFORMANCE), so the schema already carries the parameter burden. The description adds only the plan-availability constraint on `type`, which is indirect. Baseline 3 is appropriate.

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?

States a specific verb and resource ("Add an email or WhatsApp alert channel") and immediately discloses the surprising dual behavior: for the ten secret-bearing types it does not create anything but returns the dashboard page that finishes the channel. An agent can distinguish this from vs_channels_update or vs_channels_list without opening 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes by channel type: EMAIL and WHATSAPP are created here, all other types answer with a dashboard page. It also warns that plan tier gates which types are available. It stops short of naming sibling alternatives (vs_channels_update for existing channels, vs_channels_test for verification), so the routing is clear but not exhaustive.

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

All Visual Sentinel toolsInspect
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.

Resources