Skip to main content
Glama

particle_alert_create

Create an alert that watches a single entity and emails you 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.

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).

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.

Input Schema

TableJSON 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 (guest/panelist/correspondent/audience). 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).
entitiesYesThe 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.
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 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.
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. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the single destructiveHint=false annotation, the description discloses side effects and constraints: the alert backfills the past week without sending emails, filters apply persistently across all channels, speaker_roles is rejected for ENTITY_MENTION, and kind is fixed at creation. This gives an agent an accurate model of what will happen.

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?

The description is longer than average but is organized into a clear purpose paragraph, a filters paragraph, and a behavior/forward-reference paragraph. It is front-loaded with the core action and each section earns its place, though a small amount of duplication with the exhaustive schema is present.

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 complex creation tool with nine parameters, no output schema, and minimal annotations, the description covers the preconditions, filter semantics, error condition, post-creation backfill, and downstream usage. The response shape is implied by the statement that the created alert id feeds the other alert tools, which is sufficient for the agent to invoke correctly.

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 coverage is 100% and the schema entries are already very detailed, so the description does not need to compensate. It adds useful workflow framing (e.g., entity slugs come from resolve tools, one alert per entity) but mostly restates what the schema already documents, keeping this at the baseline.

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?

The description opens with a specific verb and resource: 'Create an alert that watches a single entity and emails you...' and immediately distinguishes the two kinds (ENTITY_MENTION vs PODCAST_SPEAKER). It also names related tools in the workflow, so the tool's role is unambiguous.

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?

It gives explicit workflow guidance: resolve an entity first with particle_entity_resolve, then create with the returned slug, and use particle_alert_preview before committing. It also tells the agent to call the tool once per entity and notes that the resulting id feeds subsequent alert tools.

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