Skip to main content
Glama
tribeunal

Tribeunal Decision-Making Platform

Official
by tribeunal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update webhook

tribeunal_update_webhook
Idempotent

Update a webhook endpoint's event subscriptions or pause/resume delivery without changing its URL or secret. Provide events, active, or both.

Instructions

Change which events a webhook endpoint receives, or pause/resume delivery, without touching its URL or secret. Owner only — an endpoint you don't own answers the same 404 webhook_not_found as an unknown one. Pass events and/or active; at least one is required, any other key (including url) 400s field_not_editable. URL and secret cannot be changed here or read back — delete with tribeunal_delete_webhook and re-create with tribeunal_create_webhook instead. Returns {uuid, url, events, active, lastDeliveredAt, lastStatusCode, failureCount, createdAt} — never the secret.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
activeNofalse pauses delivery without deleting the endpoint; true resumes it. Independent of events — pass either, both, or (refused) neither.
eventsNoReplaces the endpoint's entire subscribed-event list (not merged) — pass every event you still want, from the same catalog as tribeunal_create_webhook. Omit to leave the current subscription untouched.
webhookIdYesEndpoint UUID, from tribeunal_list_webhooks or the tribeunal_create_webhook response. An endpoint you don't own, or an unknown uuid, both answer 404 webhook_not_found.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.0
    • changedInput schema / properties / events / items / enum
      Previous value: -[
-  "case.opened",
-  "case.closed",
-  "vote.cast",
-  "vote.revoked",
-  "comment.created",
-  "evidence.marked",
-  "evidence.unmarked",
-  "jury.joined",
-  "ping"
-]New value: +[
+  "case.opened",
+  "case.closed",
+  "vote.cast",
+  "vote.revoked",
+  "comment.created",
+  "evidence.marked",
+  "evidence.unmarked",
+  "jury.joined",
+  "ping",
+  "dispute.opened",
+  "appeal.filed",
+  "ruling.final"
+]
  2. Addedv2.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly=false, idempotent=true, destructive=false); the description goes well beyond them by disclosing owner-only authorization, that non-owned and unknown endpoints both return an indistinguishable 404 webhook_not_found, that unsupported keys return 400 field_not_editable, and that the secret is never returned. That is exactly the non-obvious behavioral context an agent needs before calling a mutation.

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?

The core action is front-loaded in the first clause, followed by authorization, the parameter contract, the rejected alternative, and the return shape — in descending order of importance. Every clause carries distinct operational information with no filler.

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 present, the description compensates by enumerating the returned fields and explicitly noting the secret is excluded. Combined with the error-code and ownership disclosures, an agent has everything needed to invoke and interpret this tool correctly.

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 description coverage is already 100%, so the baseline is 3, but the description adds genuine cross-parameter semantics: at least one of events/active is required, and any other key including url is rejected. It reinforces the replace-not-merge contract for events. It stops short of repeating enum values, which 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?

Opens with a precise verb+resource+scope: 'Change which events a webhook endpoint receives, or pause/resume delivery, without touching its URL or secret.' It immediately distinguishes itself from tribeunal_create_webhook and tribeunal_delete_webhook, which it names explicitly, so an agent can route correctly without opening 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?

States when to use it (events and/or active), when not to (URL/secret changes are refused), and the exact alternative workflow — 'delete with tribeunal_delete_webhook and re-create with tribeunal_create_webhook instead.' It also names the ownership precondition and the error semantics for violating it.

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

Deploy Server

Other Tools