Skip to main content
Glama

kaiten_update_webhook

Modify an existing webhook for a Kaiten space: change its target URL or enable/disable it. Provide space and webhook IDs to apply changes.

Instructions

Update an external webhook for a Kaiten space. Can change URL and enable/disable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoWebhook URL to receive events (max 4096 chars)
enabledNoWhether the webhook is enabled
space_idYesSpace ID
webhook_idYesWebhook ID
Install Server

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It discloses that the operation mutates URL and enabled state, but it does not mention permissions, whether updates are partial or full, side effects on event delivery, reversibility, or error/response behavior. This is a thin disclosure for a write tool.

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?

Two sentences, front-loaded with purpose, and no filler. The second sentence is somewhat redundant with the schema, but it gives a compact overview of allowed changes.

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

Completeness3/5

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

The schema fully covers the parameters and the tool is simple, so the description is minimally viable. However, with no output schema and no behavioral annotations, it leaves return values, failure modes, and update semantics unspecified.

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 the schema already documents all four parameters. The description's 'Can change URL and enable/disable' restates the schema rather than adding deeper meaning such as URL format or enabled-state semantics, so the baseline applies.

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?

Description uses a specific verb ('Update') and resource ('external webhook for a Kaiten space'), and names the two mutable aspects (URL, enabled). The qualifier 'external' distinguishes this from sibling kaiten_update_incoming_webhook.

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?

The description implies use for external webhooks, and 'external' hints at the boundary with incoming-webhook tools, but it does not explicitly state when to use this over kaiten_update_incoming_webhook or mention prerequisites like the webhook needing to exist. No exclusions or alternatives are named.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ViktorOgnev/kaiten-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server