Skip to main content
Glama

watch_webhook

Start an HTTP server to receive incoming webhooks from sources like GitHub or Vercel, enabling real-time visibility into CI results, deployments, and test outcomes for AI coding agents.

Instructions

Start an HTTP server to receive incoming webhooks

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
source_typeYesLabel for the webhook source (e.g. "github", "vercel")
portNoPort to listen on (default: 9876)
filterNoOptional filter criteria
action_idNoLink events to an agent action

Implementation Reference

  • The handleWatchWebhook method implements the watch_webhook tool logic by parsing input arguments, creating a watch record, and registering a new WebhookWatcher.
    private async handleWatchWebhook(args: Record<string, unknown>) {
      const schema = z.object({
        source_type: z.string(),
        port: z.number().optional(),
        filter: z.record(z.unknown()).optional(),
        action_id: z.string().optional(),
      });
      const parsed = schema.parse(args);
      const id = uuidv4();
      const now = new Date().toISOString();
    
      const config: WebhookConfig = { kind: 'webhook', ...parsed };
      const watch: WatchRecord = {
        id,
        kind: 'webhook',
        config,
        action_id: parsed.action_id ?? null,
        created_at: now,
        active: true,
        last_poll_at: null,
      };
    
      insertWatch(watch);
      const watcher = new WebhookWatcher(id, parsed.action_id ?? null, this.registry.getNotifyFn(), config);
      this.registry.register(watcher);
    
      return {
        content: [{
          type: 'text' as const,
          text: JSON.stringify({ watch_id: id, status: 'listening', port: parsed.port ?? 9876 }),
        }],
  • src/server.ts:179-180 (registration)
    The tool call is routed to handleWatchWebhook within the main server request handler.
    case 'watch_webhook': return this.handleWatchWebhook(args ?? {});
    case 'check_consequences': return this.handleCheckConsequences(args ?? {});
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions starting a server, it fails to disclose whether this blocks the agent, how events are delivered (streamed, batched, via action_id linkage), error conditions (port conflicts), or the long-running lifecycle implied by the cancel_watch sibling tool.

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 single sentence is efficient and front-loaded with the core action. However, given the operational complexity of starting an HTTP server, the brevity may underserve the user; nonetheless, the existing text contains no waste.

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

Completeness2/5

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

For a tool that spawns a network server with 4 parameters (including complex filtering) and no output schema or annotations, a single sentence is inadequate. Missing critical context includes event delivery format, shutdown mechanics (despite cancel_watch existing), and security implications.

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 description coverage is 100%, providing detailed descriptions for all 4 parameters including the nested filter object and action_id linkage. The description adds minimal semantic value beyond the schema, which meets the baseline expectation for high-coverage schemas.

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 states a specific action ('Start an HTTP server') and purpose ('receive incoming webhooks'), which distinguishes it from generic polling watches. However, it does not explicitly differentiate from sibling tools like watch_url or poll_events, which may also involve HTTP traffic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use webhooks versus polling via poll_events or watch_url, nor prerequisites like port availability or firewall configuration. The existence of cancel_watch as a sibling suggests this tool requires explicit lifecycle management, which is unmentioned.

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/jarvisassistantux/loopsense'

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