Vike Data API

Alerts Register Webhook

alerts_register_webhook

Destructive

Register an HTTPS webhook as an alert delivery channel for the current user. We POST signed JSON to the URL when alerts fire, and once right now: a signed test event whose result comes back as test ({ok, status} or {ok, error}); a failing test does not refuse the channel. Every POST is signed with HMAC-SHA256: pass your own secret (>=16 chars) or we generate one and return it as secret in this answer (show it to the user now; it is shown at registration and again any time on Account -> Alerts -> channels, Show secret; alerts_rotate_webhook_secret issues a new one). The test is signed with that secret, so a receiver that checks signatures answers 401/403 until it has it: if your receiver needs the secret first, install it and call alerts_test_webhook. Recipients verify by computing HMAC-SHA256(secret, '{X-Vike-Timestamp}.{body}') over the RAW body and comparing it, in constant time, to EVERY sig= value of X-Vike-Signature: accept the delivery if ANY of them matches (during a secret rotation the header carries two). Replays should be rejected if timestamp is more than ~5 min old. Payload, headers and a verification example: https://vike.io/data/api#mcp-alerts

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": {
      "url": "<url>"
    },
    "name": "alerts_register_webhook"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Webhook URL, https:// only. Must be reachable from our server.
`secret`	No	Optional HMAC secret (>=16 chars). If omitted, we generate one and return it as `secret` in the answer.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedInput schema / properties / secret / description

Previous value: -"Optional HMAC secret (>=16 chars). If omitted, we generate one and return it once."New value: +"Optional HMAC secret (>=16 chars). If omitted, we generate one and return it as `secret` in the answer."

Changed2 schema fields changedOct 31, 2026

changedInput schema / properties / secret / description

Previous value: -"Optional HMAC secret (recommended, >=16 chars). If omitted, we still POST but with no signature."New value: +"Optional HMAC secret (>=16 chars). If omitted, we generate one and return it once."

changedInput schema / properties / url / description

Previous value: -"Webhook URL (http or https). Must be reachable from our server."New value: +"Webhook URL, https:// only. Must be reachable from our server."

First observedOct 25, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds the key behavioral fact an agent could not infer: registration immediately performs a signed POST test and returns {ok, status} or {ok, error}, and a failed test still leaves the channel registered. It also explains HMAC signing, secret generation, and the 401/403 edge case. It does not address re-registering an existing URL, though annotations already declare idempotentHint=false.

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?

The first sentence is a clean, front-loaded purpose statement and the operational facts follow in a logical order. It is dense and long for a two-parameter tool, with some material (the constant-time comparison recipe, replay rejection, Account menu navigation) that serves the end recipient rather than the caller, but none of it is filler prose.

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?

With no output schema, the description carries the return contract itself, documenting the test result shape and the returned `secret`. Combined with the authentication and signature requirements, an agent has everything needed to call the tool and report the outcome.

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 would be 3, but the description adds real meaning beyond the schema: the generated secret is returned as `secret` in this response and must be surfaced to the user, and the test is signed with it. The >=16 char constraint is restated, which is redundant but harmless.

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 first sentence gives a specific verb and resource ("Register an HTTPS webhook as an alert delivery channel for the current user") and scopes the audience to the current user. It also implicitly separates itself from siblings by naming alerts_test_webhook and alerts_rotate_webhook_secret as different operations.

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 conditional routing: if the receiver needs the secret before it can validate signatures, install the secret and call alerts_test_webhook instead, and use alerts_rotate_webhook_secret to issue a new one. It also states that a failing test does not refuse the channel, which prevents the agent from assuming registration failed.

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

All Vike Data API 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.