CatchAll MCP server

• add_dataset_entitiesFree

  Add existing entities to a dataset.

• add_project_resourcesFree

  Add one or more resources to a project. Webhooks are first-class project resources: a webhook can belong to several projects at the same time, and deleting a project only detaches its webhooks — it never deletes them.

• append_csv_to_datasetFree

  Append entities from a CSV file to an existing dataset. Parses the CSV and appends its entities to the dataset. Each row must have a `name` column; include a `domain` or `description` column (or both) for meaningful enrichment. Duplicate rows (by name) are skipped. To create a new dataset from a CSV, use `create_dataset_from_csv` instead.

• assign_webhook_resourceFree

  Map a resource (job, monitor, or monitor_group) to a webhook. Use when: - You want a webhook to fire for a specific job or monitor's deliveries.

• check_healthFree

  Check API health status. This tool maps to GET /health and does not require an API key.

• continue_jobFree

  Expand a job by processing more records beyond the initial limit. This increases the number of records the system processes (which costs additional credits). Only use this when the user wants MORE data processed. This only applies to jobs originally submitted with `limit`. If a job was submitted without `limit`, there is nothing to continue. The new_limit must be greater than the previous limit when provided. If omitted, API defaults to your plan maximum.

• create_datasetwrite actionFree

  Create a new dataset. Datasets are collections of entities (companies/people). Connect a dataset to a job via `submit_query(connected_dataset_ids=[...])` to narrow retrieval scope.

• create_dataset_from_csvwrite actionFree

  Create a new dataset by uploading a CSV file. The CSV must have at least a `name` column. For meaningful entity enrichment each row should also include a `domain` column or a `description` column (or both) — a row with only a name is accepted but produces lower-quality enrichment. Additional columns are mapped to entity attributes. Max file size is plan-dependent. To add CSV rows to an existing dataset, use `append_csv_to_dataset` instead.

• create_entities_batchwrite actionFree

  Create multiple entities in one call.

• create_entitywrite actionFree

  Create a single entity (a company or person). ``name`` is required plus at least one identifying field: either ``description`` or ``additional_attributes.company_attributes.domain``.

• create_monitorwrite actionFree

  Create a recurring monitor from a completed job. Monitors re-run a job's query on a schedule. Use the explore -> refine -> automate pattern: submit a job, refine until results match, then create a monitor. The schedule is defined in natural language (e.g., 'every day at 9 AM EST'). Always include a timezone (in the schedule text or via the `timezone` arg). API-enforced constraints apply: - If `backfill=true`, reference job end_date must be within the last 7 days - If `backfill=false`, reference job age does not matter - Minimum schedule frequency depends on your plan Webhooks are now centralized: register them with `create_webhook`, then pass their IDs here via `webhook_ids` (there is no inline webhook config anymore).

• create_projectwrite actionFree

  Create a new project. Projects group related resources (jobs, monitors, datasets, monitor_groups) so you can organize work and filter listings by `project_id`.

• create_webhookwrite actionFree

  Create a new webhook endpoint. Use when: - You want to register a URL to receive job or monitor result deliveries. - You need a webhook_id to attach to a monitor (via webhook_ids) or a job submission. - You want the webhook associated with a project from the start (pass `project_id`).

• delete_datasetwrite actionFree

  Permanently delete a dataset. The entities the dataset referenced are not deleted; only the dataset and its entity associations are removed.

• delete_entitywrite actionFree

  Permanently delete an entity.

• delete_jobwrite actionFree

  Permanently delete a job and its results. Use when: - You want to remove a job you no longer need from your account.

• delete_monitorwrite actionFree

  Permanently delete a monitor and stop its scheduled runs. Use when: - You want to remove a monitor entirely (use `disable_monitor` to only pause it).

