Skip to main content
Glama

Particle Alert Create

particle_alert_create
Destructive

Create an alert that watches a single entity and sets up recurring email delivery to external recipients whenever it is mentioned on a podcast episode (kind=ENTITY_MENTION) or appears as a speaker (kind=PODCAST_SPEAKER). Pass the entity slug from a resolve tool — resolve a name with particle_entity_resolve, then create the alert with the slug it returns. An alert watches exactly one entity; to cover several entities, call this tool once per entity.

An active alert emails future matches to its configured recipients at the selected 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.

When a name has no entity slug, or its entity has no podcast coverage (a startup known by a brand that differs from its legal name, a product, a drug, a code word), create a kind=KEYWORD_MENTION alert with keyword instead of entities. It fires whenever the phrase is spoken — the match particle_podcast_search_transcripts makes for a double-quoted keyword_search phrase (words adjacent and in order), not the looser unquoted match — so also set description to say what the phrase means; that is how same-name mentions of something else are filtered out.

Use the optional filters object to narrow what gets surfaced on every channel (matches list, realtime email, daily/weekly digest). Four independent axes: languages (BCP-47-like tags like ['en','pt-BR'] — empty means all languages), relevance (EVERYTHING returns on-target + incidental matches, RELEVANT narrows to on-target only — dropping passing mentions), source_popularity (ANY keeps every source, POPULAR keeps only matches from podcasts in the top 5% by chart popularity), and speaker_roles (PODCAST_SPEAKER alerts only — REPLACES the default appearance set GUEST/PANELIST/CORRESPONDENT/AUDIENCE/SOUNDBITE_SPEAKER; sending it on an ENTITY_MENTION alert errors with unprocessable_entity). ENTITY_MENTION alerts also take speaker_statement_characteristics, which fires only on mentions said a certain way: {"sentiment": ["negative"]} for negative mentions of a company, {"specificity": ["specific"], "temporal_orientation": ["future"]} for predictions about it, {"certainty": ["confident"]} for confident claims. Each mention line in the alert's matches carries its labels.

Billing: creating an active alert can move an eligible organization's subscription from its credit/trial phase to paid fixed-fee billing. Explain this possible billing change and obtain the user's explicit confirmation before creating an active alert. Creating a paused alert (is_active=false) does not trigger this billing transition.

After creation the alert immediately backfills matches from the past week (visible via particle_alert_list_matches) without sending emails for them. To see what an alert would catch BEFORE committing, use particle_alert_preview first. The created alert's id feeds particle_alert_get, particle_alert_update, particle_alert_delete, and particle_alert_list_matches.

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

NameRequiredDescriptionDefault
kindNoWhat signal to watch for. ENTITY_MENTION (default) fires whenever a watched entity is mentioned on a podcast episode. PODCAST_SPEAKER fires only when a watched person is themself an identified speaker: by default as guest/panelist/correspondent/audience or in an excerpted soundbite (SOUNDBITE_SPEAKER), never as host; speaker_roles replaces that set. KEYWORD_MENTION fires whenever keyword is spoken — use it when the name has no entity slug (a resolve tool finds nothing, or the right entity has no episodes). Kind is fixed at creation.
titleYesHuman-readable title for the alert (e.g. 'OpenAI mentions').
filtersNoPersistent narrowing applied to every surface the alert produces (matches list, realtime email, daily/weekly digest). Omit for no filters — every detected match is surfaced. See AlertFiltersInput for the four axes (languages, relevance, source_popularity, speaker_roles).
keywordNoKEYWORD_MENTION alerts only (and required for them): the phrase to watch, e.g. Lightfield. Matches like a double-quoted keyword_search phrase — the words adjacent and in order, ignoring case and punctuation, on whole words — in topic-discussion and interview segments, never ad reads, intros, or outros. Also set description to say what the phrase means (e.g. 'Lightfield, the AI-native CRM'); it is how same-name mentions of something else get filtered out. A phrase that matched more than 700 podcast episodes in the past week is rejected as too broad.
entitiesNoThe entity to watch, as a single slug from the resolve tools (particle_entity_resolve, particle_person_resolve, particle_company_resolve). Person, company, and place/other (knowledge-graph) slugs are all accepted; the resolved type is echoed back in the response. Exactly one for ENTITY_MENTION and PODCAST_SPEAKER — an alert watches a single entity, so create one alert per entity. Omit for KEYWORD_MENTION.
is_activeNoWhether the alert produces matches. Defaults to true. Set false to create it paused.
descriptionNoOptional longer description of what the alert is for.
notificationsNoEmail addresses for recurring alert notifications. Only recipients verified for your organization receive alert emails; pending recipients may be saved but stay silent until verified. At least one recipient must be deliverable. When omitted, defaults to your account email if available; otherwise pass at least one.
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_cadenceNoHow often matches are emailed: REALTIME (default, one email per match), DAILY (one bundled email each morning), or WEEKLY (one bundled email Monday).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / filters / properties / speaker_statement_characteristics
      Added value: +{
      +  "description": "ENTITY_MENTION alerts only — sending it on a PODCAST_SPEAKER or KEYWORD_MENTION alert returns unprocessable_entity. Keeps a match only when one of its mention lines was said the way you ask, the same filter particle_podcast_find_mentions takes: {'sentiment': ['negative']} for criticism of the watched entity, {'specificity': ['specific'], 'temporal_orientation': ['future']} for concrete predictions about it, {'certainty': ['confident']} for confident claims. Labels on one axis OR together, axes AND. Mention lines the filter does not accept are not marked as mentions and do not count. Put how something is said here, never in the alert's title or keyword.",
      +  "properties": {
      +    "certainty": {
      +      "description": "How sure the speaker sounds. 'confident' for flat assertions and high conviction; 'hedged' for maybe, I think, it could, and other hedging; 'neutral' for neither.",
      +      "items": {
      +        "enum": [
      +          "hedged",
      +          "neutral",
      +          "confident"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "sentiment": {
      +      "description": "The statement's tone. 'positive' for optimistic, bullish, approving or praising lines; 'negative' for skeptical, bearish, critical or worried ones; 'neutral' for lines that clearly lean neither way.",
      +      "items": {
      +        "enum": [
      +          "negative",
      +          "neutral",
      +          "positive"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "specificity": {
      +      "description": "Whether the line commits to something concrete. 'specific' for names, numbers, dates and mechanisms (concrete claims); 'vague' for generalities; 'neutral' for neither.",
      +      "items": {
      +        "enum": [
      +          "vague",
      +          "neutral",
      +          "specific"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "temporal_orientation": {
      +      "description": "Where the line points in time. 'future' for predictions, forecasts, plans and expectations; 'past' for looking back; 'present' for how things are now.",
      +      "items": {
      +        "enum": [
      +          "past",
      +          "present",
      +          "future"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / kind / description
      Previous value: -"What signal to watch for. ENTITY_MENTION (default) fires whenever a watched entity is mentioned on a podcast episode. PODCAST_SPEAKER fires only when a watched person is themself an identified speaker (guest/panelist/correspondent/audience). KEYWORD_MENTION fires whenever keyword is spoken — use it when the name has no entity slug (a resolve tool finds nothing, or the right entity has no episodes). Kind is fixed at creation."New value: +"What signal to watch for. ENTITY_MENTION (default) fires whenever a watched entity is mentioned on a podcast episode. PODCAST_SPEAKER fires only when a watched person is themself an identified speaker: by default as guest/panelist/correspondent/audience or in an excerpted soundbite (SOUNDBITE_SPEAKER), never as host; speaker_roles replaces that set. KEYWORD_MENTION fires whenever keyword is spoken — use it when the name has no entity slug (a resolve tool finds nothing, or the right entity has no episodes). Kind is fixed at creation."
  3. Changed1 schema field changed
    • changedInput schema / properties / notifications / description
      Previous value: -"Email addresses to notify. Each must already be verified for your organization (or belong to an org member). When omitted, defaults to your account email if available; otherwise pass at least one."New value: +"Email addresses for recurring alert notifications. Only recipients verified for your organization receive alert emails; pending recipients may be saved but stay silent until verified. At least one recipient must be deliverable. When omitted, defaults to your account email if available; otherwise pass at least one."
  4. Changed1 schema field changed
    • changedInput schema / properties / keyword / description
      Previous value: -"KEYWORD_MENTION alerts only (and required for them): the phrase to watch, e.g. Lightfield. Matches like a double-quoted keyword_search phrase — the words adjacent and in order, ignoring case and punctuation, on whole words — in topic-discussion and interview segments, never ad reads, intros, or outros. Also set description to say what the phrase means (e.g. 'Lightfield, the AI-native CRM'); it is how same-name mentions of something else get filtered out. A phrase that matched more than 7,000 podcast episodes in the past week is rejected as too broad."New value: +"KEYWORD_MENTION alerts only (and required for them): the phrase to watch, e.g. Lightfield. Matches like a double-quoted keyword_search phrase — the words adjacent and in order, ignoring case and punctuation, on whole words — in topic-discussion and interview segments, never ad reads, intros, or outros. Also set description to say what the phrase means (e.g. 'Lightfield, the AI-native CRM'); it is how same-name mentions of something else get filtered out. A phrase that matched more than 700 podcast episodes in the past week is rejected as too broad."
  5. Changed5 schema fields changed
    • changedInput schema / properties / entities / description
      Previous value: -"The entity to watch, as a single slug from the resolve tools (particle_entity_resolve, particle_person_resolve, particle_company_resolve). Person, company, and place/other (knowledge-graph) slugs are all accepted; the resolved type is echoed back in the response. Exactly one — an alert watches a single entity, so create one alert per entity."New value: +"The entity to watch, as a single slug from the resolve tools (particle_entity_resolve, particle_person_resolve, particle_company_resolve). Person, company, and place/other (knowledge-graph) slugs are all accepted; the resolved type is echoed back in the response. Exactly one for ENTITY_MENTION and PODCAST_SPEAKER — an alert watches a single entity, so create one alert per entity. Omit for KEYWORD_MENTION."
    • addedInput schema / properties / keyword
      Added value: +{
      +  "description": "KEYWORD_MENTION alerts only (and required for them): the phrase to watch, e.g. Lightfield. Matches like a double-quoted keyword_search phrase — the words adjacent and in order, ignoring case and punctuation, on whole words — in topic-discussion and interview segments, never ad reads, intros, or outros. Also set description to say what the phrase means (e.g. 'Lightfield, the AI-native CRM'); it is how same-name mentions of something else get filtered out. A phrase that matched more than 7,000 podcast episodes in the past week is rejected as too broad.",
      +  "maxLength": 100,
      +  "type": "string"
      +}
    • changedInput schema / properties / kind / description
      Previous value: -"What signal to watch for. ENTITY_MENTION (default) fires whenever a watched entity is mentioned on a podcast episode. PODCAST_SPEAKER fires only when a watched person is themself an identified speaker (guest/panelist/correspondent/audience). Kind is fixed at creation."New value: +"What signal to watch for. ENTITY_MENTION (default) fires whenever a watched entity is mentioned on a podcast episode. PODCAST_SPEAKER fires only when a watched person is themself an identified speaker (guest/panelist/correspondent/audience). KEYWORD_MENTION fires whenever keyword is spoken — use it when the name has no entity slug (a resolve tool finds nothing, or the right entity has no episodes). Kind is fixed at creation."
    • changedInput schema / properties / kind / enum
      Previous value: -[
      -  "ENTITY_MENTION",
      -  "PODCAST_SPEAKER"
      -]New value: +[
      +  "ENTITY_MENTION",
      +  "PODCAST_SPEAKER",
      +  "KEYWORD_MENTION"
      +]
    • changedInput schema / required
      Previous value: -[
      -  "title",
      -  "entities"
      -]New value: +[
      +  "title"
      +]
  6. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint=false / destructiveHint=true annotations: discloses the possible credit-to-paid billing transition and the need for explicit user confirmation, that paused alerts avoid it, that creation backfills the past week without emailing, that unverified recipients stay silent, and that alerts are excluded from zero data retention. These are exactly the operational facts an agent cannot infer from structured fields.

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?

Front-loaded with purpose and rightly dense on billing/backfill, but the long filters paragraph duplicates what the schema already documents in greater depth (language tag collapsing, popularity percentile, statement characteristics), padding a description that is already the longest part of the definition.

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, nested-object mutation with no output schema, the description covers everything an agent needs: the resolve-then-create prerequisite chain, kind selection, billing consent, backfill behaviour, recipient verification, DZR status, and which sibling tools consume the returned alert id. Nothing material is left to inference.

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; the description still adds cross-parameter meaning the schema only states piecemeal — that is_active=false sidesteps the billing transition, that entities and keyword are mutually exclusive by kind, and the coupling of keyword with the free-text description field for disambiguation. It restates the filters axes, but the workflow-level framing is genuine added value.

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 ('Create an alert that watches a single entity and sets up recurring email delivery') and enumerates the three signal kinds with what each fires on. It explicitly distinguishes itself from particle_alert_preview and the resolve tools, so an agent can place it in the workflow without reading 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 Guidelines5/5

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

Gives explicit routing rules: resolve a name first with particle_entity_resolve and pass the slug; use KEYWORD_MENTION when no slug exists or the entity lacks podcast coverage; call once per entity to cover several; use particle_alert_preview before committing. It also states when-not (paused alerts avoid billing, speaker_roles on ENTITY_MENTION errors).

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