Skip to main content
Glama
Sign In

HotCodePush

by com.hotcodepush
OverviewDiscussionsAdmin

Update a webhook

update_webhook

Rename a webhook or change its URL, events, app filter or whether it is enabled; the format and the secret never change. Use this to subscribe to other events, to point it at a new receiver, or to turn it back on: enabling a webhook disabled after fifty failed deliveries in a row starts that count again. Null appId sets the filter back to every app. Returns the updated webhook. Do not use this to change the format (delete the webhook and create another) or to remove it (use delete_webhook).

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

Input Schema

NameRequiredDescriptionDefault
urlNoThe new https URL the events are posted to. Optional.
nameNoThe new name, e.g. "team-chat". Optional.
appIdNoThe id of the app whose events alone the webhook receives; null for every app's and the organization's events. Optional.
eventsNoThe audit types the webhook receives from now on, replacing the list, e.g. ["release.created"]. Optional.
isEnabledNoWhether the webhook delivers, e.g. true. Optional.
webhookIdYesThe id of the webhook, e.g. "a1b2c3d4-0000-4000-8000-000000000000". Use `list_webhooks` to look it up by name.
organizationIdYesThe id of the organization, e.g. "a1b2c3d4-0000-4000-8000-000000000000". Use `list_organizations` to look it up.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare non-read-only, non-destructive and open-world, and the description adds genuinely new behavioral facts: format and secret are immutable, re-enabling a webhook disabled after fifty consecutive failures resets that counter, null `appId` widens the filter to every app, and the tool returns the updated webhook. These are operational consequences an agent could not infer from the annotations or 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?

Purpose is front-loaded in the first clause, followed by use cases, then invariants, then exclusions. There is no filler: every clause either names a mutable field, a use case, an immutable constraint, or the return value.

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?

For a 7-parameter mutation tool with no output schema, the description covers the mutation semantics, the immutable fields, the side effect of re-enabling, the null-filter behavior, the return value, and routing to delete/create siblings. Nothing an agent needs in order to call this correctly is missing.

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 and the schema already defines each field including the null-appId case and the replacing-list semantics of `events`. The description still adds meaning the schema does not: that `isEnabled: true` restarts the failed-delivery counter. That is real added value, though most of the rest restates schema-documented behavior.

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 and resource ("Rename a webhook or change its URL, events, app filter or whether it is enabled") and immediately names the two things that cannot be changed (format, secret). An agent can distinguish this from create_webhook, delete_webhook and get_webhook without consulting any schema.

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

Usage Guidelines5/5

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

It gives positive triggers ("subscribe to other events", "point it at a new receiver", "turn it back on") and explicit exclusions with the correct alternative for each: change the format → delete and recreate, remove → `delete_webhook`. Both when-to-use and when-not-to-use are covered, with a named sibling.

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

All HotCodePush toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources