Skip to main content
Glama

Fixter

by dev.fixter.mcp
OverviewDiscussionsAdmin

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
NameRequiredDescriptionDefault
sourceYesThe notification source. Validated against the set of routable sources; an unknown value is rejected with the valid set named in the error.
subjectNoOptional. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / subject
      Added value: +{
+  "description": "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.",
+  "type": "string"
+}
  2. Added

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 toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources