Skip to main content
Glama

Pushary

by com.pushary
OverviewDiscussionsAdmin

Server Details

An MCP connector that lets your AI agents ask you questions, request permission approvals, and send alerts as push notifications to your phone and mac notch, so you can unblock and approve your agents from anywhere.

Ownership verified
Status
Healthy
Uptime
100.0% over 77 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored across 6 tools

Disambiguation4/5

The tools mostly target distinct lifecycle steps: sending a question, waiting for its answer, cancelling it, proposing a scope contract, sending notifications, and managing reminders. The main overlap is between ask_user and propose_scope, since both send real questions, though propose_scope is framed as a specialized boundary-agreement flow.

Naming Consistency5/5

All tool names follow a clear snake_case verb_noun pattern: ask_user, cancel_question, propose_scope, schedule_reminder, send_notification, wait_for_answer. The convention is predictable and readable throughout.

Tool Count5/5

Six tools is well-scoped for an agent-to-user interaction server covering questions, notifications, and reminders. Each tool has a defensible role, even though schedule_reminder internally combines several reminder operations.

Completeness4/5

The surface covers the main question lifecycle (ask, wait, cancel), scope proposals, notifications, and reminders with schedule/list/retrieve/cancel operations. Minor gaps exist, such as no dedicated way to list all pending questions, but core workflows are covered.

Available Tools

6 tools
ask_userAsk User a QuestionA
Destructive
Inspect

Request an unresolved decision or missing input from the user through Pushary. Supports confirm, select and input questions. Delivery and waiting follow the account policy; a call waits at most 55 seconds and may return immediately. Returns the question state, answer when available, delivery information and handoff fields. answerUrl is optional. A pending question remains answerable after a poll ends. Sends a real question; it does not grant permission for other actions.

NameRequiredDescriptionDefault
envNoSet to "test" from a test suite. The question is stored and returned as pending, and nothing is delivered to a phone, browser or Slack. The X-Pushary-Env: test header does the same for every call on the connection.
tagsNoDeliver only to subscribers that have any of these tags.
typeNoQuestion type: confirm renders yes/no buttons, select renders the options list, input renders a free-text field.confirm
waitNotrue (default) blocks until the user answers or the timeout fires. Set false to return immediately with a pending correlationId and poll it yourself via wait_for_answer.
actionNoThe concrete operation about to happen, one line. Shown as the Action line. Cut to 500 chars.
intentNoThe user's stated task (from their last prompt), one line. Shown as the Intent line so the user can see why the agent stopped. Cut to 500 chars.
blockerNoThe single gating reason the agent stopped, one line. Shown as the Blocker line. Cut to 500 chars.
contextNoOne or two sentences about what the agent is working on, shown above the question so the user can decide without opening the terminal.
optionsNoThe 2 to 6 choices for a select question. Required when type is "select", ignored otherwise. The answered value is the chosen option string.
repoKeyNoStable repository identity for the working directory, e.g. "github.com/acme/api". Lets an approval routing rule scoped to one repository avoid governing another. Optional; omit it and only workspace-wide routing rules apply.
questionYesThe complete question, up to 8000 characters. Preserve every point. Notifications show a short preview; the answer interface shows the full question.
toolNameNoThe tool this approval is for (e.g. "Bash"), so the user can choose to always-allow it.
toolPathNoMACHINE-POPULATED. Exact absolute Write file_path from the runtime, for diagnostic correlation only. Models must omit it.
agentNameNoName of the agent asking, format "{Agent} - {project}" (e.g. "Claude Code - myproject"). Shown in the notification title so the user knows which session needs them. Falls back to the MCP client name if omitted. Cut to 100 chars.
machineIdNoStable machine id of the asking agent, so two machines never collapse into one session.
questionsNoONE question, in the richer Claude-compatible shape: a header, per-option descriptions, multiSelect, and an optional write-in. Exactly one keeps already-installed clients answerable; asking several means several calls. Runtime-populated; ordinary callers should omit it and use question/type/options.
requestIdNoMACHINE-POPULATED. The CALLER's own identifier for one logical invocation, used only when the runtime supplies no toolUseId. Mint it once, outside your retry loop, and send the same value on every attempt, so three retries of one ask become one decision. Do NOT derive it from the question text or reuse it across two deliberate asks: both collapse a real second question into the first one's answer. If you are a model deciding to call this tool, omit this field.
scopePathNoSet ONLY when this approval exists because the path falls outside the scope the user ratified via propose_scope. Approving then widens the run scope to include this exact path, so the user is not asked again for the same area.
sessionIdNoOpaque per-session id of the asking agent, so parallel sessions are attributed separately.
timeoutMsNoHow long this call blocks, in milliseconds (max 55000). Defaults to the site policy timeout. Ordinary questions stay open until answered or cancelled; through a connector they close 10 minutes after they are sent. A timeout ends this poll only; follow up with wait_for_answer.
toolUseIdNoMACHINE-POPULATED. The agent RUNTIME's own identifier for the tool call this approval gates, forwarded verbatim by a hook that received it. Do NOT invent, guess, derive, or reuse a value: two different questions sent under the same id collapse into one, and the second one never reaches a human. If you are a model deciding to call this tool, omit this field.
actionBodyNoThe diff (Edit/Write) or full command (Bash/apply_patch), secret-redacted and size-capped. Rendered as a collapsible detail block; never used as the push body.
toolTargetNoCompact target of the tool call (e.g. the command head "git push" for Bash, or a file extension like ".ts" for Edit/Write). Used to mine policy suggestions.
waitEndsAtNoMACHINE-POPULATED. When the agent hook stops waiting live and hands control back to the terminal. The question may remain answerable after this time. Ordinary callers should omit it.
callbackUrlNoWebhook URL that receives a POST with the answer when the user responds, signed with the X-Pushary-Signature header. Useful when the agent process may exit before the answer arrives.
externalIdsNoDeliver only to subscribers matching these external IDs.
pausedAwareNoMACHINE-POPULATED. true from a hook that ends a paused approval exactly as the same approval unanswered after its full wait. Any other value is ignored. If you are a model deciding to call this tool, omit this field.
placeholderNoHint text shown inside the free-text field for input questions
questionOwnerNoMACHINE-POPULATED. Ownership supplied by the supported personal Codex bridge. Models must omit this field.
subscriberIdsNoDeliver only to these subscriber IDs. Omit all targeting fields to reach every connected device.
permissionModeNoMACHINE-POPULATED. The agent runtime's own permission or approval mode for the tool call this approval gates, recorded with the decision. Any other value is ignored. If you are a model deciding to call this tool, omit this field.
sessionToolAwareNoMACHINE-POPULATED. Set by a Pushary hook whose engine applies a session tool grant with its risky-command ceiling, so the grant is only offered where it takes effect. If you are a model deciding to call this tool, omit this field.
localSurfaceAvailableNoMACHINE-POPULATED. false from a hook that cannot show its own approval prompt for this call, so the phone is asked every time and never spared for presence at the keyboard. Any other value is ignored. If you are a model deciding to call this tool, omit this field.

Output Schema

NameRequiredDescription
envNoEchoed when the call was test traffic.
heldNoPresent when the question was stored but deliberately not delivered: test traffic, or a permission ask with no toolName and no sessionId.
hintNoWhat to do next, when there is a next step.
modeNoThe site delivery mode that stopped this call from waiting.
noteNoFree text the user added alongside their answer.
typeYesThe question type that was rendered.
valueNoThe user's answer: "yes" or "no" for confirm, the chosen option for select, the typed text for input.
pausedNoTrue when nothing was sent because the last approvals in this session went unanswered. Withdraw the question, then end the call as it would end unanswered.
statusNoThe question state. Only pending is a live unanswered wait; cancelled, expired, missing, and unavailable must not be described as timeouts.
warningNoPresent only when no channel is connected, naming what the user has to connect.
answeredNoTrue once the user responded. Absent on the wait:false path, where nothing was awaited.
deliveryNoPer-channel reach for the push carrying this question.
questionYesThe question exactly as the user saw it.
timedOutNoTrue when the initial wait ended while the question was still live. Poll once with wait_for_answer, then follow handoffAction when present, otherwise nextAction.
answerUrlNoOptional signed-in dashboard page where the user can answer this question.
noDevicesNoTrue when no phone, browser, or Slack channel could receive the question. Do not wait; follow handoffAction immediately.
nextActionNoBackward-compatible next step: keep waiting while pending or ask in the current client. Follow handoffAction first when present.
suppressedNoTrue when the PHONE push was deliberately held because a terminal on this machine is active, or, alongside paused, because nothing was sent at all. It says nothing about the notch, the dashboard or Slack, which are unaffected and may still be showing this question. A caller with no screen of its own should treat it as the terminal's to answer; a caller that can render the question itself should keep waiting unless paused is true.
waitEndsAtNoWhen the agent hook stops waiting live. On an idempotent replay this is the original question's deadline, which the hook must reuse.
answerSourceNoRecorded answering surface, when known. Missing provenance is not proof of a phone answer; sandbox is simulated.
deliveryModeNoEffective delivery policy for this decision.
correlationIdYesId of the question that was created. Pass it to wait_for_answer to keep waiting, or to cancel_question to retract it.
handoffActionNoRace-safe directive for updated clients. Takes precedence over nextAction: cancel before asking in the current client, or stop the handoff.
policyTimeoutMsNoPolicy wait window in milliseconds. Callers must also honor their host deadline.
expiresInSecondsNoHow long the question stays answerable.

TDQS

A4/5.0
Behavior4/5

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

Adds real behavioral context beyond the annotations: delivery and waiting follow account policy, a call blocks at most 55 seconds and may return immediately, and a pending question stays answerable after a poll ends. That informs retry and follow-up decisions the structured hints (destructive/openWorld/idempotent) do not convey. It stops short of describing what happens on duplicate or abandoned asks.

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 what the tool does, then timing, then return shape, then the safety boundary — a sensible order in five short sentences. The orphaned "answerUrl is optional" sentence is the one line that does not clearly earn its place.

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?

