Skip to main content
Glama

trigger_mock_webhook

Dispatch cryptographically signed mock payment webhooks to test your backend endpoint's signature parsing and event processing before using live charges.

Instructions

Constructs and dispatches a cryptographically authentic HMAC-SHA256 signed synthetic webhook event payload directly to a local or remote backend endpoint. Useful for verifying webhook signature parsing, event processing handlers, and local integration pipelines without executing live card charges. Returns the HTTP status code, response headers, and response body received from the target server.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eventYesThe standardized webhook event name to emulate (e.g., "payment.captured", "payment.failed", "refund.processed", "payment_intent.succeeded", "charge.refunded").
amountNoOptional minor unit currency amount to inject into the mock payload data body (e.g., 5000 for $50.00). Defaults to 1000 if unspecified.
secretNoThe shared webhook signing secret used to compute the HMAC-SHA256 signature header. If omitted, the active profile webhook secret is used.
providerYesThe payment gateway whose payload schema, signature format, and HTTP headers will be synthesized ("razorpay" adds "x-razorpay-signature", "stripe" adds "stripe-signature").
targetUrlYesFully qualified HTTP or HTTPS destination URL of your backend webhook ingestion endpoint (e.g., "http://localhost:3000/api/webhooks" or "https://api.example.com/webhooks").
Behavior3/5

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

With no annotations, the description must disclose behavior. It covers dispatching, signing, and returning response details, but omits potential side effects like network failure handling or external endpoint impact. The main actions are clear, but not exhaustive.

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?

The description is concise, two sentences, and flows logically from action to use case to output. No redundant wording.

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?

The description explains what the tool does, its return value, and its intended use. It doesn't cover edge cases like error handling or rate limits, but for a mock testing tool, the provided information is sufficient for basic usage.

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?

The schema descriptions for all five parameters are detailed and self-explanatory, covering format and defaults. The tool description adds no extra parameter info, but the schema already provides high coverage, so a baseline of 3 is exceeded due to quality.

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 clearly states the tool's purpose: constructing and dispatching a signed webhook event to a target endpoint for testing. This distinguishes it from sibling tools like create_payment_link or verify_webhook_signature.

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 explicitly notes usefulness for verifying webhook parsing and integration pipelines without live charges, providing clear context. However, it doesn't explicitly contrast with alternatives, though the 'without live charges' implies a testing scenario.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pritam825/unified-pay-cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server