Skip to main content
Glama

Create Ignore Rule

create_ignore_rule

Ignore rules exclude a traffic fingerprint (e.g. HTTP 404 responses, or one client address) from burn-rate alert evaluation for a service/operation. This changes the data that counts toward error/latency burn — it does not mute notifications. To temporarily silence alert notifications without changing evaluation, use suppress_signal instead. Also created from the 'Ignore this pattern' button on an alert; button-created rules expire after a configured period (90 days by default) and can be made permanent from the confirmation page. WRITE: requires the ADMIN role.

A rule masks matching traffic from ONE signal's burn evaluation only — set signal to ERROR_RATE or LATENCY_P95. URL_PATH values are matched against normalized paths ({id} segments), so pass the template form (e.g. /orders/{id}); raw ids are normalized automatically.

Scope: signal: required (ERROR_RATE or LATENCY_P95). THROUGHPUT has no burn evaluation. service: required. operation: optional. Omit to ignore the fingerprint across the whole service. Required for LATENCY_P95 (service-level latency is not re-evaluated, so the rule would do nothing). dimension: which fingerprint attribute to match (e.g. HTTP_STATUS, CLIENT_ADDRESS, URL_PATH). value: the attribute value to ignore.

Duration: expiresInHours: optional. Omit for a permanent rule.

Input Schema

NameRequiredDescriptionDefault
valueYesThe fingerprint value to ignore (URL_PATH values are normalized)
signalYesSignal to mask: ERROR_RATE or LATENCY_P95
serviceYesService name the rule applies to
dimensionYesFingerprint dimension to match: one of CLIENT_ADDRESS, END_CUSTOMER, USER_AGENT, URL_PATH, MESSAGING_DESTINATION, DB_STATEMENT, GENAI_MODEL, TARGET_HOST, HTTP_STATUS
operationNoOperation to scope the rule to. Omit for the whole service (not allowed for LATENCY_P95)
expiresInHoursNoHours until the rule expires. Omit for a permanent rule

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 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 / expiresInHours / format
      Added value: +"int32"
  2. Added
  3. Removed
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial behavioral context beyond the annotations: WRITE operation requiring the ADMIN role, the fact that it alters burn evaluation data rather than muting notifications, per-signal scoping, and duration/expiry semantics. Annotations already cover non-destructive/non-idempotent status, and the description complements them without contradiction.

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 description is front-loaded with the core purpose and alternative tool, then organized under Scope and Duration headings. It is longer than necessary because some parameter details repeat the schema descriptions, but the structure keeps the reader oriented and most sentences earn their place.

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 complex write tool with no output schema, the description covers permissions, effect on evaluation, scope rules, normalization behavior, and expiry defaults. Nothing essential for correct invocation is 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful cross-parameter constraints such as operation being required for LATENCY_P95 and signal scope limitations (THROUGHPUT has no burn evaluation). It also explains URL_PATH normalization with a template example beyond the schema wording.

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?

States a specific verb and resource ('create_ignore_rule') and precisely defines what an ignore rule does: exclude a traffic fingerprint from burn-rate evaluation. It distinguishes the tool from sibling alternatives such as suppress_signal and clearly describes the effect (changes evaluation data, not notifications).

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?

Explicitly names the alternative for notification-only silencing ('use suppress_signal instead') and explains the condition that selects it. It also gives concrete usage context including UI button creation, default expiry, and scope constraints for LATENCY_P95 versus ERROR_RATE.

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