• delete_projectwrite actionFree

  Delete a project. By default the project's resources (jobs, monitors, etc.) are detached but kept. Set `delete_resources=true` to also delete the contained jobs, monitors, datasets, and monitor groups. Webhooks are the exception: they are never deleted by this operation — an attached webhook is only detached from the project and keeps working (it may belong to other projects or resources independently of this one).

• delete_webhookwrite actionFree

  Permanently delete a webhook endpoint. Use when: - You want to remove a webhook from your account.

• disable_monitorFree

  Disable a monitor to stop its scheduled runs. The monitor can be re-enabled later with enable_monitor.

• enable_monitorFree

  Enable a previously disabled monitor to resume its scheduled runs.

• get_datasetFree

  Get a single dataset's details.

• get_dataset_statusFree

  Get the status history of a dataset (e.g. its enrichment progress over time).

• get_entityFree

  Get a single entity's details.

• get_job_statusFree

  Check the status of a submitted job. Call this after submit_query to see if your job is ready. Status progression: submitted -> analyzing -> fetching -> clustering -> enriching -> completed/failed IMPORTANT: Jobs take several minutes to process. First check after ~1-2 minutes, then poll every 30-60 seconds. Broad searches can take 10-30+ minutes; for long jobs, poll every 60-120 seconds. Do NOT call this tool in a tight loop. Stop polling when status is `completed` or `failed`. Treat `submitted`, `analyzing`, `fetching`, `clustering`, and `enriching` as active states and continue polling. You don't need to wait for completion to pull results. Partial results are available during `enriching` — call pull_results after ~2 minutes, then poll status every 30-60 seconds and pull again for fresher results. Do not stop pulling just because an intermediate pull is empty/unchanged. Use `progress_validated` vs `candidate_records` to track whether more results may still appear (`progress_validated < candidate_records`). If transport/session fails, resume using the same `job_id`.

• get_monitor_statusFree

  Get the status history of a monitor. Use when: - You want to see the timeline of a monitor's state changes (e.g. active, disabled, errored) and any related details.

• get_projectFree

  Get a single project's details.

• get_project_overviewFree

  Get a project's resource overview (counts grouped by resource type and status).

• get_user_limitsFree

  Retrieve plan features and current usage limits for your API key. Use when: - You want to know how many records/jobs/monitors your plan allows. - You want to check current usage against plan limits before running a large job.

• get_versionFree

  Get current API version. This tool maps to GET /version and does not require an API key.

• get_webhookFree

  Retrieve the full configuration of a specific webhook. Use when: - You want to inspect a webhook's URL, method, headers, or status by its ID.

• get_webhook_historyFree

  Get webhook delivery history, either for a resource or for a webhook. Query in exactly one of two modes: - By resource: pass `resource_type` + `resource_id` to see deliveries made for a specific job/monitor/monitor_group. - By webhook: pass `webhook_id` to see every delivery made through one webhook — including manual test deliveries (from `test_webhook`), which are not tied to a job or monitor and only appear in this mode.

• initialize_queryFree

  Preview suggested validators, enrichments, and date ranges before submitting. Use when: - You want to inspect/edit auto-generated validators/enrichments before submitting. - You want to preview date adjustments via `date_modification_message`. Do not use when: - You want to start processing immediately with final inputs (use `submit_query`). Key behavior: - Preview-only endpoint: does not create a job and does not start processing. - Suggestions are LLM-generated and not deterministic across calls. - To reuse suggestions, pass them explicitly to `submit_query`.

• list_dataset_entitiesFree

  List the entities contained in a dataset.

• list_datasetsFree

  List your datasets.

• list_entitiesFree

  List your entities.

• list_monitor_jobsFree

  List all jobs spawned by a monitor. Returns the history of scheduled runs for a monitor.

• list_monitorsFree

  List all your monitors. Returns all monitors with their schedule, status, reference query, and webhook config.

• list_project_resourcesFree

  List the resources contained in a project.

• list_projectsFree

  List your projects.

• list_resource_webhooksFree

  List the webhooks mapped to a specific resource (job/monitor/monitor_group). Use when: - You have a job or monitor ID and want to know which webhooks will fire for it.

