@apinator/mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APINATOR_KEY | Yes | API key | |
| APINATOR_APP_ID | Yes | App ID | |
| APINATOR_SECRET | Yes | API secret. Used to sign requests; never returned by any tool | |
| APINATOR_WS_URL | No | WebSocket base URL of a local or self-hosted data plane (default `wss://ws-{cluster}.apinator.io`) | wss://ws-{cluster}.apinator.io |
| APINATOR_API_URL | No | REST base URL of a local or self-hosted data plane (default `https://ws-{cluster}.apinator.io`) | https://ws-{cluster}.apinator.io |
| APINATOR_CLUSTER | Yes | Region the app was created in, e.g. `eu` or `us` | |
| APINATOR_READ_ONLY | No | `1` removes `publish_event`, so the agent can only observe |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| publish_eventA | Publish an event to one or more Apinator channels. Every client subscribed to those channels receives it immediately. On cache- channels the event is also stored and replayed to future subscribers. Pass exactly one of |
| list_channelsA | List the app's active channels (channels with at least one subscriber right now) and their subscriber counts. Channels that nobody is subscribed to are not listed, even if events were published to them. |
| get_channelB | Get one channel's subscriber count. Reports |
| sign_channel_authA | Compute the auth signature a client needs to subscribe to a private- or presence- channel, exactly as your auth endpoint would return it. Useful for testing an auth flow or debugging a signature mismatch. Presence channels need |
| watch_channelA | Subscribe to a channel over WebSocket and collect the events that arrive for a few seconds, then disconnect. Use it to confirm events are flowing, see payload shapes, or test a publish end to end (start the watch, then publish). Private and presence channels are signed automatically. On presence channels the watcher joins as a member, which other subscribers will see. Long watches report progress every few seconds. |
| list_webhooksA | List the app's webhook endpoints (at most 10 per app): id, URL, events and whether each is enabled. Signing secrets are never listed; add_webhook shows a new endpoint's secret once. |
| list_webhook_deliveriesA | Recent deliveries to one webhook endpoint, newest first: event, payload, status, attempts and the last error. Use it to check that events reach your receiver, or why they fail. Failed deliveries are retried 7 times over about 9 hours; delivered and failed ones are kept 7 days. |
| add_webhookA | 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). |
| edit_webhookA | Change a webhook endpoint's URL, events, or enabled state. Pass only what changes. The signing secret stays the same. |
| delete_webhookA | Delete a webhook endpoint. It stops receiving events at once, and its pending deliveries are dropped. |
| test_webhookA | Send one signed webhook.test event to an endpoint now and report the receiver's HTTP status and timing. Redirects are not followed. The test event is not queued or retried, and real events never use this type. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| add-realtime-feature | Plan and build a realtime feature (live updates, chat, presence, notifications) with Apinator. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| apinator-docs | The Apinator docs index for LLMs, fetched live from https://apinator.io/llms.txt. |
| apinator-protocol | WebSocket frames, system events, error codes, channel prefixes and the channel auth signature. |
TDQS
Scored across 11 tools
Webhook tools are cleanly partitioned by action (list/add/edit/delete/test/deliveries), and channel tools are similarly distinct (list/get, publish, sign auth, watch). There is little overlap; even the observability tools target different resources, such as webhook deliveries versus live channel events.
Every tool follows a snake_case verb-first pattern with resource-oriented nouns: list_webhooks, add_webhook, edit_webhook, publish_event, sign_channel_auth, watch_channel. Singular/plural usage is consistent with get/list semantics, and there are no mixed conventions.
The 11 tools map well to the domain: webhook lifecycle and delivery inspection plus channel listing, publishing, auth signing, and live watching. Each tool has a clear role, with no obvious filler or missing lightweight operation forcing extra calls.
Webhook coverage is essentially full CRUD plus testing and delivery inspection; channel coverage includes listing, lookup, publishing, auth signing, and live watching. Minor gaps remain, such as no single-webhook getter beyond list_webhooks or event-history retrieval, but core workflows are covered.