Pushary

Send Push Notification

send_notification

Destructive

Send a one-way notification to connected devices for a requested update or a meaningful unattended result. Use ask_user when an answer is needed. Delivery follows the account policy and optional recipient filters. context adds a detail page; context.askQuestion creates a linked decision. Returns web/mobile delivery counts and a warning when no delivery channel is connected. Sends real notifications.

Input Schema

TableJSON Schema

Name	Required	Description
`env`	No	Set to "test" from a test suite. The notification is recorded in the activity feed and nothing is delivered to a phone or browser. The X-Pushary-Env: test header does the same for every call on the connection.
`url`	No	URL opened when the user taps the notification. Ignored if context is provided, because a context detail page URL is generated automatically.
`body`	Yes	Notification body text (max 500 chars). One or two sentences the user can act on without opening anything.
`tags`	No	Deliver only to subscribers that have any of these tags.
`title`	Yes	Notification title shown on the lock screen (max 100 chars). Lead with the outcome, e.g. "Build finished" or "Migration failed".
`context`	No	Structured context rendered as a rich detail page when the user taps the notification. Strongly recommended for task_complete and error notifications so the user can act from their phone.
`iconUrl`	No	URL of the notification icon image
`imageUrl`	No	URL of a large image shown in the notification
`agentName`	No	Name of the agent sending this notification, format "{Agent} - {project}" (e.g. "Claude Code - myproject"). Shown in the notification so the user knows which session is talking. Falls back to the MCP client name if omitted.
`machineId`	No	Stable machine id of the sending agent, so two machines never collapse into one session.
`sessionId`	No	Opaque per-session id of the sending agent, so parallel sessions are attributed separately in the activity feed.
`externalIds`	No	Deliver only to subscribers matching these external IDs.
`subscriberIds`	No	Deliver only to these subscriber IDs. Omit all targeting fields to reach every connected device.

Output Schema

TableJSON Schema

Name	Required	Description
`env`	No	Echoed when the call was test traffic.
`hint`	No	What to do next, when there is a next step.
`sent`	No	Total devices reached, web plus mobile. Zero is a successful call that found nobody to deliver to, not an error.
`warning`	No	Present only when the notification reached zero devices, naming what the user has to connect.
`delivery`	No	Per-channel outcome. The two channels are independent with no cross-fallback, so each reports its own result.
`attribution`	No	Whether real session and machine identifiers were supplied. Unattributed notifications are delivered without creating a live session.
`notificationId`	No	Trace ID for this notification; provider acceptance does not confirm a person saw it.
`linkedCorrelationId`	No	Present only when context.askQuestion embedded a decision prompt. Pass it to wait_for_answer to collect the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

addedOutput schema / properties / notificationId

Added value: +{
+  "description": "Trace ID for this notification; provider acceptance does not confirm a person saw it.",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}

Changed2 schema fields changedOct 7, 2026

changedInput schema / properties / context / properties / type / description

Previous value: -"What kind of update this is. Use \"task_complete\" when work finished, \"error\" when something failed (delivered with high urgency), \"info\" for everything else."New value: +"What kind of update this is. Use \"task_complete\" when work finished, \"error\" when something failed (delivered with high urgency), \"info\" for everything else. Error severity describes this notification, not the agent session health."

addedOutput schema / properties / attribution

Added value: +{
+  "description": "Whether real session and machine identifiers were supplied. Unattributed notifications are delivered without creating a live session.",
+  "enum": [
+    "session",
+    "unattributed"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 6, 2026
- changedInput schema / properties / context / properties / askQuestion / properties / question / maxLength
```
Previous value: -500New value: +8000
```

Changed2 schema fields changedSep 2, 2026

addedInput schema / properties / env

Added value: +{
+  "description": "Set to \"test\" from a test suite. The notification is recorded in the activity feed and nothing is delivered to a phone or browser. The X-Pushary-Env: test header does the same for every call on the connection.",
+  "enum": [
+    "test"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / env

Added value: +{
+  "description": "Echoed when the call was test traffic.",
+  "enum": [
+    "test"
+  ],
+  "type": "string"
+}

Changed1 schema field changedAug 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "delivery": {
+      "additionalProperties": false,
+      "description": "Per-channel outcome. The two channels are independent with no cross-fallback, so each reports its own result.",
+      "properties": {
+        "mobile": {
+          "additionalProperties": false,
+          "properties": {
+            "recipients": {
+              "description": "Phones that accepted the push.",
+              "type": "number"
+            },
+            "status": {
+              "description": "Why mobile delivery reached nobody, present only when it reached nobody.",
+              "type": "string"
+            }
+          },
+          "required": [
+            "recipients"
+          ],
+          "type": "object"
+        },
+        "web": {
+          "additionalProperties": false,
+          "properties": {
+            "recipients": {
+              "description": "Browsers that accepted the push.",
+              "type": "number"
+            },
+            "status": {
+              "description": "Why web delivery reached nobody, present only when it reached nobody.",
+              "type": "string"
+            }
+          },
+          "required": [
+            "recipients"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "web",
+        "mobile"
+      ],
+      "type": "object"
+    },
+    "hint": {
+      "description": "What to do next, when there is a next step.",
+      "type": "string"
+    },
+    "linkedCorrelationId": {
+      "description": "Present only when context.askQuestion embedded a decision prompt. Pass it to wait_for_answer to collect the response.",
+      "type": "string"
+    },
+    "sent": {
+      "description": "Total devices reached, web plus mobile. Zero is a successful call that found nobody to deliver to, not an error.",
+      "type": "number"
+    },
+    "warning": {
+      "description": "Present only when the notification reached zero devices, naming what the user has to connect.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedJul 29, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already flag a non-readonly, non-idempotent, open-world, destructive action; the description adds real operational context beyond that: 'Sends real notifications' (contrasted against the env=test dry-run), that delivery follows account policy, and that a warning is returned when no channel is connected. It does not explain why destructiveHint is set or what happens to already-delivered notifications, so it falls short of full coverage.

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?

Front-loaded with purpose and the ask_user contrast, then delivery behavior, then the return/warning note, closing with the important 'Sends real notifications' caveat. Dense and mostly waste-free, though the final sentence slightly overlaps the opening framing.

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 13 parameters, nested objects, full schema coverage, an output schema, and rich annotations, the description fills exactly the remaining gaps: sibling routing, real-send semantics, and failure signaling. Nothing needed to call it correctly 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 structural meaning the schema only implies: context renders as a detail page, context.askQuestion produces a linked decision (pairing with wait_for_answer), and the targeting fields act as optional recipient filters. These are meaningful relationships beyond field-level docs.

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 ('Send a one-way notification to connected devices') plus the triggering conditions ('a requested update or a meaningful unattended result'). It explicitly contrasts itself with the sibling ask_user, so an agent can route between the two without opening either schema.

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?

Gives an explicit when-to-use rule ('one-way... use ask_user when an answer is needed') naming the alternative tool, and further clarifies that context.askQuestion creates a linked decision rather than a one-way send. Delivery scoping via account policy and recipient filters is also noted.

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

All Pushary tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?