• list_source_groupsFree

  List source groups (named domain allowlists). Use when: - You want to discover reusable, named sets of source domains (public groups plus any organization-visibility groups your organization can access). - You need a group's `slug` to attach to `submit_query` via `source_groups` to scope fetching to that domain allowlist.

• list_user_jobsFree

  List all jobs submitted by you. Returns your job history with IDs, queries, statuses, and timestamps.

• list_webhook_resourcesFree

  List the resources mapped to a webhook. Use when: - You want to see which jobs/monitors a webhook is attached to.

• list_webhooksFree

  List all your webhooks. Use when: - You want to see all webhook endpoints configured in your account. - You need to find a webhook_id to pass to monitors (via webhook_ids) or jobs.

• pull_job_csvFree

  Download a job's results as a CSV file. Use when: - You want the full job output as a CSV for offline analysis or export. - Prefer this over `pull_results` when the consumer needs spreadsheet/CSV format.

• pull_monitor_csvFree

  Download the latest monitor run's results as a CSV file. Use when: - You want the most recent monitor run output as a CSV for offline analysis or export. - Prefer this over `pull_monitor_results` when the consumer needs spreadsheet/CSV format.

• pull_monitor_resultsFree

  Retrieve the latest results from a monitor. Returns the most recent run's results including run_info, records, and all_records.

• pull_resultsFree

  Retrieve the results of a job. Can be called before completion for partial results, or after completion for the full set. Returns clustered, validated, and enriched web results. While job status is active, call this repeatedly (typically page=1) to refresh partial output. When job reaches completed, iterate all pages. If job fails, call once more to capture any partial output.

• remove_dataset_entitieswrite actionFree

  Remove entities from a dataset (the entities themselves are not deleted).

• remove_project_resourcewrite actionFree

  Remove a single resource from a project. This detaches the resource from the project without deleting the resource itself (e.g. removing a webhook only ends its membership in this project; the webhook keeps existing and stays attached to any other projects).

• remove_webhook_resourcewrite actionFree

  Unmap a resource from a webhook. Use when: - You want to stop a webhook from firing for a specific job or monitor.

• submit_querywrite actionFree

  Create a new CatchAll processing job from a natural-language query. Use when: - You want to start a new CatchAll web research run from a user query. - You want the API to fetch/process sources and then return structured results. Do not use when: - You want status for an existing job (use `get_job_status`). - You want records for an existing job (use `pull_results`). Key rules: - `query` is required. - You can submit with only `query`; omitted optional fields (`validators`, `enrichments`, `start_date`, `end_date`) are auto-selected/generated by the API. - Optional fields are independent: you can pass any subset (for example, custom `validators` but no `enrichments`), and omitted fields are still auto-selected/generated. - When `connected_dataset_ids` is set, the `query` must describe the **topic or event type only** (e.g. "M&A activity", "regulatory filings", "executive changes"). Do NOT write things like "for my companies", "for the selected list of companies", or "news about my watchlist" — the entity filtering is applied automatically by the connected dataset. Mentioning companies in the query when a dataset is attached is redundant and degrades retrieval quality. - When `connected_dataset_ids` is set, entity-relevance validators (e.g. `company_is_primary_subject`) are generated automatically by the API. Do NOT add them manually to `validators` — they are redundant and may conflict with the auto-generated ones. Only pass validators that describe the **event or topic**, not entity filtering. - `start_date` and `end_date` filter by web page discovery date, not event date. - Discovery dates and extracted event dates can differ. For event-time accuracy, use event-focused validators/enrichments and verify `event_date` in pulled results. - `end_date` must be after `start_date`. - Dates outside your plan lookback limits return API 400. - `limit` controls processed record count (cost-affecting). Omit it to retrieve everything up to your plan's maximum. If provided, must be >= 10. - `validators` / `enrichments` may be passed either as arrays or as JSON-string arrays (for client compatibility). - `validators[].type` must be `boolean` (if omitted, it defaults to `boolean`). - `enrichments[].type` supported values: text, number, date, option, url, company. Basic examples: - validators: `[{"name":"is_acquisition_event","description":"true if page describes an acquisition","type":"boolean"}]` - enrichments: `[{"name":"acquiring_company","description":"Extract acquiring company","type":"company"},{"name":"deal_value","description":"Extract announced deal value","type":"number"}]` Next step: - Save the returned `job_id`. - Poll `get_job_status` and call `pull_results` (partial results can appear before completion).

