Skip to main content
Glama

pbs_notification_matcher_set

Create or update an alert routing rule for PBS notifications, using filters like severity, field, and calendar, with dry-run planning before execution.

Instructions

MUTATION: create-or-update a PBS notification matcher (alert routing rule). One safe read of the matchers collection decides create (POST, name in body) vs update (PUT .../{name}) — digest/delete only apply to the update branch. Dry-run by default (returns a PLAN); confirm=True executes (synchronous — PBS returns null) and returns {"status": "ok", "result": None}. No snapshot primitive — re-apply with this same tool to restore after deletion. To remove a matcher use pbs_notification_matcher_delete. Needs PROXIMO_PBS_* config.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoHow match-* filters combine: 'all' (default on PBS) or 'any'.
nameYesName of the notification matcher (alert routing rule) to create or update (2-32 chars, alnum start).
deleteNoUpdate only: property names to clear (e.g. ['comment','target']). Ignored on create.
digestNoOptimistic-lock (update only): 64-char lowercase hex SHA-256 of the config PBS last returned. Ignored on create — PBS's own create schema has no digest field.
targetNoNames of endpoints/targets to notify when this matcher fires.
commentNoOptional free-text comment stored with the matcher.
confirmNoFalse (default) returns a dry-run PLAN only; True executes the create/update.
disableNoIf True, disable this matcher without deleting it.
match_fieldNoMetadata field filters to match (see pbs_notification_matcher_fields for known names).
invert_matchNoIf True, invert the whole filter's match result.
match_calendarNoCalendar-event time-window filters to match.
match_severityNoSeverity levels to match (e.g. ['error','warning']).
proximo_targetNoWhich configured Proxmox target to run this call against — a target name from your multi-target config (a specific PVE/PBS/PMG/PDM box). Omit to use the single/default target from the environment; the selection applies only to this call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Discloses key behaviors: mutation operation, create-vs-update logic based on existence, digest/delete only for update, dry-run default, synchronous execution with null return, no snapshot primitive, and the need to re-apply to restore. Since no annotations exist, the description fully covers the behavioral burden.

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 a single, dense paragraph that front-loads the mutation type and then efficiently covers key points (create-vs-update, dry-run, confirm, restoration, deletion alternative). No extraneous information.

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?

Given the tool's complexity (13 params, 1 required, output schema present), the description covers all essential aspects: operation type, branching logic, dry-run/execution modes, return values, restoration, and prerequisites. Nothing appears missing.

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?

With 100% schema coverage, baseline is 3, but the description adds useful context beyond schema: clarifies that 'digest' and 'delete' only apply to the update branch, and that 'confirm' defaults to false for dry-run. This extra detail earns a 4.

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 clearly states the tool is a 'MUTATION: create-or-update a PBS notification matcher (alert routing rule)', using specific verb and resource. It distinguishes from the sibling pbs_notification_matcher_delete by explicitly naming it for removal.

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?

Provides explicit guidance: mentions dry-run by default, confirm=True for execution, and directs to the sibling tool for deletion. Also notes config requirement (PROXIMO_PBS_*), covering when to use and prerequisites.

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/john-broadway/proximo'

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