Fixter

get_notification_destinations

Show which notification channels a source's notifications are delivered to for the authenticated customer. Returns JSON with channelIds. A null channelIds means no destinations are configured, so delivery falls back to the next step down: a subject falls back to its source, and a source falls back to the default, which is the customer's email channel plus their default channel. An empty list means notifications are turned off entirely for whatever was asked about.

Pass subject to read one alert rule's or one API test's own destinations rather than the whole source's. A subject row outranks the source row at delivery time, so a source read alone will not tell you where a routed rule's alerts actually go.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`source`	Yes	The notification source. Validated against the set of routable sources; an unknown value is rejected with the valid set named in the error.
`subject`	No	Optional. The id of one thing within the source to route on its own: an alert rule id for source alerting (the id field from get_alert_rules), or an API test id for source e2e-monitoring. Omit to address the whole source.

TDQS

A4.8/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 of behavioral disclosure. It explains the meaning of null channelIds, empty-list channelIds, fallback to the default, subject-over-source precedence, and the rule about routed destinations. This is exactly the kind of non-obvious behavior an agent needs before invoking the tool.

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 dense but not bloated; every sentence serves a purpose. It front-loads the core behavior, then explains conditional semantics and the subject override. The length is justified by the fallback and precedence behavior.

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 and no annotations, this description sufficiently covers the return shape, channelIds meaning, parameter semantics, and edge cases. An agent has enough information to call the tool correctly and interpret its result.

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 input schema already has strong 100% parameter descriptions, and the tool description adds extra semantic value: subject outranks source at delivery time, subject accepts alert rule IDs from get_alert_rules, and source-only reads miss routed rule destinations. These additions materially improve parameter formation and interpretation.

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 begins with a precise verb and object: 'Show which notification channels a source's notifications are delivered to.' It also distinguishes the subject scope from the source scope, making it clear this is a read-only lookup rather than a configuration tool like set_notification_destinations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear invocation guidance: omit subject to address the whole source, or pass subject to read one alert rule's or API test's destinations. It also warns that a source read alone is insufficient for routed rules. It does not explicitly name alternative tools, but the context is strong enough for an agent to choose correctly.

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?