Skip to main content
Glama

Manage Suppression Rule

manage_suppression_rule
Destructive

Add, retarget, remove or dry-run one suppression rule of the caller's account, chosen by action. A matched issue keeps recording events and keeps its status while staying out of the default list and out of every notification. To silence a set of issues: call this with action=preview and the match and conditions, read the sample back to the person (call again with page=1 and the same match and conditions when issuesMatched is larger than one page), then call this with action=create and that same match and those same conditions, then call list_suppression_rules to see how much the new rule covers. A rule the account already holds is refused, so read the existing rules before adding one. To retarget a rule that is too wide, too narrow or simply wrong: call list_suppression_rules to read the rule ids, their conditions and their coverage, call this with action=preview and the match and conditions you mean to move it to, then call this with action=update, the id and that same match and those same conditions; a rule is replaced whole, so send every condition it should keep, and it keeps its id, its author and the day it was added. To remove a rule: call list_suppression_rules for the id, then call this with action=delete and that id. On update and delete, issues the old conditions hid return to the list at once and alert again on their next event; nothing is resent for issues that stay quiet, cards withheld while the rule was in force are not resent, and the answer reports how many issues are now waiting to alert again as rearmedIssues. A preview stores nothing and changes no issue: its answer holds how many issues the conditions match, how many of those were seen in the last day, and one page of matching issues, most recently seen first. To silence a single issue instead (the app calls this suppressing one issue), call set_issue_status with IGNORED. A rule holds one to five conditions and one operator: match="all" covers an issue only when every condition holds, match="any" covers it as soon as one does. A rule of one condition has nothing to join, so it is stored and answered as match="all" whichever operator you sent. A condition is a field and a value. Every field matches the whole value, case insensitive, and a star stands for any run of characters: service notifier names that one service, exceptionType java.net.* names every type under java.net, title timed out names every title carrying that phrase, level warn names every issue recorded at that severity. An ENVIRONMENT condition matches an issue that has been seen in a deployment environment matching the value, so a rule naming one environment covers the whole issue, not only that environment's rows. A value of only stars is refused. To narrow, write match="all" with conditions [{"field":"SERVICE","value":"notifier"},{"field":"ENVIRONMENT","value":"staging"},{"field":"LEVEL","value":"warn"}], which covers the notifier service's warnings in staging and nothing else. To widen, write match="any" with conditions [{"field":"EXCEPTION_TYPE","value":"com.slack."},{"field":"EXCEPTION_TYPE","value":"io.netty."}], which covers both libraries. A condition can be negated: to cover everything from payments except timeouts, write match="all" with conditions [{"field":"SERVICE","value":"payments"},{"field":"EXCEPTION_TYPE","value":"java.util.concurrent.TimeoutException","negated":true}], and an issue carrying no exception type at all counts as not a timeout.

Input Schema

NameRequiredDescriptionDefault
idNoThe rule id (from list_suppression_rules); needed by update and delete, ignored by create and preview
pageNopreview only: page of matching issues to read, 0 to 1000 (default 0); a page beyond that is refused
sizeNopreview only: issues per page, 1 to 50 (default 10)
matchNoall or any; needed by create, update and preview
actionYescreate, update, delete or preview
conditionsNoOne to five conditions, each a field (SERVICE, ENVIRONMENT, EXCEPTION_TYPE, TITLE or LEVEL), a value of 1 to 200 characters in which a star stands for any run of characters, and an optional negated flag, false unless you send it, which turns the condition into is not; needed by create, update and preview

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / format
      Added value: +"int32"
    • addedInput schema / properties / size / format
      Added value: +"int32"
  2. Added
  3. Removed
  4. Added
  5. Removed
  6. Added
  7. Removed
  8. Changed1 schema field changed
    • changedInput schema / properties / conditions / description
      Previous value: -"One to five conditions, each a field (SERVICE, ENVIRONMENT, EXCEPTION_TYPE or TITLE), a value of 1 to 200 characters in which a star stands for any run of characters, and an optional negated flag, false unless you send it, which turns the condition into is not; needed by create, update and preview"New value: +"One to five conditions, each a field (SERVICE, ENVIRONMENT, EXCEPTION_TYPE, TITLE or LEVEL), a value of 1 to 200 characters in which a star stands for any run of characters, and an optional negated flag, false unless you send it, which turns the condition into is not; needed by create, update and preview"
  9. Added
  10. Removed
  11. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description carries far more: matched issues keep recording and keep status while being hidden from lists and notifications; update/delete rearm hidden issues immediately with nothing resent and withheld cards not resent; the response reports rearmedIssues; preview stores nothing; duplicate rules are refused. These are exactly the mutation side-effects an agent needs and are not inferable from the annotations.

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 purpose and action set are front-loaded, and the dense workflows are appropriate for a genuinely complex six-parameter tool. It is nevertheless long and repeats the 'call list_suppression_rules' instruction three times, so a little telescoping would tighten it without losing content.

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?

With no output schema, the description compensates by describing what preview returns (match count, last-day count, one page of issues most-recent-first) and what update/delete return (rearmedIssues). Combined with the condition grammar and the refusal/validation rules, an agent has everything needed to call and interpret this tool.

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 already 100%, so the schema explains each parameter's role. The description still adds real semantics the schema lacks: match='all' vs 'any' join behavior, the one-condition rule being stored as 'all', star wildcards matching whole values case-insensitively, ENVIRONMENT matching the whole issue, and negation semantics including issues lacking the field. It overlaps the schema on a few points (wildcards, 1-5 conditions) but adds beyond it.

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 first sentence names a specific verb set (add, retarget, remove, dry-run) on a specific resource (one suppression rule of the caller's account) and ties it to the 'action' parameter. It further distinguishes itself from siblings by explaining the single-issue alternative (set_issue_status with IGNORED) and the read-side tools (list_suppression_rules). An agent can separate this from create_ignore_rule or suppress_signal without opening a schema.

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?

Explicit step-by-step workflows are given for each of the three real use cases: silencing a set of issues (preview then create then verify), retargeting (list, preview, update), and removing (list, delete). It also names the when-not case ('To silence a single issue instead ... call set_issue_status') and the precondition ('read the existing rules before adding one'). This is about as complete as usage guidance gets.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources