PixelGlass

Create a webhook

create_webhook

On one site of the account, named in site. A new webhook: when its event happens, the publication sends a signed POST (Standard Webhooks) to its URL — Zapier, Make, or the person's own code. One event a webhook; two events are two webhooks. The URL must be https and on the public internet. The answer holds the secret that signs each request: give it to the person for their receiver. test_webhook sends a sample.

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": {
      "site": "<site>",
      "name": "<name>",
      "event": "<event>",
      "url": "<url>"
    },
    "name": "create_webhook"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	The https address that receives each event
`name`	Yes	What the person calls it: "CRM", "Slack"
`site`	Yes	The site to work on, as list_sites names it
`event`	Yes	The one event it sends; list_webhooks names them all

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

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, destructive=false) by disclosing the delivery mechanism (signed POST, Standard Webhooks), why it is openWorld, and critically that the response contains the signing secret the caller must hand to the user. That is the kind of one-time-reveal behavior an agent could easily mishandle if it were omitted.

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?

Dense and front-loaded, with the scoping constraint first and the secret-handling instruction late but present. The telegraphic sentence fragments ('A new webhook: when its event happens...') and the redundant opening stack against it slightly, though almost every clause carries information.

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?

Covers the essentials for a 4-required-param mutation with no output schema, including what the return payload contains and how to validate delivery. It leaves edge cases unaddressed, such as duplicate URLs, event-count limits, and what error looks like if the site name is wrong.

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 already 100%, so the baseline is 3, but the description adds real meaning: site must match how list_sites names it, name is the person's own label for the hook, and the event enum is strictly one event per webhook. The public-internet restriction on url extends the schema text.

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+resource (create a webhook) scoped to one site, and explains the resulting behavior precisely: a signed Standard Webhooks POST fires on the chosen event. The line 'One event a webhook; two events are two webhooks' distinguishes this from update_webhook and delete_webhook semantics without needing their schemas.

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

Usage Guidelines4/5

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

Gives clear preconditions (URL must be https and publicly reachable) and a follow-up route ('test_webhook sends a sample'), which tells the agent what to do after creation. It stops short of explicit when-not guidance or steering toward list_webhooks/delete_webhook for managing existing hooks.

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

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