Dutify

pm_update_webhook

Destructive

Partial-update a webhook subscription. Only fields present in the call are changed (pass-through PATCH-style semantics). Use active: false to pause deliveries without deleting. Updating eventTypes replaces the full subscribed set. Pass secret to rotate the HMAC signing secret: it is stored exactly as given and never returned, so keep your copy. Resuming (active: true) re-checks the stored URL. Re-scope with scopeType plus scopeEntityIdentifier (same values as pm_create_webhook), or pass clearScope: true to make the webhook workspace-wide again. includeSecurityBugs sets whether feature-request security bugs are delivered; omit it to keep the stored value. An API key can turn it off but not on (403): only a workspace admin signed in as a person can turn it on. The URL must be publicly reachable: Dutify refuses private, loopback, link-local, CGNAT and IPv6 ULA addresses, localhost, bare hostnames and *.svc / *.cluster.local names (400 WEBHOOK_URL_NOT_ALLOWED) at create, update and resume, and re-checks it on every attempt. Redirects are not followed; http:// is accepted for public addresses. API-key scope: webhooks:write.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "webhookIdentifier": "<webhookIdentifier>"
    },
    "name": "pm_update_webhook"
  }
}

Input Schema

Name	Required	Description
`url`	No
`name`	No
`active`	No	Toggle delivery on/off without deleting
`secret`	No	New HMAC signing secret (rotation); must not be blank; sent unchanged, never returned
`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.
`scopeType`	No	New scope; requires scopeEntityIdentifier when set
`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.
`clearScope`	No	true removes the scope (workspace-wide delivery); not with scopeType
`eventTypes`	No	Replacement event-type list (see pm_list_webhook_event_types)
`webhookIdentifier`	Yes	Webhook identifier
`includeSecurityBugs`	No	Feature requests: also deliver security bugs. Omit to keep the current value; an API key can only turn it off
`scopeEntityIdentifier`	No	The scoped entity: its identifier, a wiki space key, a board slug or id, or a request/bug short key (required when scopeType is set; requires scopeType)

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 27, 2026

addedInput schema / properties / clearScope

Added value: +{
+  "description": "true removes the scope (workspace-wide delivery); not with scopeType",
+  "type": "boolean"
+}

addedInput schema / properties / includeSecurityBugs

Added value: +{
+  "description": "Feature requests: also deliver security bugs. Omit to keep the current value; an API key can only turn it off",
+  "type": "boolean"
+}

addedInput schema / properties / scopeEntityIdentifier

Added value: +{
+  "description": "The scoped entity: its identifier, a wiki space key, a board slug or id, or a request/bug short key (required when scopeType is set; requires scopeType)",
+  "type": "string"
+}

addedInput schema / properties / scopeType

Added value: +{
+  "description": "New scope; requires scopeEntityIdentifier when set",
+  "enum": [
+    "SPACE",
+    "FOLDER",
+    "TASK_LIST",
+    "TASK",
+    "WIKI_SPACE",
+    "WIKI_PAGE",
+    "FEEDBACK_BOARD",
+    "FEEDBACK_REQUEST",
+    "FEEDBACK_BUG"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / secret / description

Previous value: -"New HMAC signing secret (rotation); sent unchanged, never returned"New value: +"New HMAC signing secret (rotation); must not be blank; sent unchanged, never returned"

Changed2 schema fields changedOct 27, 2026

changedInput schema / properties / eventTypes / description

Previous value: -"Replacement event-type list (dash-cased)"New value: +"Replacement event-type list (see pm_list_webhook_event_types)"

addedInput schema / properties / secret

Added value: +{
+  "description": "New HMAC signing secret (rotation); sent unchanged, never returned",
+  "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?

Goes far beyond the annotations: discloses that the secret is stored verbatim and never returned, that eventTypes replaces the whole set, that resume re-validates the URL, and that an API key can disable but not enable includeSecurityBugs (403). It also enumerates the exact URL classes rejected and the WEBHOOK_URL_NOT_ALLOWED error, plus redirect and http:// handling — precisely the mutation risk that destructiveHint=true implies.

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?

Purpose and PATCH semantics are front-loaded, and most sentences carry unique operational information. A few clauses duplicate the schema text (e.g. 'stored exactly as given and never returned' mirrors the secret parameter description), adding slight redundancy across ten sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter mutation tool with no output schema, it covers auth, error codes, URL validation and field-level side effects thoroughly. The one gap is response shape — nothing states whether the updated webhook object is returned, and with no output schema the description is the only place that could be said.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 83% (baseline 3), but the description adds real meaning: replacement-vs-merge semantics for eventTypes, the mutual exclusion of clearScope and scopeType, the asymmetric permission on includeSecurityBugs, and 'omit to keep stored value'. These are behavioral rules the schema alone does not convey.

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 ('Partial-update a webhook subscription') and immediately pins down the scope semantics as pass-through PATCH. It distinguishes itself from siblings by referencing pm_create_webhook (shared scope values) and pm_delete_webhook (the alternative that active:false avoids).

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?

Gives clear conditional guidance: use active:false to pause instead of deleting, clearScope to un-scope, scopeType+scopeEntityIdentifier to re-scope. It does not explicitly route the agent to pm_create_webhook or pm_get_webhook for creation/inspection, so exclusions are implied rather than stated.

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?