CatchAll

Newscatcher CatchAll MCP Server

MCP server for the NewsCatcher CatchAll Web Search API.

Quick Start — Use Our Hosted Server

You don't need to clone or run this repo to use the MCP — NewsCatcher runs a hosted instance:

https://catchall-mcp.newscatcherapi.com/mcp?apiKey=YOUR_CATCHALL_API_KEY

Get a CatchAll API key at platform.newscatcherapi.com, then connect:

{

"mcpServers": { "catchall": { "type": "http", "url": "https://catchall-mcp.newscatcherapi.com/mcp?apiKey=YOUR_CATCHALL_API_KEY" } } }

Or via Claude Code CLI:

claude mcp add --transport http catchall "https://catchall-mcp.newscatcherapi.com/mcp?apiKey=YOUR_CATCHALL_API_KEY"

Full integration docs: https://www.newscatcherapi.com/docs/web-search-api/integrations/mcp

Prefer to run the server yourself (locally or self-hosted)? See Running below.

Tool To Endpoint Mapping

Jobs

Job listing filters: list_user_jobs supports search, ownership, project_id,

and mode (base or lite) filters in addition to page/page_size.

Monitors

Webhooks

Webhook notes: create_webhook accepts an optional project_id to attach the

webhook to a project on creation. list_webhooks also accepts an optional project_id

to filter to webhooks belonging to a specific project. get_webhook_history queries in

one of two modes — pass resource_type + resource_id for a job/monitor/monitor_group's

deliveries, or pass webhook_id for everything delivered through one webhook (exactly

one mode per call). Manual test deliveries (test_webhook) only appear in webhook mode

and are recorded with resource_type: "test".

Projects

Project resources: resource_type is one of job, monitor, dataset,

monitor_group, or webhook. A webhook can belong to several projects at once.

delete_project with delete_resources=true deletes the contained jobs, monitors,

datasets, and monitor groups, but webhooks are only detached — never deleted — and the

response's deleted_resources reports them under a webhook_unlinked count.

Datasets

CSV uploads (v1.6.1): create_dataset_from_csv and append_csv_to_dataset take

the CSV content in the file parameter — raw CSV text or standard base64. They

never read a path from the server's filesystem, so they stay safe on a remote/hosted

MCP. Inline CSV content is capped at a hard 10 MB (after base64 decoding).

create_dataset_from_csv also accepts the new optional project_id field.

Entities

`external_entity_id` (v1.6.3): create_entity and update_entity accept an optional

external_entity_id string — a customer-supplied identifier that links the entity to a

record in an external system. `project_id` (v1.8.0): list_entities accepts an

optional project_id to filter to entities belonging to a specific project.

Source Groups

Source groups (v1.8.0): named, reusable domain allowlists (public groups plus any

organization-visibility groups your organization can access). list_source_groups

returns each group's slug, name, and description. submit_query accepts an optional

source_groups list of slugs (max 20 per job) that scopes fetching to those domain

allowlists. The attached groups are echoed back as source_groups in the job status and

results.

User & Meta

Authentication

API key precedence (highest to lowest):

1. api_key tool parameter
2. x-api-key request header
3. Authorization: Bearer request header
4. URL query parameter ?apiKey=...
5. CATCHALL_API_KEY environment variable

check_health and get_version do not require API key auth.

Hosted deployment (FastMCP Gateway)

When deployed via fastmcp.app, a stateless gateway sits in front of the server. The gateway forwards HTTP headers to the backend but not URL query parameters. Use the x-api-key header or CATCHALL_API_KEY environment variable instead of ?apiKey=.

Claude Code / Cursor:

{

"mcpServers": { "catchall": { "type": "http", "url": "https://YOUR-DEPLOYMENT.fastmcp.app/mcp", "headers": { "x-api-key": "YOUR_API_KEY" } } } }

Or via CLI:

claude mcp add --transport http catchall "https://YOUR-DEPLOYMENT.fastmcp.app/mcp" \

--header "x-api-key: YOUR_API_KEY"

Direct server access (no gateway): ?apiKey=YOUR_KEY in the URL still works.

Core Workflow (Jobs)

1. Optional: call initialize_query to preview validators/enrichments/date window.
2. initialize_query is preview-only (it does not create a job) and suggestions are non-deterministic.
3. Submit with submit_query (query required). You can send only query; omitted optional fields are auto-selected/generated.
4. Optional fields are independent: provide any subset (for example, custom validators only), omitted ones are still auto-generated.
5. start_date/end_date filter web page discovery dates, not event dates in extracted content.
6. For event-time accuracy, use event-focused validators/enrichments and verify event_date in pulled results.
7. Poll get_job_status: first check after ~1-2 minutes, then every 30-60 seconds, stop on completed or failed.
8. Pull with pull_results; partial data appears during enriching.
9. Paginate while page < total_pages to retrieve all available records.
10. Use continue_job only to process more records (cost-affecting). It applies only to jobs originally submitted with limit.
11. continue_job.new_limit is optional; if omitted, API defaults to your plan maximum.
12. page/page_size/total_pages represent already-available records; use progress_validated < candidate_records to detect if more records may still appear.

Limit vs Page Size

• limit (submit_query, continue_job) controls how many records are processed and therefore affects cost. If provided, must be >= 10. Omit to retrieve everything up to your plan's maximum.
• page_size (pull_results, list_user_jobs) controls pagination only and does not affect processing cost.
• pull_results.page_size default is 100.
• page_size range is 1..1000.
• pull_results response includes error (failed jobs) and limit (applied job limit).

API-Enforced Monitor Constraints

• create_monitor.backfill=true: reference job end_date must be within the last 7 days.
• create_monitor.backfill=false: reference job age constraint does not apply.
• Monitor minimum schedule frequency depends on plan.
• create_monitor supports optional limit (minimum 10), backfill (default true), timezone, webhook_ids, and project_id.
• Webhooks are centralized in v1.5.3: register them with create_webhook, then attach by ID via create_monitor.webhook_ids / update_monitor.webhook_ids (no inline webhook config).
• Monitors are only supported for base jobs (not lite).
• enable_monitor supports optional backfill.
• update_monitor updates webhook_ids, run limit, schedule, and/or timezone (pass webhook_ids=[] to clear assignments; timezone is ignored unless schedule is also set).
• list_monitors supports pagination via page and page_size plus search, ownership, and project_id filters; it returns total, page, page_size, total_pages, monitors.

Enrichment Output Notes

• `enrichment.enrichment_co