Dutify

pm_list_webhooks

Read-onlyIdempotent

List webhook subscriptions in the current workspace. By default only the webhooks the caller created are listed; pass all: true to list every webhook in the workspace (needs the MANAGE_WEBHOOKS permission, else 403). The HMAC secret is NOT included. Pass url to return only the webhooks whose URL matches it exactly. Each entry reports scopeType, scopeEntityIdentifier, scopeEntityName and includeSecurityBugs; for a FEEDBACK_BOARD scope, scopeEntityIdentifier is the board UUID, also when it was set by slug. API-key scope: webhooks:read.

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": "pm_list_webhooks"
  }
}

Input Schema

Name	Required	Description
`all`	No	List every webhook in the workspace, not only the caller's (needs MANAGE_WEBHOOKS)
`url`	No	Optional exact-match URL filter
`account`	No	Multi-account auth only: name of the account from X-Dutify-Accounts to use for this call. Ignored in single-account mode (X-API-Key header). When multiple accounts are configured and this is omitted, the call fails with ACCOUNT_REQUIRED listing the available names. list_accounts never requires a selection.
`workspace`	No	Workspace identifier or exact name for this call. Overrides the configured workspace. For personal keys, discover candidates with list_workspaces and select explicitly. Does not change other calls or expand a workspace key's access.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / all

Added value: +{
+  "description": "List every webhook in the workspace, not only the caller's (needs MANAGE_WEBHOOKS)",
+  "type": "boolean"
+}

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / url

Added value: +{
+  "description": "Optional exact-match URL filter",
+  "type": "string"
+}

First observedOct 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond: it discloses that the HMAC `secret` is deliberately omitted from results, that `all: true` requires MANAGE_WEBHOOKS or the call fails with 403, and that the API-key scope is `webhooks:read`. Those are exactly the operational facts an agent needs before calling.

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?

Four sentences, front-loaded with the core action, then filtered by parameter, then return shape, then API-key scope. Dense but nearly every clause carries information; the return-field enumeration is slightly listy but justified because there is no output schema.

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?

With no output schema, the description compensates by naming the return fields (scopeType, scopeEntityIdentifier, scopeEntityName, includeSecurityBugs) and calling out the exclusion of `secret`. Combined with the auth-scope note and permission failure mode, an agent has everything needed to invoke and interpret this read tool.

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 the baseline is 3, but the description adds genuine semantics: the default-vs-all behavior and its permission cost, the exact-match nature of `url`, and the notable edge case that scopeEntityIdentifier is a board UUID for FEEDBACK_BOARD scopes even when set by slug. The `account` and `workspace` parameters are left entirely to the schema, which is acceptable given full coverage.

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?

Opens with a specific verb and resource ('List webhook subscriptions in the current workspace'), which immediately separates it from pm_get_webhook (single) and pm_list_webhook_deliveries (delivery log). The scope is bounded to the current workspace, so an agent can select it 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?

Clearly explains the default behavior (only the caller's webhooks), the opt-out via `all: true`, the permission prerequisite and the 403 failure mode, and the exact-match `url` filter. It stops short of naming sibling alternatives such as pm_get_webhook for a single subscription, so it earns a 4 rather than 5.

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

All Dutify 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?