Covers purpose, timing envelope, poll-versus-wait behavior, return contents and the non-permission boundary, which is enough for an agent to call this correctly despite the large schema. The many machine-populated parameters are flagged in the schema itself, and an output schema exists, so the description need not restate return structure.

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

Parameters3/5

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

Schema coverage is 100% across 33 parameters, so the schema already carries the burden and baseline 3 applies. The description contributes only one param-level note ("answerUrl is optional"), and answerUrl is a return field rather than an input, so it adds little.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: requesting an unresolved decision or missing input from a human. It also carves a boundary ("Sends a real question; it does not grant permission for other actions"), but never names the sibling it replaces, so an agent must still infer why ask_user rather than send_notification.

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?

The first clause gives a clear trigger condition: an unresolved decision or missing input that only the user can supply. The closing sentence rules out using it as a permission grant. No explicit exclusion against send_notification or cancel_question, which are the obvious adjacent choices.

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

cancel_questionCancel Pending QuestionA
DestructiveIdempotent
Inspect

Retract a pending question that is no longer needed or is moving to the current client. Returns cancelled:true only when a pending question was removed. False may mean it was already answered, expired, missing or unavailable. An unavailable state includes handoffAction:stop because cancellation could not safely inspect or fence the question. Does not retract an answer already recorded.

NameRequiredDescriptionDefault
handoffNoTrue when you are cancelling because you are about to ask the same question in the current client. For the next minute the Pushary hook then lets your own question tool through instead of sending it back to the phone. Set automatically whenever a live question is cancelled.
correlationIdYesThe correlationId of the pending question to cancel, as returned by ask_user or send_notification

Output Schema

NameRequiredDescription
hintNoWhat to do when cancellation could not safely inspect the question.
statusNoPresent when Pushary could not safely read or fence the question state.
cancelledYesTrue when a still-pending question was removed. False when it was already terminal, missing, or unavailable; inspect status and handoffAction when present.
askHandoffNoTrue when the session was marked as handing off to the current client, so the hook will not re-ask on the phone for the next minute.
correlationIdYesThe question this result refers to, echoed back.
handoffActionNoStop rather than opening another answer surface when the question state is unavailable.

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations by explaining the return contract ('cancelled:true only when a pending question was removed') and enumerating why false can occur (answered, expired, missing, unavailable, handoffAction:stop). This is exactly the kind of failure-mode detail an agent needs for a destructive operation.

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?

Four tight sentences, front-loaded with the action and scope, then the return contract and failure modes. Every sentence carries information and none is wasted.

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?

An output schema exists and the description still usefully explains the boolean return contract; annotations cover the destructive/idempotent profile and the description supplies the safety caveats. Nothing material is missing for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so both correlationId and handoff are already documented in the schema. The description's 'moving to the current client' wording loosely reinforces the handoff concept but adds no syntax or format detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Retract a pending question') and adds scope ('no longer needed or is moving to the current client'), so the agent can tell it apart from ask_user and wait_for_answer. It does not name a sibling alternative explicitly, which keeps it below a 5.

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 conditions for use (question no longer needed, or moving to the current client) and implicitly excludes answered questions via 'Does not retract an answer already recorded.' No explicit alternatives such as wait_for_answer are mentioned, so it stops short of a 5.

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

propose_scopePropose Run ScopeA
Destructive
Inspect

Request agreement on an unresolved or user-requested boundary for this session. Sends a real scope question and returns ratified, answered, contract and enforcement information. Only supported hooks can enforce file paths on path-bearing tool calls; promises are recorded but not enforced. Empty enforces means no automatic boundary checking. A contract never overrides host permissions or authorizes a separate action. The call waits at most 55 seconds; a pending proposal remains answerable after the call returns.

NameRequiredDescriptionDefault
doneWhenYesWhat "finished" means for this run, one or two lines. Carried for the human to judge against; never enforced automatically.
promisesNoBoundaries that are not file paths: recipients, channels, spend limits, systems you will not open. For an agent whose work is not code (marketing, sales, support, operations), this is where the boundary goes. Shown to the user labelled "Promised, not checked" and recorded in the ledger, but NEVER enforced, because the gate judges a file path and these have none. Do not put these in allowedPaths.
agentNameNoName of the agent asking, format "{Agent} - {project}".
machineIdNoStable machine id, so two machines never collapse into one session.
sessionIdYesYour per-session id, as your client reports it for THIS run. Required, and it is the key the gate reads the contract back by: a value that matches no live session still returns ratified:true and enforces nothing. Never invent one, and never reuse one from another run.
timeoutMsNoHow long this call blocks, in milliseconds (max 55000).
allowedPathsNoGlobs you intend to change, e.g. ["src/**", "docs/*.md"]. File paths only: a word that is not a path ("hubspot", "summer-campaign") matches no file and makes every edit read as out of scope. A bare directory is expanded for you, so "docs" also covers "docs/**". Omit or leave empty to propose no path restriction, which the user is told plainly.
offLimitsPathsNoGlobs you promise not to touch, e.g. [".env*", "infra/**"]. These win wherever they overlap allowedPaths. A leading "**/" needs a directory before it, so "**/.env*" is expanded for you to also cover a root ".env".