• test_webhookwrite actionFree

  Send a test delivery to a webhook endpoint. Use when: - You want to verify a webhook URL is reachable and correctly configured before attaching it to a monitor or job.

• trigger_webhookFree

  Manually trigger webhook delivery for a resource (job/monitor/monitor_group). Use when: - You want to (re-)send a webhook delivery on demand instead of waiting for the automatic dispatch — e.g. to replay a missed or failed delivery.

• update_datasetwrite actionFree

  Update a dataset's name and/or description.

• update_entitywrite actionFree

  Update an entity's name, description, external_entity_id, and/or attributes.

• update_monitorwrite actionFree

  Update a monitor's schedule, timezone, webhook assignments, and per-run limit. Note: reference_job_id cannot be modified through this endpoint. Webhooks are centralized — pass webhook IDs (from `create_webhook`/`list_webhooks`).

• update_projectwrite actionFree

  Update a project's name and/or description. Only the fields you provide are changed.

• update_webhookwrite actionFree

  Update an existing webhook's configuration. Use when: - You want to change a webhook's URL, method, headers, or other settings. - You want to enable or disable a webhook (set `is_active`). - Only the fields you provide are updated; omitted fields remain unchanged.

• validate_queryFree

  Check the quality of a query before submitting a job ("Check Query Quality"). Use when: - You want quick feedback on whether a query is well-formed for CatchAll before spending credits on a job. - You want concrete suggestions to improve a vague or overly broad query. Do not use when: - You want to preview auto-generated validators/enrichments (use `initialize_query`). - You want to actually run a search (use `submit_query`).

• –Code scanremote-only server, no package to scann/a
• Live reliabilityremote reachable in 1391ms20/20
• Tool poisoning61 tool descriptions checked13/15
• Auth qualityAPI key sent as a header8/15
• Maintenancelast push 3 days ago15/15
• Maintainer identitynamespace and repository owner differ; GitHub account older than a year6/10

Safety score

83/100

higher than 70% of 3,470 Web search servers

Tools

61

the typical Web search server has 5

Tools that change things

38%

typical: 0%. Fewer write tools means less an agent can break

Uptime

100%

of our recent checks; the typical remote Web search server answers 100%

Response time

816 ms

faster than 14% of 2,238 Web search servers

GitHub stars

1

more than 55% of 1,786 Web search servers

CatchAll: common questions

Is CatchAll MCP server safe?

Mostly: it is graded B (83/100). Read the CatchAll safety report

How do I install CatchAll?

It runs remotely at catchall-mcp.newscatcherapi.com. Add it to Claude Code, Cursor, VS Code or Claude Desktop with the snippets above, or call it through the mcp.market gateway without installing anything.

Does CatchAll need an API key?

Yes. The registry entry asks for x-api-key.

Is CatchAll maintained?

The last commit was 43 days ago (2026-09-22). The latest release is v1.6.5.

Is CatchAll up?

100% of our last 28 checks got an answer. We check remote servers about four times a day.

What can I use instead of CatchAll?

Servers from other publishers that do the same job: Brave Search MCP server, Free Search MCP server and Zotero MCP server.

How does CatchAll compare with other Web search MCP servers?

safety score 83/100 (higher than 70% of 3,470 Web search servers); tools 61 (the typical Web search server has 5); tools that change things 38% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.