Sautikit

update_webhook

Idempotent

Update a webhook's URL, event list, or status (active/disabled). Only supplied fields change.

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": {
      "webhook_id": "<webhook_id>"
    },
    "name": "update_webhook"
  }
}

Input Schema

Name	Required	Description
`url`	No	new delivery URL
`events`	No	replacement event list — workspace-subscribable event kinds only (call.* lifecycle events are NOT accepted here — they route per-number instead), e.g. broadcast.call.started, number.provisioned, wallet.low_balance
`status`	No	active or disabled
`purpose`	No	Required on tools that read data or reports; recommended on every tool. One sentence: what you are doing and why (for example "finding this caller's open ticket to answer them"). Building a report, dashboard, analytics or an export is a SautiDesk Pro feature done by the report tools, not by pulling records.
`webhook_id`	Yes	webhook subscription UUID

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A3.6/5.0

Behavior3/5

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

The line 'Only supplied fields change' usefully discloses partial-update (PATCH) semantics, which the annotations (idempotentHint, destructiveHint, openWorldHint) do not convey. However, it omits behavioral consequences that matter for a mutation tool: that the events list is replaced wholesale rather than merged, and whether in-flight deliveries are affected.

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?

Two short sentences with zero filler: the operation and affected fields come first, and the partial-update guarantee follows. Every clause carries information an agent needs.

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 five-parameter mutation with full schema coverage, an annotation set covering safety and idempotency, and no output schema, the description covers the essentials. The only meaningful gap is that replacement semantics for the events array and the effect on pending deliveries are left to the schema and inference.

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%, so all five parameters — including webhook_id, url, events, status, and even the purpose field — are already fully documented in the schema. The description restates the same updatable fields (URL, event list, status) without adding syntax, format, or constraint detail beyond it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (update) and resource (webhook) plus the three mutable aspects (URL, event list, status), which cleanly separates it from create_webhook and delete_webhook siblings. It does not explicitly name those siblings, keeping it just below a 5.

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

Usage Guidelines3/5

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

Usage is implied by the verb and by the fact that a webhook_id is required, so an agent can infer this is the tool for modifying an existing subscription. There is no explicit guidance on when to prefer it over delete/recreate, nor on prerequisites such as permissions or the webhook needing to exist.

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

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