Output Schema

NameRequiredDescription
noteNoPresent only when the scope is not in force, saying what to do instead of proceeding.
valueNoThe raw answer behind ratified, "yes" or "no".
statusNoThe underlying scope-question state.
answeredYesTrue when the user responded at all. Answered but not ratified means they declined, so ask what scope they want rather than proceeding.
contractYesThe scope as it is STORED and gated, echoed back so you and the server hold the same contract. Paths are the EXPANDED ones: a bare directory and a leading "**/" each gain the variant they would otherwise have missed, so this can contain more entries than you sent. The user was shown the paths you sent, because the added twin says the same thing to a reader; the expansion only changes what the matcher covers, never what it means.
enforcesYesWhat this contract CONTAINS that can be checked, not a promise about what the gate on this machine will do. An EMPTY array means nothing here is checked automatically: the contract is a recorded promise, and every action stays governed by the permission policy exactly as it was before. Never tell the user a boundary is enforced when this is empty.
hookSeenNoWhether any agent hook has actually reported this sessionId. FALSE means the gate will look this contract up under a key that does not exist, so nothing will be checked no matter what ratified says: fix the session id rather than proceeding as if a scope were in force. ABSENT means the check could not run, which is not evidence either way.
ratifiedYesTrue only on an explicit yes. The contract is in force for this session only when this is true; anything else means proceed as if no scope was agreed.
nextActionNoKeep waiting with the same correlationId while the proposal is pending. Follow handoffAction first when present; a poll ending does not expire or cancel the proposal.
correlationIdYesId of the scope question. Keep waiting with this id while the question is pending.
handoffActionNoRace-safe directive for updated clients. Takes precedence over nextAction.
enforcementNoteNoPresent only when there is something true to say about the limits of this contract. Repeat it to the user rather than paraphrasing it.

TDQS

A4.1/5.0
Behavior5/5

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

Annotations declare mutation, open-world, and destructive behavior, and the description adds substantial context beyond them: the 55-second blocking cap, that a pending proposal remains answerable after return, that promises are recorded but never enforced, that an empty allowlist means no automatic boundary checking, and that a contract never overrides host permissions. These are exactly the side-effect and authorization facts an agent needs before invoking a destructive tool.

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?

Five dense sentences, front-loaded with purpose and then the enforcement caveats; each sentence carries a distinct constraint rather than restating the schema. It is slightly packed with caveats and could be broken up, but there is no filler.

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?

For an 8-parameter destructive tool with an output schema, the description covers the blocking window, post-timeout answerability, enforcement limits, and the permissions ceiling. Return-value shapes are handled by the output schema, so nothing critical is missing for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100% and the individual parameter docs are unusually thorough (sessionId keying, promises vs. allowedPaths distinction, glob expansion rules). The description adds little parameter-level detail beyond repeating that promises are recorded but not enforced, so the baseline 3 for a fully documented schema applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Request agreement on an unresolved or user-requested boundary for this session' and explains that it returns ratified/answered/contract/enforcement information. This is clearly distinct from the generic ask_user sibling, though the description never names that alternative explicitly, so sibling differentiation is left implicit.

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?

It states the triggering condition ('unresolved or user-requested boundary for this session') and some constraints on when enforcement applies ('Only supported hooks can enforce file paths on path-bearing tool calls'). However, it never says when to use ask_user or wait_for_answer instead, which would be the natural routing decision for an agent facing these siblings.

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

schedule_reminderSchedule a Personal ReminderA
Destructive
Inspect

Schedule, list, retrieve or cancel a personal Pushary reminder for the authenticated user. Scheduled reminders can arrive after the agent exits. One-time only; up to 30 days away, 25 pending per user/site. Scheduling requires body and either inMinutes or at with an explicit UTC offset. requestId identifies one schedule across retries. reminderId retrieves its outcome; no arguments lists pending reminders; cancelReminderId cancels a pending reminder. Returns the scheduled time, state and any delivery warning. Delivery respects stop/mute and active membership. Does not schedule agent work or customer campaigns. API reference: https://pushary.com/docs/agents/reference/tools#schedule_reminder

