mcp-server

tickerbot_test_webhook

Send a real-shape test POST to your endpoint, instantly. One-shot: a failed test never retries and never auto-disables the webhook. 400 when the webhook has no target_url.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Webhook id.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Delivery id of the test — `dl_…`, the same shape as a real delivery on the deliveries route.
`test`	Yes	`true` — this delivery was a synthetic ping, not a trigger firing.
`as_of`	Yes	Server time this response was assembled (ISO 8601).
`error`	Yes	Why delivery failed, in words; `null` on success.
`status`	Yes	The delivery record's status: `delivered` or `permanent_failure` (a test is never retried).
`delivered`	Yes	Whether your endpoint accepted the ping (2xx within the timeout).
`created_at`	Yes	When the ping was sent (ISO 8601).
`elapsed_ms`	Yes	Round-trip time of the ping.
`webhook_id`	Yes	The webhook that was tested.
`http_status`	Yes	The status your endpoint returned; `null` when it could not be reached.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "as_of": {
+      "description": "Server time this response was assembled (ISO 8601).",
+      "type": "string"
+    },
+    "created_at": {
+      "description": "When the ping was sent (ISO 8601).",
+      "type": "string"
+    },
+    "delivered": {
+      "description": "Whether your endpoint accepted the ping (2xx within the timeout).",
+      "type": "boolean"
+    },
+    "elapsed_ms": {
+      "description": "Round-trip time of the ping.",
+      "type": "number"
+    },
+    "error": {
+      "description": "Why delivery failed, in words; `null` on success.",
+      "type": "string"
+    },
+    "http_status": {
+      "description": "The status your endpoint returned; `null` when it could not be reached.",
+      "type": "number"
+    },
+    "id": {
+      "description": "Delivery id of the test — `dl_…`, the same shape as a real delivery on the deliveries route.",
+      "type": "string"
+    },
+    "status": {
+      "description": "The delivery record's status: `delivered` or `permanent_failure` (a test is never retried).",
+      "type": "string"
+    },
+    "test": {
+      "description": "`true` — this delivery was a synthetic ping, not a trigger firing.",
+      "type": "boolean"
+    },
+    "webhook_id": {
+      "description": "The webhook that was tested.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "as_of",
+    "id",
+    "webhook_id",
+    "test",
+    "delivered",
+    "http_status",
+    "elapsed_ms",
+    "error",
+    "status",
+    "created_at"
+  ],
+  "type": "object"
+}

AddedJun 29, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the disclosure burden and does so well: it states the request is a real POST, is one-shot, never retries, never auto-disables the webhook, and fails with 400 if target_url is missing. These details go beyond the schema and name, giving an agent accurate side-effect expectations.

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 short sentences with the main action front-loaded and each subsequence sentence adding a distinct behavioral detail. There is no redundant phrasing or unnecessary repetition of schema 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?

For a one-parameter tool with an output schema, the description covers the core purpose, the error condition, and important side-effect behavior. It does not mention whether the webhook must be enabled or permissions required, but these are minor gaps given the tool's low complexity.

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?

The sole required parameter 'id' is already fully described in the schema as 'Webhook id' with 100% schema coverage, so the description does not need to repeat it. The description adds no additional paramter semantics, which matches the baseline for high schema coverage.

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 leads with a specific action ('Send a real-shape test POST') against a specific resource ('your endpoint'), making it clear this is a webhook testing tool. It also distinguishes itself from sibling webhook tools by emphasizing it is a one-shot live test rather than configuration or inspection.

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?

The tool implies it should be used when you want to immediately validate a webhook endpoint, but it never explicitly states when to use it instead of alternatives like list_webhook_deliveries or create_webhook. It gives clear context in the first sentence but omits when-not-to-use guidance and alternatives.

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

All mcp-server 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.