Skip to main content
Glama
sekera-radim

@briefgate/mcp

by sekera-radim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Manage webhook endpoints

manage_webhook
Destructive

Register, list, or remove webhook endpoints so BriefGate pushes intake events to your service, eliminating the need to poll for status. Use only when your service can accept public HTTPS requests.

Instructions

Register, list, or remove a webhook endpoint so BriefGate pushes intake events to your service instead of you polling for them.

Use this ONLY if you control a service that can receive public HTTPS requests. An agent running in a terminal cannot — for that case do not register anything and check on a schedule with get_intake_status instead. A registered endpoint that cannot receive produces failing deliveries and a false impression that the work is being watched.

action="create" returns a "secret" exactly once. Store it somewhere durable outside this conversation: it is needed to verify the signature on every delivery (use verifyWebhookSignature from @briefgate/mcp/webhook) and it cannot be retrieved again. If it is ever exposed, there is no rotation in place — delete the endpoint and create a new one, which issues a fresh secret.

Events: intake.completed (all required items in — the one to act on), item.submitted (a single item arrived), client.viewed (the client opened the portal), chase.bounced (a reminder failed to deliver), intake.overdue (the due date passed with required items outstanding — the one to act on when work is blocked), intake.stalled (fires only when the intake sets max_reminders; without it this event never arrives).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoHTTPS endpoint to deliver to. Required for action="create".
actionYesWhat to do. "list" needs no other argument.
eventsNoEvents to receive. Required for action="create". For "tell me when the client is done", this is ["intake.completed"].
formatNoPayload shape. "raw" (default) is the signed BriefGate envelope; "slack" and "discord" post a message those services render directly.
webhook_idNoEndpoint to remove. Required for action="delete".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already signal destructive/non-read-only behavior, but the description adds substantial context: the create action returns a one-time secret, the secret cannot be retrieved again, there is no rotation, and unreachable endpoints create false delivery confidence. It also documents conditional event behavior such as intake.stalled only firing with max_reminders set.

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 long but tightly organized: purpose, usage restriction, secret lifecycle, then event definitions. Every sentence carries operational weight, and the most important usage constraint is front-loaded.

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?

For a webhook manager with no output schema, this is highly complete: it covers when to use the tool, when not to, secret handling, event semantics, format options, and action-specific parameters. Nothing necessary for correct invocation is missing.

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%, so the baseline is 3; the schema already describes url, action, events, format, and webhook_id. The description adds some operational meaning, like the secret-on-create behavior and an events example, but it does not need to carry much of the parameter-semantics burden.

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 states a specific verb-and-resource relationship: register, list, or remove webhook endpoints so BriefGate pushes intake events instead of polling. This clearly distinguishes the tool from the polling-based sibling get_intake_status.

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 explicitly says this tool should only be used when the agent controls a public HTTPS-receiving service, and warns that terminal agents must instead poll with get_intake_status. It also gives concrete event-selection guidance, such as using ["intake.completed"] for client-completion scenarios.

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