Skip to main content
Glama
redditapis

RedditAPIs

by redditapis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

reddit_monitor_webhook_test

Send a one-off test payload to a registered webhook to confirm it is wired correctly before real match deliveries. On failure, report the returned hint naming the fix.

Instructions

Send a one-off test delivery to a registered webhook (rate-limited to 10/min) so you can confirm it's wired up correctly before waiting for a real match. Uses the webhook's kind to format the test payload the same way a real delivery would. On failure the response carries reason and status plus TWO fields that say what to actually do: hint, our sentence naming the fix (most often that the target's kind does not match its host, which no test can succeed through), and detail, a bounded, sanitised copy of what the destination itself replied. Report hint to the user rather than the bare reason -- http_error with a 400 names no field, no value and no remedy. Returns 404 webhook_not_found if the id does not exist or is not yours, or webhook_url_rejected if the URL fails re-validation (e.g. now resolves to a private address).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe webhook's id, from reddit_monitor_webhook_create's response or reddit_monitor_webhook_list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.3

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly=false, destructive=false, openWorld=true); the description adds the rate limit (10/min), the payload-formatting behavior driven by the webhook's kind, the rich failure shape (`reason`, `status`, `hint`, `detail`), and two specific error outcomes (404 webhook_not_found, webhook_url_rejected). It even explains why `hint` should be surfaced over `reason`.

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?

Purpose is front-loaded, followed by payload behavior and then failure semantics in a logical order. It is dense and long, but nearly every sentence carries actionable information, so little 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?

With no output schema, the description takes on the burden of documenting return values and does so thoroughly: success formatting plus the full failure contract (reason/status/hint/detail and named error codes). An agent has everything needed to call and interpret this tool.

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 coverage is 100% and the schema already documents the `id` parameter including where it comes from (create or list), so the description adds essentially no extra meaning beyond what the schema provides. Baseline 3 is appropriate.

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 clause states a specific verb and resource ('Send a one-off test delivery to a registered webhook') and its purpose ('confirm it's wired up correctly'), which cleanly separates it from siblings like reddit_monitor_webhook_create and reddit_monitor_webhook_delete.

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?

It gives clear context for use: run it before waiting for a real match to verify wiring. It doesn't explicitly name an alternative or a when-not condition, but the pre-flight framing makes the intended usage unambiguous.

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