On My Radar
On this page

Guides Agents and MCP

MCP tools for webhooks, notifications and your account

Reference for the eighteen MCP tools that manage webhooks, subscriptions and client portals, read notifications, and report who you are and what the server can do.

Updated October 30, 2026 · Checked against On My Radar build 2c4905d

These eighteen tools cover everything around the edges of your radars: URLs that turn outside events into blips, signed pushes out to other systems, client-portal connections, your notification tray, and the two tools that tell an agent who it is and what it can do. Ids and scopes are explained in the MCP reference overview. For the user view of webhooks, see Webhooks.

Inbound webhooks

An inbound webhook gives a radar a secret URL that anything can POST to. Each delivery becomes a blip: a form submission, a build result, an alert. The delivery is authorized as the person who created the webhook, so it can never reach a radar they could not write to, and it stops working when they lose that access. Deliveries are limited to 60 a minute per webhook and 64 KB per payload. All five tools need radars:manage and ownership of the radar.

The drop box cannot have a webhook, because an ingest URL is an unauthenticated way into a private inbox. A smart radar cannot have one either, because it holds no blips.

list_webhooks

Lists the inbound webhooks on a radar, with delivery counts and the last error. Secrets are never returned. Only a create or rotate call ever shows one.

  • Scope: radars:manage. Read-only.
  • Required: radarId (string).

create_webhook

Creates a webhook on a radar. The response contains the secret URL and shows it exactly once. Hand it to the person, and remember that anyone holding it can write to the radar.

  • Scope: radars:manage. Writes.
  • Required: radarId (string), name (1 to 120 characters: what will be sending).
  • Optional:
    • format: auto (default) reads the payload's shape. A recognisable message field is used as it is, otherwise every field becomes a labelled line. template renders bodyTemplate instead.
    • bodyTemplate (up to 4,000 characters): used with format: "template". {{field.path}} is filled in from the payload.
    • titleTemplate (up to 300 characters).
    • tags (up to 24, each up to 48 characters): applied to every blip this webhook creates. Worth setting, for provenance.
    • state: the triage state of created blips. Default inbox.
  • Returns: id, name, secretUrl and a note.

A template format without a non-empty bodyTemplate is refused.

{ "radarId": "5b2c7e2e-1f0a-4a55-9a53-0d1f6f3b8a10", "name": "Contact form", "tags": ["inbound"] }

update_webhook

Changes a webhook's mapping, tags or name, or pauses and resumes it. It does not reveal or rotate the existing secret.

  • Scope: radars:manage. Writes.
  • Required: webhookId (UUID), plus at least one field.
  • Optional: name, format, bodyTemplate, titleTemplate, tags, state (same limits as create_webhook) and enabled (boolean).

rotate_webhook_secret

Invalidates the current webhook URL and issues a replacement, shown only in this response. Update the sender with the new secretUrl.

  • Scope: radars:manage. Writes (marked destructive, and not idempotent: each call issues a new URL).
  • Required: webhookId (UUID).

delete_webhook

Stops a webhook accepting deliveries. Its URL dies immediately.

  • Scope: radars:manage. Writes (marked destructive).
  • Required: webhookId (UUID).
  • Returns: { "deleted": "<webhookId>" }.

Outbound subscriptions

An outbound subscription pushes signed events from a radar (blip.created, blip.updated, blip.deleted, comment.created) to a public HTTPS receiver. An agent can inspect and delete them. Creating one, pausing it, rotating its secret and sending a test are refused for any connection, so those happen in the app. A radar can have up to 20 subscriptions.

list_subscriptions

Lists the signed outbound webhook subscriptions on a radar. Secrets are never returned.

  • Scope: radars:manage. Read-only.
  • Required: radarId (UUID).

list_subscription_deliveries

Shows the last 100 delivery attempts for a subscription, newest first, without payloads or secrets.

  • Scope: radars:manage. Read-only.
  • Required: radarId (UUID), subscriptionId (UUID).

delete_subscription

Deletes a subscription and its pending deliveries.

  • Scope: radars:manage. Writes (marked destructive).
  • Required: radarId (UUID), subscriptionId (UUID).
  • Returns: { "deleted": "<subscriptionId>" }.

Client-portal integrations

A client portal is an outside system that reads and posts to your Helpdesk radars using its own credential. That credential is never an MCP credential. Connecting a portal, rotating or revoking its token, connecting a Helpdesk, setting where events are pushed, rotating the signing secret, resuming delivery and sending a test are all refused to an agent at any scope. Send the person to Settings, Connections. An agent can read the state and take the two safe steps below.

list_integrations

Lists your outside-system credentials, revoked ones included, and the Helpdesk radars each one reaches, with when each token was last used and when it expires. Secrets are never returned.

  • Scope: radars:read. Read-only.
  • Arguments: none.
  • Returns: { "integrations": [...] }.

list_integration_deliveries

Shows where an integration pushes its events (ids only, signed), whether delivery is paused, how many events are waiting, and the last attempts with their HTTP status. Delivery pauses by itself after six failed attempts and keeps every event queued.

  • Scope: radars:read. Read-only.
  • Required: integrationId (UUID).

pause_integration_delivery

Stops pushing events to the portal. Nothing is lost: events keep being logged and queued, the portal can still pull them, and you resume delivery from Settings, Connections, which sends the queue oldest first.

  • Scope: radars:write. Writes. Idempotent.
  • Required: integrationId (UUID).
  • Returns: the integration, as it is now.

unenroll_helpdesk_radar

Disconnects a Helpdesk radar from a portal: the portal can no longer list its requests or post to it. This is permanent for that connection. Reconnecting is the account owner's decision in a browser.

  • Scope: radars:write. Writes (marked destructive).
  • Required: integrationId (UUID), radarId (UUID).
  • Returns: the integration, as it is now.

Notifications

An agent may read and clear your notifications. It may never change how or whether you are notified. Email, browser push, per-radar levels and device subscriptions are refused for any connection. Send the person to Settings, Notifications. See Notifications.

A connection bound to an agent has a notification queue of its own: mentions of that agent. Nothing is emailed or pushed to it, and an unread item waits indefinitely, so drain it on connect.

list_notifications

Lists what has happened on your radars while you were away. Each line is already a rendered sentence, and several events of the same kind on the same blip are folded into one with a count.

  • Scope: radars:read. Read-only.
  • Optional:
    • unreadOnly (boolean, default false).
    • radarId (UUID): narrow to one radar.
    • kind: one of subscription_failed, comment, mention, reaction, share, blip, topic_share, topic_cascade, email_received, due or reply_pending.
    • limit (1 to 100, default 30) and cursor.
  • Returns: unreadTotal, items (each with id, kind, summary, optional excerpt and count, radarId, radarName, blipId, read, createdAt) and nextCursor.

A comment notification means a thread is worth reading: call list_comments on its blipId. A mention is never folded: two mentions are two lines. A notification on a Helpdesk radar may quote a client, and is marked external and fenced as data.

mark_notifications_read

Clears notifications that have been dealt with. It deletes nothing: the notification stays, and read: false puts it back. It also closes the folding window, so the next event on the same blip starts a fresh line.

  • Scope: radars:write. Writes.
  • Required: one of ids, radarId or all.
  • Optional: ids (1 to 200 UUIDs), radarId (UUID: everything outstanding on one radar), all (the literal true: everything; prefer ids), read (boolean: false puts one back as unread, and only works with ids).
  • Returns: the result and the new unreadTotal.
{ "ids": ["a4f1b8c2-77d0-4e19-9b3a-0c6d5e2f1a88"] }

mark_notifications_seen

Marks the notification tray as seen without marking items read or changing delivery settings. Use mark_notifications_read to finish individual items.

  • Scope: radars:write. Writes. Idempotent.
  • Arguments: none.

get_notification_settings

Reads your email and push preferences and your notification level for each radar you can read. It changes nothing, and this connection cannot mute or enable anything.

  • Scope: no scope is checked beyond a valid connection, so it works with radars:read. Read-only.
  • Arguments: none.

Account and discovery

whoami

Reports the On My Radar account this connection acts as, and what the connection was granted. Call it first if you need to know whether you can do something, so you can tell "I was not granted that" from "my person cannot do that".

  • Scope: no scope is checked beyond a valid connection. Read-only.
  • Arguments: none.
  • Returns: id, email, name, isAdmin, appUrl, scopes (the scopes this connection holds, or null), agent (id, name, handle and mention when this connection is bound to an agent, otherwise null) and voice (granted and default, or null).

list_capabilities

Returns the inventory of web features and their MCP equivalents, and where the human-only controls live. Use it to find out whether something you want is possible, and where to send the person if it is not. It is also published as the resource onmyradar://capabilities.

  • Scope: no scope is checked beyond a valid connection. Read-only.
  • Arguments: none.

The tool itself says to use the live tool list for current input schemas. This reference was written from the server's code at one point in time, and the live list is authoritative.

Next