Skip to main content
Glama

HTML/CSS to Image API

Create a Webhook

create_webhook

Creates a webhook that sends the selected organization events to an HTTPS endpoint. Subscribing to an event requires read access to its resource; api_key events cannot be subscribed to through MCP. Creating an enabled webhook sends a webhook_test delivery to the endpoint; test_event_id in the result identifies it. Returns the configuration without secret parameter values or the signing secret.

Input Schema

NameRequiredDescriptionDefault
contentYesWebhook name, endpoint URL, subscribed events, and delivery parameters. Omit disabled or set it to false to enable the webhook.

Output Schema

NameRequiredDescriptionDefault
itemNoOperation result. Check success before using this value.
errorNoError details when the operation failed; null on success.
successNoWhether the operation succeeded. If false, inspect error before retrying.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / content / properties / signing_enabled / description
      Previous value: -"Whether to sign deliveries with this webhook's signing secret. The secret is generated when the webhook is created and can be copied from the dashboard. Defaults to false."New value: +"Whether to sign deliveries with this webhook's signing secret. The secret is generated when the webhook is created, returned only in the REST API create response, and can also be copied from the dashboard. Defaults to false."
    • addedOutput schema / properties / item / properties / signing_secret
      Added value: +{
      +  "description": "Signing secret for verifying deliveries. Returned only in the REST API create response, even when signing is disabled. Store it securely; updates, reads, lists, and MCP responses omit this field.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, openWorld=true, idempotent=false) by disclosing that an enabled webhook immediately fires a webhook_test delivery to the external endpoint, that test_event_id identifies it in the result, and that the returned configuration omits secret parameter values and the signing secret. The outbound-network side effect and secret redaction are exactly the kind of behavior an agent must know before invoking a create.

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?

Three sentences, front-loaded with purpose then constraints then side effect, with no filler. Each clause carries distinct operational information.

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 nested, single-parameter create tool with a fully documented schema and an output schema, the description supplies the remaining behavioral essentials: authorization prerequisites, the api_key exclusion, the automatic test delivery, and secret redaction in the response. Nothing required to call it 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, but the description adds meaning the schema lacks: api_key events cannot be subscribed through MCP even though they appear in the events enum, and enabling the webhook triggers a test delivery (clarifying the disabled default). It does not touch url, parameters, or signing_enabled semantics, which the schema already covers.

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?

States a specific verb and resource ("Creates a webhook") plus the scope and target ("sends the selected organization events to an HTTPS endpoint"), which clearly separates it from list_webhooks, get_webhook, update_webhook, and delete_webhook. An agent can pick this tool without opening the schema.

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?

Provides real eligibility constraints — read access to an event's resource is required to subscribe, and api_key events cannot be subscribed through MCP — which steers event selection. However, it never routes the agent between create/update/delete or says when creating a webhook is the wrong choice over updating an existing one, so the when-to-use-vs-alternative guidance is only implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.