Skip to main content
Glama

Create Webhook

gitlab_create_webhook

Creates a GitLab project or group webhook that sends selected event payloads to a trusted URL, with URL and token redacted from errors and never returned.

Instructions

Create a project or group webhook. GitLab then sends the selected event payloads to url, so only target endpoints you trust. token and url are redacted from errors and never returned.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "gitlab_create_webhook"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
nameNo
tokenNo
group_idNo
job_eventsNo
project_idNo
descriptionNo
note_eventsNo
push_eventsNo
emoji_eventsNo
issues_eventsNo
member_eventsNo
project_eventsNo
pipeline_eventsNo
releases_eventsNo
subgroup_eventsNo
tag_push_eventsNo
wiki_page_eventsNo
deployment_eventsNo
feature_flag_eventsNo
vulnerability_eventsNo
merge_requests_eventsNo
branch_filter_strategyNo
enable_ssl_verificationNo
confidential_note_eventsNo
push_events_branch_filterNo
confidential_issues_eventsNo
resource_access_token_eventsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.7.0

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare the write/non-idempotent/open-world profile, and the description adds genuine context beyond them: that GitLab actively pushes selected event payloads to the given URL (an ongoing external side effect, not just a one-time record), and that token and url are redacted from errors and never returned. This is real operational value for a security-sensitive tool. It stops short of saying which fields cannot be changed after creation or what the response contains, but it exceeds the annotation baseline.

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?

Three short sentences, front-loaded with the action, followed by the consequence and the secret-handling note. No redundant or filler wording; every clause carries information.

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 28-parameter creation tool with no output schema, the description is thin: it never explains how to choose between project_id and group_id, how event flags default when omitted, or how branch filtering is configured. The safety content is good, but an agent could still call this incorrectly on the substantive parameters.

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 0% across 28 parameters, so the description carries the full explanatory burden and largely does not. It explains only url's role and token's redaction behavior; the ~24 event boolean flags, the branch_filter_strategy enum, push_events_branch_filter, and the project_id/group_id mutual-exclusivity are all left to the raw schema with no prose guidance.

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 opens with a specific verb and resource ("Create a project or group webhook") and thereby distinguishes the two scopes the tool supports. It does not name the sibling mutators (gitlab_update_webhook, gitlab_delete_webhook) explicitly, but 'Create' is unambiguous against them.

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?

"Only target endpoints you trust" is a safety warning about the target, not guidance about when to select this tool over gitlab_update_webhook or gitlab_list_webhook_events. There is no stated prerequisite (e.g., maintainer/owner permission, project_id vs group_id choice) and no exclusion criteria.

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