CheckFlow

List webhooks

list_webhooks

Read-onlyIdempotent

The workspace's webhook subscriptions: which events are being posted where. Newest first, because the caller is usually auditing what has been set up rather than looking one up by name. Administrators can also see them in the app, under Team Management > Webhooks. This is also the way to find out whether an integration that thinks it subscribed actually did. Read isActive on every row: a paused subscription keeps its id, its event, its target and its scope, and is simply skipped when the event fires. Nothing is queued while it is paused and nothing is replayed when it resumes. When isActive is false, read disabledReason before saying anything about it: present means the platform switched it off after ten consecutive events failed to be delivered, absent means a person paused it on purpose, and those need opposite advice. consecutiveFailures on an active row is the early warning -- anything above zero means the receiver is currently missing events. Reactivating is update_webhook with isActive true, which clears the counter and the reason; it replays nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_webhooks"
  }
}

Input Schema

Name	Required	Description
`sort`	No	Order, as field or field:asc / field:desc. One of: createdDateTime, eventType, targetUrl. Default createdDateTime:desc.
`after`	No	The nextCursor from the previous reply. Send the same filters alongside it.
`source`	No	Only the subscriptions carrying this label, matched without regard to case. This is what the label is for: an integration that sets subscriptions up on a customer's behalf stamps its own name on them and finds them again with this rather than remembering ids. 'ALL' means the label ALL here, unlike v2, where that word is the sentinel for no filter and a subscription labelled with it is unfindable.
`isActive`	No	true for the subscriptions that are delivering, false for the paused ones. Omit for both.
`pageSize`	No	Results per page, 1-100. Default 50. A value outside the range is not refused; the default of 50 is used instead.
`eventType`	No	Only the subscriptions to this event. Exactly one of: new_checklist, task_completed, file_uploaded, checklist_completed, comment_created, task_assigned, data_set.record.created, data_set.record.updated, data_set.record.deleted. Matched exactly, case included; anything else is refused rather than ignored, because a filter that was quietly dropped would answer with every subscription the workspace has and read as a workspace subscribed to everything.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description explains paused subscription behavior in detail: the subscription keeps its id but is skipped when events fire, nothing is queued while paused, and nothing is replayed on resume. It also distinguishes platform-disabled from human-paused rows via disabledReason and explains consecutiveFailures as an early warning, which is exactly the kind of operational context annotations cannot provide.

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 purpose is front-loaded, and most sentences carry high-value behavioral warnings about isActive, disabledReason, and consecutiveFailures. The sentence about administrators seeing webhooks under Team Management > Webhooks is useful background but not essential for an agent, keeping it just below maximum conciseness.

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?

There is no output schema, but the description compensates by explaining the key row fields an agent will encounter: isActive, disabledReason, and consecutiveFailures. Combined with the rich schema, this is complete enough for an agent to call the tool and interpret paused versus active subscriptions 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 description coverage is 100%, and the schema itself documents all six parameters thoroughly, including sort syntax, cursor reuse, source matching rules, isActive behavior, pageSize bounds, and eventType validation. The description mentions "newest first" but does not add meaning beyond the schema for the remaining filters, so the baseline 3 is appropriate.

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+resource: "The workspace's webhook subscriptions: which events are being posted where." It also distinguishes the typical audit/list use from looking one up by name, so an agent can tell this apart from get_webhook without opening the schema.

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?

It gives clear usage context: auditing what has been set up, checking whether an integration actually subscribed, and using update_webhook to reactivate. It implies rather than explicitly names get_webhook as the lookup-by-name alternative, and does not discuss list_webhook_deliveries for delivery inspection, so it falls short of full when/when-not guidance.

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

All CheckFlow 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.