Skip to main content
Glama

manage_git_webhooks

Destructive

List, enable, or disable remote Git push webhooks to detect anchor-file drift across Forgejo, Gitea, GitHub, and GitLab, with HMAC-signed hooks and removal of only Helios hooks.

Instructions

List, enable, or disable remote Git push webhooks for anchor_files drift detection across Forgejo, Gitea, GitHub, or GitLab. Requires HELIOS_GIT_TOKEN and HELIOS_WEBHOOK_URL (returns manual setup instructions if unconfigured): action='list' audits owned repos, action='enable' installs an HMAC-signed push webhook on each target in repos, and action='disable' deletes only the Helios webhook from the remote repositories without affecting code or stored memories. Always run action='list' and confirm target repos with the user before calling 'enable' or 'disable'. Use manage_git_webhooks to manage remote repository hooks; use manage_server_config to set HELIOS_GIT_* settings, or revalidate_memories to clear [STALE] flags after a push.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "manage_git_webhooks"
  }
}

Input Schema

NameRequiredDescriptionDefault
reposNoList of repository names (e.g. ['braz/helios', 'braz/homelab']) to enable or disable.
actionNoAction to perform: 'list' (display repos and drift hook status), 'enable' (attach drift webhook), or 'disable' (remove drift webhook).list
include_forksNoWhether to include forked repositories when listing.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.3

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, it discloses that enable installs an HMAC-signed push webhook, disable deletes only the Helios webhook without affecting code or stored memories, and list audits owned repos. It also states token/URL requirements and the manual setup fallback when unconfigured.

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 front-loaded with the core action set and scope, then adds prerequisites, safety details, and alternatives in a logical order. Every sentence contributes useful routing or behavioral context.

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 multi-action external mutation tool with destructive and open-world behavior, the description covers prerequisites, safety constraints, confirmation workflow, and alternatives. Since an output schema exists, return-value details are not required in the description.

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?

Schema coverage is 100%, so the schema already defines all parameters. The description adds semantic meaning for action values and repos targets, explaining what list audits and what enable/disable do on each target, though include_forks is only described in the schema.

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 names a specific resource and verb set: list, enable, or disable remote Git push webhooks for anchor_files drift detection across Forgejo, Gitea, GitHub, and GitLab. It clearly distinguishes this from manage_server_config and revalidate_memories.

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 gives explicit workflow guidance: always run action='list' and confirm target repos with the user before enable or disable. It also names alternatives for related tasks, such as manage_server_config for HELIOS_GIT_* settings and revalidate_memories after a push.

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