Skip to main content
Glama

Fixter

by dev.fixter.mcp

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

TableJSON 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

TDQS

A5/5.0
Behavior5/5

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

Despite no annotations, the description discloses critical behaviors: it is a WRITE operation requiring ADMIN role, it affects burn evaluation rather than notifications, URL_PATH values are normalized, and rules can be permanent or expire after expiresInHours. This goes beyond baseline.

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 core purpose and key distinction, then uses clear sections (Scope, Duration) for parameter details. Each sentence provides necessary information with no fluff, making it well-organized for an agent to parse.

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 six parameters, no annotations, and no output schema, the description fully compensates by covering admin requirements, signal constraints, edge cases, and expiration behavior. It leaves no major gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all parameters, but the description enriches semantics by explaining why operation is required for LATENCY_P95, what THROUGHPUT implies, how URL_PATH normalization works, and what omitting expiresInHours means. These details are not present in the schema and materially improve correct usage.

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 defines the tool as creating ignore rules that exclude traffic fingerprints from burn-rate alert evaluation, using specific verbs and resources. It distinguishes itself from suppress_signal (which mutes notifications) and from listing/deleting rules, making its purpose unambiguous.

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 when-to-use guidance: 'To temporarily silence alert notifications without changing evaluation, use suppress_signal instead.' Also explains parameter requirements such as operation being required for LATENCY_P95 and THROUGHPUT having no burn evaluation, helping the agent choose appropriate values.

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

All Fixter toolsInspect
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