NameRequiredDescriptionDefault
atNoFuture ISO 8601 timestamp with explicit UTC offset or Z, at most 30 days away. Resolve the user's local time and timezone before scheduling; never guess a timezone.
envNo
bodyNoWhat to remind the authenticated user about, at most 180 UTF-16 units after secret redaction (emoji may use two). Omit all fields to list their pending reminders.
titleNo
agentNameNo
inMinutesNoMinutes from the server clock; use for timers and relative reminders.
machineIdNo
requestIdNoUnique ID for this scheduling operation. Reuse it unchanged on retries to return the original reminder, including after it settles.
sessionIdNo
reminderIdNoLook up your reminder, including its final outcome and delivery status, instead of scheduling or cancelling.
cancelReminderIdNoCancel this user's scheduled reminder instead of creating one. Already-dispatching reminders cannot be cancelled.

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial context beyond annotations: reminders can fire after the agent exits, delivery respects stop/mute and active membership, limits are given, and return values (scheduled time, state, delivery warning) are described. Minor gap: it does not clarify whether cancellation or scheduling carries side effects an agent should warn the user about, and the requestId retry semantics sit in mild tension with idempotentHint=false.

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 mode routing, then constraints, then return values, then exclusions, then a reference link. Dense but nearly every clause carries information; the single run-on paragraph is harder to scan than a short bulleted mode list.

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?

For a multi-mode tool with no output schema, the description supplies return shape, limits, delivery caveats, idempotent retry guidance and a docs link. An agent can act correctly without opening anything else.

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?

With 55% schema coverage over 11 params, the description meaningfully compensates for the key fields: body+inMinutes/at requirement, explicit UTC offset, requestId retry semantics, reminderId outcome lookup, and cancelReminderId. It leaves env, title, agentName, machineId and sessionId unexplained, which are presumably housekeeping fields.

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 specific verbs (schedule, list, retrieve, cancel) applied to a precisely scoped resource: a personal Pushary reminder for the authenticated user. The closing exclusion ('Does not schedule agent work or customer campaigns') plus sibling context makes the boundary 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?

Each invocation mode is routed explicitly: no arguments lists pending, reminderId retrieves outcome, cancelReminderId cancels, and scheduling requires body plus inMinutes or at. Constraints (one-time only, 30 days, 25 pending per user/site) tell the agent when an attempt will fail.

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

send_notificationSend Push NotificationA
Destructive
Inspect

Send a notification to connected devices for a requested update or a meaningful unattended result, such as a finished task. Delivery follows the account policy and optional recipient filters. context adds a detail page. context.askQuestion is kept for older clients; ask questions with ask_user. Returns web/mobile delivery counts and a warning when no delivery channel is connected. Sends real notifications. API reference: https://pushary.com/docs/agents/reference/tools#send_notification

NameRequiredDescriptionDefault
envNoSet 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.
urlNoURL opened when the user taps the notification. Ignored if context is provided, because a context detail page URL is generated automatically.
bodyYesNotification body text (max 500 chars). One or two sentences the user can act on without opening anything.
tagsNoDeliver only to subscribers that have any of these tags.
titleYesNotification title shown on the lock screen (max 100 chars). Lead with the outcome, e.g. "Build finished" or "Migration failed".
contextNoStructured 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.
iconUrlNoURL of the notification icon image
imageUrlNoURL of a large image shown in the notification
agentNameNoName 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.
machineIdNoStable machine id of the sending agent, so two machines never collapse into one session.
sessionIdNoOpaque per-session id of the sending agent, so parallel sessions are attributed separately in the activity feed.
externalIdsNoDeliver only to subscribers matching these external IDs.
subscriberIdsNoDeliver only to these subscriber IDs. Omit all targeting fields to reach every connected device.

Output Schema

NameRequiredDescription
envNoEchoed when the call was test traffic.
hintNoWhat to do next, when there is a next step.
sentNoTotal devices reached, web plus mobile. Zero is a successful call that found nobody to deliver to, not an error.
statusNoOutcome when a session completion is recorded for delivery once per turn.
updatesNoEffective update delivery setting and the policy that selected it.
warningNoPresent only when the notification reached zero devices, naming what the user has to connect.
deliveryNoPer-channel outcome. The two channels are independent with no cross-fallback, so each reports its own result.
suppressedNoReason the notification was recorded without a push.
attributionNoWhether real session and machine identifiers were supplied. Unattributed notifications are delivered without creating a live session.
completionIdNoRecorded completion identifier, or null when no completion was recorded.
notificationIdNoTrace ID for this notification; provider acceptance does not confirm a person saw it.
linkedCorrelationIdNoPresent only when context.askQuestion embedded a decision prompt. Pass it to wait_for_answer to collect the response.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and openWorldHint=true; the description supplies the missing context that 'destructive' here means sending real user-visible notifications rather than data loss. It also discloses delivery-policy behavior, the 'no delivery channel connected' warning, and return values (web/mobile counts), which is real information beyond the annotations.

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?

Purpose and trigger conditions come first, followed by behavior and return values, then the API reference. It is a bit listy and the standalone 'Sends real notifications.' sentence is terse, but every sentence carries information an agent needs.

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?

For a 13-parameter tool with a nested context object, a deprecation trap, and a real-world side effect, the description covers purpose, side effects, delivery semantics, return shape, and the sibling alternative. The output schema and rich parameter descriptions handle the rest.

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 coverage is 100%, so the baseline is 3; the description still adds value by explaining that context renders a detail page and by giving migration guidance on the deprecated askQuestion field. It does not restate the length limits or targeting fields, deferring correctly to the schema.

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 notification to connected devices') plus the legitimate triggering conditions ('a requested update or a meaningful unattended result, such as a finished task'). It also draws the boundary against the ask_user sibling, so an agent can distinguish it without opening schemas.

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 use conditions (requested update, finished task) and routes question-asking to ask_user rather than the deprecated context.askQuestion path. It stops short of an explicit 'do not use for X' exclusion list, but the alternative is named with its scope.

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

wait_for_answerWait for User AnswerA
Read-onlyIdempotent
Inspect

Read the answer or current state of an existing Pushary question by its correlationId. Waits up to timeoutMs, capped at 55 seconds. Returns answered, the answer when available, status and handoff information. Only pending is a live unanswered question; cancelled, expired, missing and unavailable are terminal states. Does not send another question.

NameRequiredDescriptionDefault
timeoutMsNoHow long this one poll blocks, in milliseconds (default 30000, max 55000). Follow handoffAction when present, otherwise nextAction.
correlationIdYesThe correlationId from an earlier ask_user response, or the linkedCorrelationId from a send_notification with an embedded askQuestion

Output Schema

NameRequiredDescription
hintNoWhat to do next, when there is a next step.
noteNoFree text the user added alongside their answer.
valueNoThe user's answer: "yes" or "no" for confirm, the chosen option for select, the typed text for input. Present only when answered is true.
statusYesThe actual question state. Only pending is a live unanswered wait.
answeredYesTrue once the user responded. False means follow handoffAction when present, otherwise nextAction; do not guess that every unanswered state is a timeout.
nextActionNoBackward-compatible next step for older clients. Follow handoffAction first when present.
answerSourceNoRecorded answering surface, when known. Missing provenance is not proof of a phone answer; sandbox is simulated.
handoffActionNoRace-safe directive for updated clients. Takes precedence over nextAction.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's added disclosure of the 55-second block cap and the state taxonomy (pending is live; cancelled/expired/missing/unavailable are terminal) is genuine value beyond structured data. It does not state whether repeated polling has rate limits or side effects on server state, but that gap is minor given the annotations.

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 core operation and its cap are front-loaded, and the four sentences are dense with usable information. The return-field enumeration is slightly redundant given the output schema exists, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter polling tool with full schema coverage, annotations, and an output schema, the description covers the essentials: what is read, how long it blocks, and what the return states mean. The return-field listing is the only overlap with the output schema.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are documented in-schema, including the 55000 ms maximum and the handoffAction/nextAction follow-up instruction. The description repeats the cap and adds the correlationId's originating context, but supplies no format or unit detail the schema lacks; baseline 3 applies.

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+resource ('Read the answer or current state of an existing Pushary question by its correlationId') and explicitly distinguishes itself from the sibling ask_user with 'Does not send another question.' An agent can select it over ask_user/send_notification without opening any schema.

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?

