Fixter

suppress_signal

Silence future alerts for the calling tenant so they stop paging, without touching the underlying alert rule. This mutes notifications only — rule evaluation and dashboards are unaffected, and the suppression is meant to be temporary (reversible with unsuppress_signal). To exclude specific traffic (a fingerprint such as HTTP 404s or one client) from burn-rate evaluation itself, use create_ignore_rule instead. WRITE: available to any authenticated user.

Scope narrows from left to right: service: required. The service to suppress alerts for. signal: optional (ERROR_RATE, LATENCY_P95, THROUGHPUT). Omit to suppress all signals for the service. operation: optional. Omit to suppress the whole service; set it to suppress only that operation.

Severity cap: onlyWarnings: false (default) suppresses everything, including CRITICAL alerts. true suppresses only WARNING-severity alerts — CRITICAL alerts still page.

Duration: durationHours: optional. Omit for a suppression that never expires (until removed with unsuppress_signal).

Only one suppression may exist per (signal, service, operation) scope for a tenant — creating a second one for the same scope fails. Use list_suppressions to find the existing one or unsuppress_signal to remove it first.

Input Schema

TableJSON Schema

Name	Required	Description
`signal`	No	Signal to suppress: ERROR_RATE, LATENCY_P95, or THROUGHPUT. Omit for all signals
`service`	Yes	Service name to suppress alerts for
`operation`	No	Operation to suppress. Omit to suppress the whole service
`onlyWarnings`	No	Suppress only WARNING alerts, letting CRITICAL alerts still page (default false)
`durationHours`	No	Hours until the suppression expires. Omit for no expiry (forever)

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does well: it explains that only notifications are muted (rule evaluation and dashboards unaffected), suppression is temporary and reversible, scope narrowing behavior, severity cap semantics, duration handling, and that only one suppression per scope is allowed. This exceeds typical transparency expectations.

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 well-structured with headings and front-loaded with the primary purpose. It is somewhat long but every line adds necessary behavioral detail for a 5-parameter tool. Would be a 5 if slightly more compressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage alternatives, scope, severity, duration, and uniqueness. Lacks explicit mention of the success return value, but given no output schema and the availability of list_suppressions for verification, this is a minor gap. Overall highly complete for the tool's complexity.

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 baseline is 3. The description adds value by explaining the hierarchical scope (service > signal > operation), default/omit behavior for onlyWarnings and durationHours, and the uniqueness constraint. This goes beyond the schema's individual parameter descriptions.

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 silences future alerts for the calling tenant, stopping paging without affecting the underlying alert rule. It distinguishes from siblings by naming create_ignore_rule (for excluding traffic from burn-rate evaluation) and unsuppress_signal (for reversal).

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 instructs when to use create_ignore_rule instead of this tool, and references unsuppress_signal and list_suppressions for managing suppressions. This provides clear context on alternatives and prerequisite actions.

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

All Fixter tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation2/5

Several tool pairs are near-duplicates, including three deprecated aliases (add_investigation_alert_channel vs add_alert_channel, list_investigation_alert_channels vs list_alert_channels, remove_investigation_alert_channel vs remove_alert_channel) that muddy the surface. Additionally, suppress_signal and create_ignore_rule both suppress alerting via different mechanisms, which could cause misselection despite detailed descriptions.

Naming Consistency4/5

The vast majority of tools follow a clear verb_noun snake_case pattern (create_api_test, list_issues, set_alert_rule_status). A few bare-noun tools (logs, spans, metrics) and the standalone verb correlate break the pattern slightly, but overall the naming is highly consistent and predictable.

Tool Count1/5

With 52 tools, this is on the extreme end of the calibration scale. Even accounting for the broad scope of an observability platform, the count is excessive and includes several deprecated redundancies that inflate it further.

Completeness5/5

The toolset provides comprehensive CRUD/lifecycle coverage across all major domains: alert rules (create, read, update, delete, status, delivery, preview), API tests (create, read, update, delete, run history, credentials), ignore rules and suppressions, issues with digest config, investigations with claim/read, channels, credentials, and rich query tools (logs, spans, metrics, SQL, traces, correlation). No obvious dead ends or missing core operations.

Resources

Need Help?