Skip to main content
Glama

particle-pro

by pro.particle
OverviewDiscussionsAdmin

particle_alert_update

Destructive

Update an existing alert. Only the fields you pass change; the entities and notifications lists, when provided, replace the whole set (pass a single entity slug from the resolve tools, same as particle_alert_create — an alert watches exactly one entity). A KEYWORD_MENTION alert takes a new keyword instead of entities. Use is_active to pause or resume an alert without deleting it. An alert's kind is fixed at creation — to change it, create a new alert.

Notification changes affect future recurring email delivery to external recipients; resuming an alert restarts delivery to its configured destinations. Alert emails follow delivery_cadence until paused or deleted. Only recipients verified for your organization receive alert emails; pending recipients may be saved but stay silent until verified.

The optional filters object replaces the alert's filter set wholesale — omit to leave the existing filters unchanged, send {} to clear all filters. Same four axes as particle_alert_create.filters: languages, relevance (EVERYTHING/RELEVANT), source_popularity (ANY/POPULAR), and speaker_roles (PODCAST_SPEAKER alerts only — sending it on an ENTITY_MENTION alert returns unprocessable_entity).

Alerts are not covered by zero data retention: the alert's definition and its matched results are stored as part of the alerts feature.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoNew title.
filtersNoReplace the alert's filter set wholesale. Omit to leave the existing filters unchanged; send an empty object {} to clear all filters. Same four axes as particle_alert_create.filters (languages, relevance, source_popularity, speaker_roles).
keywordNoReplacement phrase for a KEYWORD_MENTION alert; omit to leave it unchanged. Not accepted on other kinds. Matches already recorded keep the phrase they fired on.
alert_idYesAlert id to update.
entitiesNoReplacement watch target as a single entity slug (from the resolve tools). When provided, replaces the entire existing watch list — exactly one entity; omit to leave entities unchanged. Not accepted on KEYWORD_MENTION alerts.
is_activeNoPause (false) or resume (true) the alert.
descriptionNoNew description.
notificationsNoReplacement recipients for recurring alert emails. Only recipients verified for your organization receive alert emails; pending recipients stay silent until verified. When provided, replaces the entire existing set; omit to leave them unchanged.
output_formatNoOutput serialization. 'markdown' (default) returns the LLM-facing rendering. 'json' returns the structured payload as JSON text — use only for programmatic chaining where exact field extraction matters; the JSON shape is larger and noisier for an LLM to read.
delivery_cadenceNoNew delivery cadence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / notifications / description
      Previous value: -"Replacement notification emails. When provided, replaces the entire existing set; omit to leave them unchanged."New value: +"Replacement recipients for recurring alert emails. Only recipients verified for your organization receive alert emails; pending recipients stay silent until verified. When provided, replaces the entire existing set; omit to leave them unchanged."
  2. Changed2 schema fields changed
    • changedInput schema / properties / entities / description
      Previous value: -"Replacement watch target as a single entity slug (from the resolve tools). When provided, replaces the entire existing watch list — exactly one entity; omit to leave entities unchanged."New value: +"Replacement watch target as a single entity slug (from the resolve tools). When provided, replaces the entire existing watch list — exactly one entity; omit to leave entities unchanged. Not accepted on KEYWORD_MENTION alerts."
    • addedInput schema / properties / keyword
      Added value: +{
+  "description": "Replacement phrase for a KEYWORD_MENTION alert; omit to leave it unchanged. Not accepted on other kinds. Matches already recorded keep the phrase they fired on.",
+  "maxLength": 100,
+  "type": "string"
+}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond the destructiveHint/openWorldHint annotations: replacement (not merge) semantics for entities, notifications, and filters, the {} vs omit distinction for filters, notification effects on future recurring email delivery, verified-recipient gating, cadence behavior, and the explicit disclosure that alerts are not covered by zero data retention.

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 core update semantics and then organizes remaining detail into distinct paragraphs (replacement rules, delivery/recipients, filters, retention). The filters paragraph duplicates the schema's filters description fairly closely, which is the main source of redundancy.

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 10-parameter mutation tool with no output schema and a nested filters object, the description covers the behaviors an agent actually needs: partial-update semantics, kind constraints, replacement vs omit, error conditions (speaker_roles on ENTITY_MENTION), and the retention caveat.

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 cross-parameter semantics the schema states only per-field: keyword vs entities mutual exclusivity by alert kind, and the wholesale replacement behavior of the nested filters object including the {} clears-all case. It largely mirrors the schema's filter documentation, which caps it at 4.

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+resource ('Update an existing alert') and immediately disambiguates the update model: only passed fields change, while entities/notifications replace wholesale. It also draws the boundary against particle_alert_create by noting an alert's kind is fixed at creation and a new alert is needed to change it.

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 context: use resolve tools for entity slugs, use is_active to pause/resume instead of deleting, and create a new alert to change kind. It does not explicitly route between particle_alert_get/list/preview, but the update-vs-create-vs-delete boundary is well covered.

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

All particle-pro 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