Establishes the post-ask context through 'an existing Pushary question' and 'the correlationId from an earlier ask_user response,' which tells the agent when this tool applies. It rules out the send case, but does not explicitly name ask_user or offer branching guidance versus siblings like schedule_reminder or cancel_question.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedask_user1 field changed
      • changedOutput schema / properties / suppressed / description
        Previous value: -"True when the PHONE push was deliberately held because a terminal on this machine is active. It says nothing about the notch, the dashboard or Slack, which are unaffected and may still be showing this question. A caller with no screen of its own should treat it as the terminal's to answer; a caller that can render the question itself should keep waiting."New value: +"True when the PHONE push was deliberately held because a terminal on this machine is active, or, alongside paused, because nothing was sent at all. It says nothing about the notch, the dashboard or Slack, which are unaffected and may still be showing this question. A caller with no screen of its own should treat it as the terminal's to answer; a caller that can render the question itself should keep waiting unless paused is true."
  2. 2 tool updates
    • Changedask_user1 field changed
      • changedInput schema / properties / timeoutMs / description
        Previous value: -"How long this call blocks, in milliseconds (max 55000). Defaults to the site policy timeout. Ordinary questions stay open until answered or cancelled. A timeout ends this poll only; follow up with wait_for_answer."New value: +"How long this call blocks, in milliseconds (max 55000). Defaults to the site policy timeout. Ordinary questions stay open until answered or cancelled; through a connector they close 10 minutes after they are sent. A timeout ends this poll only; follow up with wait_for_answer."
    • Changedsend_notification1 field changed
      • changedInput schema / properties / context / properties / askQuestion / description
        Previous value: -"Embed a decision prompt on the detail page. The response includes a linkedCorrelationId; pass it to wait_for_answer to collect the answer. The embedded question expires 10 minutes after it is created. Only for a decision about unfinished work. Not for asking what to do next once the requested work is complete, unless the user asked you to."New value: +"Kept for older clients. To ask the user something, call ask_user instead: it stays open at least as long, offers lock-screen answers on confirm questions, and, unless the agent connects through a connector, stays open until answered or cancelled. An embedded question appears on the detail page, closes 10 minutes after it is created, and returns a linkedCorrelationId for wait_for_answer. Only for a decision about unfinished work. Not for asking what to do next once the requested work is complete, unless the user asked you to."
  3. 1 tool update
    • Changedsend_notification4 fields changed
      • addedOutput schema / properties / completionId
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Recorded completion identifier, or null when no completion was recorded."
+}
      • addedOutput schema / properties / status
        Added value: +{
+  "description": "Outcome when a session completion is recorded for delivery once per turn.",
+  "enum": [
+    "recorded",
+    "ignored"
+  ],
+  "type": "string"
+}
      • addedOutput schema / properties / suppressed
        Added value: +{
+  "description": "Reason the notification was recorded without a push.",
+  "type": "string"
+}
      • addedOutput schema / properties / updates
        Added value: +{
+  "additionalProperties": false,
+  "description": "Effective update delivery setting and the policy that selected it.",
+  "properties": {
+    "mode": {
+      "enum": [
+        "both",
+        "phone",
+        "browser",
+        "none"
+      ],
+      "type": "string"
+    },
+    "source": {
+      "enum": [
+        "kill",
+        "snooze",
+        "setting",
+        "mode",
+        "default"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "mode",
+    "source"
+  ],
+  "type": "object"
+}
  4. 1 tool update
    • Changedsend_notification1 field changed
      • changedInput schema / properties / context / properties / askQuestion / description
        Previous value: -"Embed a decision prompt on the detail page. The response includes a linkedCorrelationId; pass it to wait_for_answer to collect the answer. The embedded question expires 10 minutes after it is created."New value: +"Embed a decision prompt on the detail page. The response includes a linkedCorrelationId; pass it to wait_for_answer to collect the answer. The embedded question expires 10 minutes after it is created. Only for a decision about unfinished work. Not for asking what to do next once the requested work is complete, unless the user asked you to."
  5. 1 tool update
    • Addedschedule_reminder
  6. 1 tool update
    • Changedask_user1 field changed
      • addedInput schema / properties / questionOwner
        Added value: +{
+  "additionalProperties": {},
+  "description": "MACHINE-POPULATED. Ownership supplied by the supported personal Codex bridge. Models must omit this field.",
+  "properties": {},
+  "type": "object"
+}
  7. 1 tool update
    • Changedask_user1 field changed
      • changedInput schema / properties / timeoutMs / description
        Previous value: -"How long this call blocks, in milliseconds (max 55000). Defaults to the site policy timeout. The question stays open for 10 minutes regardless, so a timeout here is not a refusal; follow up with wait_for_answer."New value: +"How long this call blocks, in milliseconds (max 55000). Defaults to the site policy timeout. Ordinary questions stay open until answered or cancelled. A timeout ends this poll only; follow up with wait_for_answer."
  8. 1 tool update
    • Changedsend_notification1 field changed
      • 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"
+}
  9. 1 tool update
    • Changedsend_notification2 fields changed
      • 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"
+}
  10. 1 tool update
    • Changedpropose_scope1 field changed
      • changedOutput schema / properties / nextAction / description
        Previous value: -"Poll one live question once; otherwise ask in the current chat whether to continue without an enforced scope."New value: +"Keep waiting with the same correlationId while the proposal is pending. Follow handoffAction first when present; a poll ending does not expire or cancel the proposal."
  11. 3 tool updates
    • Changedask_user4 fields changed
      • changedInput schema / properties / question / description
        Previous value: -"The question shown on the user's lock screen (500 chars; a longer one is cut). Phrase it so it is answerable at a glance; put background in context instead."New value: +"The complete question, up to 8000 characters. Preserve every point. Notifications show a short preview; the answer interface shows the full question."
      • addedInput schema / properties / question / maxLength
        Added value: +8000
      • changedInput schema / properties / questions / items / properties / question / maxLength
        Previous value: -500New value: +8000
      • changedOutput schema / properties / nextAction / description
        Previous value: -"Backward-compatible next step: poll once or ask in the current client. Follow handoffAction first when present."New value: +"Backward-compatible next step: keep waiting while pending or ask in the current client. Follow handoffAction first when present."
    • Changedpropose_scope1 field changed
      • changedOutput schema / properties / correlationId / description
        Previous value: -"Id of the scope question. Pass it to wait_for_answer once when the first wait times out."New value: +"Id of the scope question. Keep waiting with this id while the question is pending."
    • Changedsend_notification1 field changed
      • changedInput schema / properties / context / properties / askQuestion / properties / question / maxLength
        Previous value: -500New value: +8000
  12. 1 tool update
    • Changedask_user1 field changed
      • addedInput schema / properties / permissionMode
        Added value: +{
+  "description": "MACHINE-POPULATED. The agent runtime's own permission or approval mode for the tool call this approval gates, recorded with the decision. Any other value is ignored. If you are a model deciding to call this tool, omit this field.",
+  "maxLength": 64,
+  "type": "string"
+}
  13. 1 tool update
    • Changedask_user2 fields changed
      • addedInput schema / properties / pausedAware
        Added value: +{
+  "description": "MACHINE-POPULATED. true from a hook that ends a paused approval exactly as the same approval unanswered after its full wait. Any other value is ignored. If you are a model deciding to call this tool, omit this field.",
+  "type": "boolean"
+}
      • addedOutput schema / properties / paused
        Added value: +{
+  "description": "True when nothing was sent because the last approvals in this session went unanswered. Withdraw the question, then end the call as it would end unanswered.",
+  "type": "boolean"
+}
  14. 1 tool update
    • Changedask_user1 field changed
      • addedInput schema / properties / localSurfaceAvailable
        Added value: +{
+  "description": "MACHINE-POPULATED. false from a hook that cannot show its own approval prompt for this call, so the phone is asked every time and never spared for presence at the keyboard. Any other value is ignored. If you are a model deciding to call this tool, omit this field.",
+  "type": "boolean"
+}
  15. 1 tool update
    • Changedask_user1 field changed
      • changedOutput schema / properties / answerUrl / description
        Previous value: -"The signed-in dashboard page where this question is waiting. Print it when you tell the user you are waiting, so they can answer from a browser."New value: +"Optional signed-in dashboard page where the user can answer this question."
  16. 1 tool update
    • Changedask_user14 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"The concrete operation about to happen, one line. Shown as the Action line."New value: +"The concrete operation about to happen, one line. Shown as the Action line. Cut to 500 chars."
      • removedInput schema / properties / action / maxLength
        Removed value: -500
      • addedInput schema / properties / action / minLength
        Added value: +0
      • changedInput schema / properties / agentName / description
        Previous value: -"Name of the agent asking, format \"{Agent} - {project}\" (e.g. \"Claude Code - myproject\"). Shown in the notification title so the user knows which session needs them. Falls back to the MCP client name if omitted."New value: +"Name of the agent asking, format \"{Agent} - {project}\" (e.g. \"Claude Code - myproject\"). Shown in the notification title so the user knows which session needs them. Falls back to the MCP client name if omitted. Cut to 100 chars."
      • removedInput schema / properties / agentName / maxLength
        Removed value: -100
      • addedInput schema / properties / agentName / minLength
        Added value: +0
      • changedInput schema / properties / blocker / description
        Previous value: -"The single gating reason the agent stopped, one line. Shown as the Blocker line."New value: +"The single gating reason the agent stopped, one line. Shown as the Blocker line. Cut to 500 chars."
      • removedInput schema / properties / blocker / maxLength
        Removed value: -500
      • addedInput schema / properties / blocker / minLength
        Added value: +0
      • changedInput schema / properties / intent / description
        Previous value: -"The user's stated task (from their last prompt), one line. Shown as the Intent line so the user can see why the agent stopped."New value: +"The user's stated task (from their last prompt), one line. Shown as the Intent line so the user can see why the agent stopped. Cut to 500 chars."
      • removedInput schema / properties / intent / maxLength
        Removed value: -500
      • addedInput schema / properties / intent / minLength
        Added value: +0
      • changedInput schema / properties / question / description
        Previous value: -"The question shown on the user's lock screen (max 500 chars). Phrase it so it is answerable at a glance; put background in context instead."New value: +"The question shown on the user's lock screen (500 chars; a longer one is cut). Phrase it so it is answerable at a glance; put background in context instead."
      • removedInput schema / properties / question / maxLength
        Removed value: -500
  17. 1 tool update
    • Changedask_user3 fields changed
      • addedInput schema / properties / toolPath / format
        Added value: +"starts_with"
      • changedInput schema / properties / waitEndsAt / pattern
        Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
      • changedOutput schema / properties / waitEndsAt / pattern
        Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"
  18. 1 tool update
    • Changedask_user1 field changed
      • addedInput schema / properties / sessionToolAware
        Added value: +{
+  "description": "MACHINE-POPULATED. Set by a Pushary hook whose engine applies a session tool grant with its risky-command ceiling, so the grant is only offered where it takes effect. If you are a model deciding to call this tool, omit this field.",
+  "type": "boolean"
+}

Publisher details

Operator
https://ralphnex.com
Operator website
https://pushary.com
Vendor relationship
Unknown
Documentation
https://pushary.com/docs
Trust center
Unknown
Restrictions
Unknown

Related MCP Connectors

Related MCP Servers

  • call-a-human-mcp

    nishantmodak
    A
    license
    A
    quality
    A
    maintenance
    An MCP server that enables AI agents to pause and request human approval or information via Slack, Telegram, or macOS dialogs before proceeding with actions.
    2
    15
    Apache 2.0

  • @zeph-to/mcp-server

    zeph-to
    A
    license
    A
    quality
    A
    maintenance
    MCP server for AI agents to send notifications, copy to clipboard, request confirmations, and collect text input from users across their devices.
    10
    45 npm
    Apache 2.0

  • Ask Agent

    coder-mil
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables any MCP-compatible AI agent to ask humans questions in real time via a mobile-friendly PWA with push notifications, operating local-first without third-party services.
    MIT
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