Skip to main content
Glama

press_release_monitor

Monitor press releases from PR Newswire, Business Wire, and GlobeNewswire by keyword. Returns company, date, category, and summary per release.

Instructions

Press Release Monitor returns keyword-matched press releases from PR Newswire, Business Wire and GlobeNewswire RSS feeds — company, publish date, category and summary, one row per release. Billed to your own Apify account: ~$0.001 per result (Apify free-plan price, lower on paid plans).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourcesNoWire sources — Select which press-release wires to read, e.g. prnewswire. Leave empty to read all three. Each source is fetched as its own public RSS feed, so a wire that is briefly unavailable produces one error row instead of failing the whole run. Options: prnewswire = PR Newswire; businesswire = Business Wire; globenewswire = GlobeNewswire.
keywordsNoKeywords — Enter keywords to match against each release's title and summary, e.g. funding, acquisition. Case-insensitive substring match; a release needs only one hit to pass. Leave empty to keep every release from the selected wires.
sinceHoursNoOnly releases from the last N hours — Enter how many hours back to keep releases, e.g. 24. Releases without a parseable publish date are dropped when this is set. Leave at 0 to disable the time filter and keep every release currently in the feed.
includeBodyNoFetch full release text — Turn this on to fetch each release's page and add up to 8,000 characters of plain-text body. Only works for PR Newswire and GlobeNewswire — Business Wire's own website blocks non-browser requests, so its body is always null.
maxItemsPerSourceNoMax items per source — Enter the most releases to keep per wire after filtering, e.g. 100. Each wire's RSS feed only ever contains its latest 20-50 releases, so this mostly matters when you run on a tight schedule and want to cap cost.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and delivers valuable operational context: billing to the caller's own Apify account, a per-result price (~$0.001, lower on paid plans), and one-row-per-release output semantics. It stops short of stating rate limits, pagination, or auth setup, but the cost/billing disclosure is genuinely additive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, and the core capability is front-loaded before the pricing note. Every clause earns its place.

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?

For a read-only, zero-required-param scraper with no output schema, the description gives sufficient scope, returned fields, and cost expectations. Since no annotations exist, it would be slightly stronger with an explicit read-only/no-mutation statement, but nothing essential for correct invocation is missing.

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%, so each of the five parameters is already fully documented in the schema (including the enum titles, error-row behavior, and the Business Wire body caveat). The description adds no parameter-level syntax or format detail, so baseline 3 applies.

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 (returns keyword-matched press releases), names the exact three source wires, and enumerates the returned fields (company, publish date, category, summary). An agent can distinguish this from google_news_scraper and the other siblings purely from the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The text is purely descriptive of behavior and pricing; it never says when to choose this over google_news_scraper or the other sibling scrapers, nor any when-not condition. Usage is only faintly implied by the tool name, so guidance is effectively absent.

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