CatchAll (by NewsCatcher)

by com.newscatcherapi.catchall-mcp

Overview Discussions Admin

Get Webhook History

get_webhook_history

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.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number for pagination (default: 1).
`api_key`	No	CatchAll API key. Optional if provided via x-api-key header or CATCHALL_API_KEY env var.
`page_size`	No	Number of results per page (default: 50, max: 500).
`webhook_id`	No	Webhook ID to fetch history for. Mutually exclusive with `resource_type`/`resource_id`.
`resource_id`	No	The ID of the job/monitor/monitor_group.
`resource_type`	No	Resource type: 'job', 'monitor', or 'monitor_group'. Required together with `resource_id` when `webhook_id` is not given.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedAug 13, 2026

addedInput schema / properties / resource_id / default
```
Added value: +""
```
addedInput schema / properties / resource_type / default
```
Added value: +""
```

changedInput schema / properties / resource_type / description

Previous value: -"Resource type: 'job', 'monitor', or 'monitor_group'."New value: +"Resource type: 'job', 'monitor', or 'monitor_group'.\nRequired together with `resource_id` when `webhook_id` is not given."

addedInput schema / properties / webhook_id

Added value: +{
+  "default": "",
+  "description": "Webhook ID to fetch history for. Mutually exclusive with\n`resource_type`/`resource_id`.",
+  "type": "string"
+}

removedInput schema / required

Removed value: -[
-  "resource_type",
-  "resource_id"
-]

First observedJul 9, 2026

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that manual test deliveries are included only in webhook mode, a useful behavioral nuance. However, it doesn't explicitly state the operation is read-only, nor does it mention pagination limits or error conditions, though some of these are implied by the schema.

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?

The description is concise and well-structured: a clear opening sentence followed by a bulleted list of the two modes. Every sentence serves a purpose, and the key information is front-loaded.

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?

Given the tool's complexity (two modes, mutual exclusivity), the description covers all critical usage aspects. The schema documents parameter details, and the output schema documents the return format. Nothing essential is missing for an agent to call this tool correctly.

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 all parameters are documented. The description adds significant value by explaining the two modes, the relationship between resource_type and resource_id, and the mutual exclusivity with webhook_id. It also clarifies that manual test deliveries only appear in webhook mode, which is not in the schema.

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 clearly states the tool retrieves webhook delivery history and distinguishes two query modes: by resource (resource_type + resource_id) or by webhook (webhook_id). This is specific and differentiates it from siblings like get_webhook (which likely fetches webhook configuration) and list_webhooks.

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

Usage Guidelines4/5

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

The description explicitly instructs to query in exactly one of two modes and explains when to use each, including a note that manual test deliveries only appear in webhook mode. It doesn't explicitly name alternative tools or state when not to use this tool, but the guidance is clear and actionable.

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

All CatchAll (by NewsCatcher) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?