LastPing

Overview Schema Source Related Servers Discussions Admin

Create alert destination

create_destination

Create a notification destination (channel) for alerts from webhooks, Slack, Discord, email and other kinds. Returns the channel id needed to route monitor alerts to it.

Instructions

Requires the write scope or higher. Creates a notification destination (channel) that monitors can route alerts to, from the fields of the chosen kind; unrelated fields are ignored. Non-email kinds are usable immediately; an email destination starts unverified, sends a confirmation link, and can join a route once the link is clicked. A project holds at most 25 destinations (DESTINATION_CAP_REACHED beyond that). Returns the new channel id, which set_route takes.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	webhook: the POST target URL.
`kind`	Yes	One of: webhook, telegram, discord, slack, ntfy, pushover, msteams, googlechat, email. Every destination URL has to be https, and a branded kind has to point at its vendor's host: discord at discord.com or discordapp.com, slack at hooks.slack.com, msteams at webhook.office.com or outlook.office.com or logic.azure.com or logic.azure.us or environment.api.powerplatform.com, googlechat at chat.googleapis.com. Any other endpoint fits kind "webhook", which accepts any https host; ntfy is unpinned too, so a self-hosted ntfy server works. A pin narrows the destination to the vendor's platform; it does not prove who owns the endpoint, since every pinned domain is multi-tenant.
`name`	Yes	Human-readable destination name, e.g. 'On-call Slack'.
`token`	No	pushover: the application API token.
`secret`	No	webhook: shared secret used to sign the HMAC-SHA256 payload.
`address`	No	email: the destination email address (a confirmation link is sent).
`chat_id`	No	telegram: the target chat id.
`user_key`	No	pushover: the user or group key.
`bot_token`	No	telegram: the bot token from @BotFather.
`topic_url`	No	ntfy: the full topic URL, e.g. 'https://ntfy.sh/my-topic'.
`webhook_url`	No	slack / discord / msteams / googlechat: the incoming-webhook URL.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.17Oct 7, 2026

changedInput schema / properties / kind / description

Previous value: -"One of: webhook, telegram, discord, slack, ntfy, pushover, msteams, googlechat, email. Every destination URL must be https. A BRANDED kind must point at its vendor's host: discord at discord.com or discordapp.com, slack at hooks.slack.com, msteams at webhook.office.com or outlook.office.com or logic.azure.com or logic.azure.us or environment.api.powerplatform.com, googlechat at chat.googleapis.com. For any other endpoint use kind \"webhook\", which accepts any https host; ntfy is unpinned too, so a self-hosted ntfy server is fine. A pin narrows the destination to the vendor's own platform; it does NOT prove the endpoint belongs to the person or project that created it, because every pinned domain is multi-tenant and open to anyone who signs up. Do not report a pinned destination as verified or as owned by anyone on the strength of its host."New value: +"One of: webhook, telegram, discord, slack, ntfy, pushover, msteams, googlechat, email. Every destination URL has to be https, and a branded kind has to point at its vendor's host: discord at discord.com or discordapp.com, slack at hooks.slack.com, msteams at webhook.office.com or outlook.office.com or logic.azure.com or logic.azure.us or environment.api.powerplatform.com, googlechat at chat.googleapis.com. Any other endpoint fits kind \"webhook\", which accepts any https host; ntfy is unpinned too, so a self-hosted ntfy server works. A pin narrows the destination to the vendor's platform; it does not prove who owns the endpoint, since every pinned domain is multi-tenant."

Changed1 schema field changedv0.1.6Sep 26, 2026

changedInput schema / properties / kind / description

Previous value: -"One of: webhook, telegram, discord, slack, ntfy, pushover, msteams, googlechat, email. Every destination URL must be https. A BRANDED kind must point at its vendor's host: discord at discord.com or discordapp.com, slack at hooks.slack.com, msteams at webhook.office.com or outlook.office.com or logic.azure.com or logic.azure.us or environment.api.powerplatform.com, googlechat at chat.googleapis.com. For any other endpoint use kind \"webhook\", which accepts any https host; ntfy is unpinned too, so a self-hosted ntfy server is fine. A pin narrows the destination to the vendor's own platform; it does NOT prove the endpoint belongs to the person or project that created it, because every pinned domain is multi-tenant and self-service. Do not report a pinned destination as verified or as owned by anyone on the strength of its host."New value: +"One of: webhook, telegram, discord, slack, ntfy, pushover, msteams, googlechat, email. Every destination URL must be https. A BRANDED kind must point at its vendor's host: discord at discord.com or discordapp.com, slack at hooks.slack.com, msteams at webhook.office.com or outlook.office.com or logic.azure.com or logic.azure.us or environment.api.powerplatform.com, googlechat at chat.googleapis.com. For any other endpoint use kind \"webhook\", which accepts any https host; ntfy is unpinned too, so a self-hosted ntfy server is fine. A pin narrows the destination to the vendor's own platform; it does NOT prove the endpoint belongs to the person or project that created it, because every pinned domain is multi-tenant and open to anyone who signs up. Do not report a pinned destination as verified or as owned by anyone on the strength of its host."

Changed1 schema field changedv0.1.3Sep 12, 2026

changedInput schema / properties / kind / description

Previous value: -"One of: webhook, email, slack, discord, telegram, ntfy, pushover, msteams, googlechat."New value: +"One of: webhook, telegram, discord, slack, ntfy, pushover, msteams, googlechat, email. Every destination URL must be https. A BRANDED kind must point at its vendor's host: discord at discord.com or discordapp.com, slack at hooks.slack.com, msteams at webhook.office.com or outlook.office.com or logic.azure.com or logic.azure.us or environment.api.powerplatform.com, googlechat at chat.googleapis.com. For any other endpoint use kind \"webhook\", which accepts any https host; ntfy is unpinned too, so a self-hosted ntfy server is fine. A pin narrows the destination to the vendor's own platform; it does NOT prove the endpoint belongs to the person or project that created it, because every pinned domain is multi-tenant and self-service. Do not report a pinned destination as verified or as owned by anyone on the strength of its host."

First observedSep 6, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the 25-destination cap and DESTINATION_CAP_REACHED error, the email verification flow, the 'unrelated fields are ignored' behavior, and the returned channel id. These are exactly the operational facts an agent needs that annotations do not provide.

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-loads the scope requirement, then the core behavior, verification nuance, cap, and return value in four tight sentences. Slightly dense but no wasted clauses.

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?

Covers auth requirement, kind-dependent behavior, cap/error, and return value — the essential facts for an 11-param creation tool. Missing only minor details like whether the returned id is used elsewhere beyond set_route, but it is essentially complete.

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% and the schema already documents each field per-kind in detail. The description adds the useful 'from the fields of the chosen kind; unrelated fields are ignored' rule, but otherwise defers to the schema. 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 ('Creates a notification destination (channel) that monitors can route alerts to') and ties it to siblings like set_route and list_destinations. An agent can immediately distinguish this from update_destination or test_destination.

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?

Explains prerequisites ('Requires the write scope or higher'), the kind-dependent immediate-vs-verification flow, and mentions set_route as the consumer of the returned id. It does not explicitly name create vs update alternatives, but the routing to set_route gives clear downstream context.

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

Deploy Server

Create alert destination

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools