Skip to main content
Glama
Sign In
@apinator/mcp

@apinator/mcp

Official
by apinator-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add webhook

add_webhook

Register a webhook endpoint to receive signed POSTs for selected events, and return its signing secret so the receiving app can verify each request.

Instructions

Register a webhook endpoint that receives signed POSTs for the chosen events. Returns the endpoint and its whsec_ signing secret, shown only this once: put it in the receiving app's environment (e.g. APINATOR_WEBHOOK_SECRET) and verify each request with verifyWebhook from the server SDK. An app can have at most 10 endpoints; adding a URL that is already registered is refused (use edit_webhook instead).

Input Schema

NameRequiredDescriptionDefault
urlYesReceiver URL, e.g. https://myapp.example.com/api/apinator-webhook. It must be reachable from the internet: private and loopback addresses (localhost, 10.x, 192.168.x) are refused. For a dev server on this machine, expose it with a tunnel (cloudflared, ngrok) and use the tunnel URL.
eventsYesEvents to send: channel_occupied / channel_vacated (a channel got its first subscriber / lost its last), member_added / member_removed (presence channels; the body carries user_id).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description discloses important behavior: signed POSTs, a one-time-only whsec_ secret, a 10-endpoint cap, and duplicate-URL refusal. These are material operational facts absent from structured fields.

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 tight sentences, front-loaded with what the tool does and the critical one-time secret behavior, then the 10-endpoint and duplicate-URL constraints. No sentence is wasted.

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 two-parameter mutation tool with no output schema, the description covers the key return value (endpoint plus one-time signing secret), secret handling guidance, limits, and failure routing. Nothing essential for correct invocation is missing.

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%, and the schema already explains both the URL reachability constraints and each event type in detail. The description only refers to 'chosen events' without adding parameter-level information beyond the schema, so the baseline of 3 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?

The description uses a specific verb and resource ('Register a webhook endpoint') and immediately states the core effect: receiving signed POSTs for chosen events. It distinguishes itself from edit_webhook by explicitly routing duplicate URLs to that sibling.

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 explicit usage conditions: an app may have at most 10 endpoints, and adding an already-registered URL is refused with the alternative 'use edit_webhook instead.' This tells the agent both when to call it and what to do when the call would be rejected.

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