Pushary

Send Push Notification

send_notification

Destructive

Send a one-way push notification to the user's phone and browser. Nothing is awaited; use ask_user instead when you need an answer back. Reach for this when a long-running task finishes and the user asked to be told, when the agent hits an error it cannot resolve on its own, or for any "notify me when my agent needs me" moment while the user is away from the terminal. By default the notification reaches every device connected to the site; narrow delivery with subscriberIds, externalIds, or tags. The optional context object turns the tap-through into a rich detail page (summary, bullet details, changed files, error info, next steps), and context.askQuestion embeds a decision prompt on that page, returning a linkedCorrelationId you can poll with wait_for_answer. Returns per-channel delivery counts for web and mobile, plus a warning when zero devices are connected. Works from Claude Code, Codex, Cursor, Hermes, or any MCP client; no Claude subscription is required. SIDE EFFECT: delivers real notifications to real devices immediately.

Input Schema

TableJSON Schema

Name	Required	Description
`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
`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.
`linkedCorrelationId`	No	Present only when context.askQuestion embedded a decision prompt. Pass it to wait_for_answer to collect the response.

TDQS

A4.9/5.0

Behavior5/5

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

Even though annotations include destructiveHint=true and readOnlyHint=false, the description adds crucial context: 'Nothing is awaited' (fire-and-forget behavior) and a SIDE EFFECT warning that it 'delivers real notifications to real devices immediately.' This goes beyond the boolean annotations and explains the real-world impact, fully aligning with the destructive hint without contradicting it.

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 long but well-structured, leading with purpose and then covering usage, targeting, context, side effects, and return. It earns its length for a 12-parameter tool, though some asides like 'Works from Claude Code, Codex, Cursor, Hermes...' are non-essential and could be trimmed. Overall it is efficient and front-loaded.

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?

The description covers usage scenarios, targeting options, the rich context detail page, askQuestion embedding, side effects, and return characteristics (per-channel counts and warnings). With an output schema present, it doesn't need to fully restate return types, and it still provides a complete operational picture for the agent to invoke this tool correctly.

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 description significantly enriches the schema (which already has 100% parameter coverage) by explaining the interaction between url and context ('Ignored if context is provided'), how targeting fields narrow delivery, and the askQuestion flow returning a linkedCorrelationId for use with wait_for_answer. It also clarifies the meaning of deliver counts and zero-device warnings, adding semantics far beyond the schema 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?

Opens with a specific verb and resource: 'Send a one-way push notification to the user's phone and browser.' It also clearly distinguishes itself from sibling ask_user by stating 'use ask_user instead when you need an answer back.' This makes the tool's purpose unambiguous and differentiates it from alternatives.

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: 'Reach for this when a long-running task finishes... when the agent hits an error it cannot resolve on its own, or for any 'notify me when my agent needs me' moment.' It also gives a clear exclusion: 'use ask_user instead when you need an answer back,' and mentions wait_for_answer for polling the response. This is textbook usage guidance.

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

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

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct role: ask_user blocks for a decision, send_notification is one-way, wait_for_answer polls an existing question, cancel_question retracts a pending one, and propose_scope is a specialized ratification flow. The only potential overlap is ask_user versus propose_scope, but the scope-specific contract and 'call ONCE at the start' guidance make the boundary clear.

Naming Consistency5/5

All five tools follow the same imperative verb_noun snake_case pattern: ask_user, cancel_question, propose_scope, send_notification, wait_for_answer. Even though the verbs differ, the structure is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for a push-notification and human-in-the-loop interaction server. There is no redundancy or padding; every tool maps to a distinct stage in the question/notification lifecycle.

Completeness5/5

The server covers the full interaction lifecycle: create a question (ask_user), wait for its answer (wait_for_answer), cancel it if obsolete (cancel_question), send one-way alerts (send_notification), and ratify scope before multi-step work (propose_scope). No obvious dead ends or missing critical operations exist for the stated purpose.

Resources

Need Help?