Skip to main content
Glama

Tạo cấu hình webhook

monapay_create_webhook

Register a webhook URL to receive notifications when incoming payments arrive, with optional HMAC_SHA256 or API key authentication and per-virtual-account filtering.

Instructions

Đăng ký URL nhận webhook khi có tiền vào; khuyến nghị auth_type HMAC_SHA256 + secret_key. / Create a webhook config.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
auth_typeNoHMAC_SHA256
secret_keyNoSecret ký HMAC hoặc giá trị API key
webhook_urlYes
api_key_nameNoTên header khi auth_type=API_KEY, mặc định X-Webhook-Secret
payload_formatNoapplication/json
virtual_account_idNoChỉ bắn cho VA này; bỏ trống = mọi tài khoản

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare this as a non-idempotent, non-destructive write in an open world, so the safety profile is covered. The description adds the useful event context (fires on incoming money) and an auth recommendation, but stays silent on behaviors like duplicate-URL handling, secret persistence, or failure modes that matter for a registration endpoint.

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 core statement and recommendation are front-loaded in a single compact sentence. The bilingual tail ('/ Create a webhook config') largely repeats what was already stated, which is mildly redundant but not harmful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation tool with no output schema and low schema coverage, the description is thin: it does not explain the parameter surface or what a successful registration returns. It covers the essentials an agent needs to recognize the tool but leaves real gaps in the configuration space.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (43%) across 7 parameters, so the description should compensate. It only touches auth_type and secret_key via a recommendation and leaves name, webhook_url, payload_format, api_key_name, and virtual_account_id entirely to the schema, adding marginal meaning beyond the field names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource ('Đăng ký URL nhận webhook' / register a webhook URL) and adds the trigger condition ('khi có tiền vào' / when money comes in), which distinguishes it from read-only siblings like monapay_list_webhooks. It is clear enough to select, though it does not explicitly contrast itself with monapay_update_webhook or monapay_test_webhook.

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's create-from-scratch role is implied, and it offers a configuration recommendation ('khuyến nghị auth_type HMAC_SHA256 + secret_key'). However, it gives no explicit when-to-use vs. when-not, nor does it point to the sibling alternatives (update/delete/test/list webhooks) an agent would need to disambiguate.

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