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 56 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored across 5 tools

Disambiguation4/5

Each tool has a distinct role: ask_user asks a decision, propose_scope asks for a boundary, send_notification is one-way, wait_for_answer reads state, and cancel_question retracts. ask_user and propose_scope both 'send a real question,' which could cause some initial confusion, but the descriptions clearly delineate decision input versus scope agreement.

Naming Consistency5/5

All five tools follow a clean verb_noun snake_case pattern (ask_user, cancel_question, propose_scope, send_notification, wait_for_answer). No mixed conventions or vague verbs.

Tool Count5/5

Five tools is well-scoped for a human-in-the-loop decision/question service. Each tool earns its place across the ask/wait/cancel/notify/scope lifecycle without redundancy.

Completeness4/5

The lifecycle is largely covered: create questions, read/await answers, cancel them, send notifications, and propose scope. The notable gap is the absence of an enumerate/list-pending-questions tool, so recovering a lost question ID depends on previously returned handles.

Available Tools

6 tools
ask_userAsk User a Question
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. Use wait_for_answer to read a pending result and cancel_question to retract it. Sends a real question; it does not grant permission for other actions.

ParametersJSON Schema
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. 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

ParametersJSON 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. 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.
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.
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.

ParametersJSON Schema
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

ParametersJSON 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.1/5.0
Behavior4/5

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

Annotations declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), and the description usefully extends this by explaining what cancelled:false means (already answered, expired, missing, unavailable) and the handoffAction:stop edge case. This adds real behavioral context about failure modes, though some of it overlaps with the output schema.

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 action and its scope are front-loaded in the first sentence, followed by tightly packed return semantics. Four sentences with little waste, though the return-value detail is dense relative to a two-parameter tool.

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 mutation tool, the description, annotations, and output schema together cover purpose, safety, and result interpretation. It could still say more about interaction with wait_for_answer, but nothing essential to correct invocation is missing.

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%, so both parameters are already documented, including a detailed handoff description. The prose only echoes the 'moving to the current client' rationale for handoff and adds no syntax or format detail beyond the schema; baseline 3 is appropriate.

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 ('Retract a pending question') plus the scope ('no longer needed or is moving to the current client'). It is clearly distinguishable from siblings like ask_user and wait_for_answer without opening a 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?

Gives clear conditions for use ('no longer needed', 'moving to the current client') and one exclusion ('Does not retract an answer already recorded'). It stops short of naming sibling alternatives or an explicit not-use case against wait_for_answer, so it is strong but not fully routing.

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 can be read with wait_for_answer.

ParametersJSON Schema
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

ParametersJSON 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

A3.9/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: promises are recorded but never enforced, empty enforcement means no automatic checking, contracts never override host permissions, and the call blocks up to 55 seconds. It does not, however, explain the destructiveHint=true / idempotentHint=false profile — what state is altered or that a re-proposal is not idempotent — leaving a gap for a mutation-flagged 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?

Purpose is front-loaded in the first sentence and every subsequent sentence carries enforcement or routing information rather than filler. It is dense and slightly prose-heavy for a five-sentence block, but nothing reads as wasted.

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?

With an output schema present, the description need not detail returns, yet it names the key return fields (ratified, answered, contract, enforcement) to orient the agent. Combined with the rich annotations and schema, the only omission is the meaning of the destructive flag.

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 the schema already documents every parameter thoroughly, including the enforcement semantics of allowedPaths, promises and offLimitsPaths. The description only reinforces the 55-second timeout already encoded as maximum 55000, adding no new syntax or semantics, so the 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 and resource ('Request agreement on an unresolved or user-requested boundary for this session'), making it clearly a scope-contract proposal rather than a generic question. It is distinguishable from ask_user by being boundary-specific, but it never explicitly contrasts itself with that nearest sibling.

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 a clear trigger ('an unresolved or user-requested boundary for this session') and routes the agent to a sibling for the follow-up case ('a pending proposal can be read with wait_for_answer'). It stops short of stating when a plain ask_user would be the better choice instead.

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 Reminder
Destructive
Inspect

Remind the authenticated user later: a timer, alarm, ping, or reminder delivered by Pushary even after the agent exits. One-time only; up to 30 days away, 25 pending per user/site. Provide body plus inMinutes or at with an explicit UTC offset. Use a unique requestId for each schedule and reuse it unchanged on retries. Use reminderId to retrieve the final outcome. Confirm the returned time and report any warning. Omit arguments to list pending reminders; use cancelReminderId to cancel a scheduled one. Never use ask_user for a reminder. Does not schedule agent work or customer campaigns. Respects stop/mute and active membership at delivery.

ParametersJSON Schema
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.
send_notificationSend Push NotificationA
Destructive
Inspect

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.

ParametersJSON Schema
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

ParametersJSON 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.
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.
attributionNoWhether real session and machine identifiers were supplied. Unattributed notifications are delivered without creating a live session.
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.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.

wait_for_answerWait for User AnswerA
Read-onlyIdempotent
Inspect

Read the answer or current state of an existing question from ask_user or send_notification. 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.

ParametersJSON Schema
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

ParametersJSON 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.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds real value beyond them: the wait is capped at 55 seconds, 'pending' is the only live state, and cancelled/expired/missing/unavailable are terminal, which tells the agent how to interpret results and whether to keep polling.

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 the core action and tightly written; the state taxonomy is the most valuable part. The trailing return-value sentence slightly overlaps the output schema but is brief.

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 annotations covering the safety profile and an output schema covering the return values, the description supplies exactly the missing pieces: wait semantics, the timeout cap, and the terminal-state taxonomy. Nothing an agent needs to call this correctly is absent.

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 fully documented in the schema, including the default, maximum, and the handoffAction/nextAction guidance. The description only restates the 55s cap, so the baseline of 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?

Specific verb+resource: reads the answer/current state of an existing question created by ask_user or send_notification. Explicitly states what it does NOT do ('Does not send another question'), which cleanly separates it from the ask_user and send_notification siblings.

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?

Tells the agent the source of the correlationId (ask_user response or linkedCorrelationId from send_notification) and clarifies the non-sending behavior, routing work back to ask_user. No explicit guidance on cancel_question vs waiting, so it stops short of the 5 bar.

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
    • Addedschedule_reminder
  2. 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"
+}
  3. 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."
  4. 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"
+}
  5. 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"
+}
  6. 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."
  7. 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
  8. 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"
+}
  9. 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"
+}
  10. 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"
+}
  11. 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."
  12. 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
  13. 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))$"
  14. 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"
+}
  15. 1 tool update
    • Changedpropose_scope12 fields changed
      • changedInput schema / properties / allowedPaths / description
        Previous value: -"Globs you intend to change, e.g. [\"src/**\", \"docs/*.md\"]. Omit or leave empty to propose no path restriction, which the user is told plainly."New value: +"Globs 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."
      • changedInput schema / properties / offLimitsPaths / description
        Previous value: -"Globs you promise not to touch, e.g. [\"**/.env*\", \"infra/**\"]. These win wherever they overlap allowedPaths."New value: +"Globs 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\"."
      • addedInput schema / properties / promises
        Added value: +{
+  "description": "Boundaries 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.",
+  "items": {
+    "maxLength": 200,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}
      • changedInput schema / properties / sessionId / description
        Previous value: -"Your per-session id. Required: a scope with no session cannot be enforced, and must never leak into another run."New value: +"Your 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."
      • changedOutput schema / properties / contract / description
        Previous value: -"The scope exactly as it was put to the user, echoed back so the agent and the human are holding the same contract."New value: +"The 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."
      • changedOutput schema / properties / contract / properties / allowedPaths / description
        Previous value: -"Globs the run may change. Empty means no path restriction was proposed, which the user was told plainly."New value: +"Globs the run may change, after expansion. Empty means no path restriction was proposed, which the user was told plainly."
      • changedOutput schema / properties / contract / properties / offLimitsPaths / description
        Previous value: -"Globs the run promised not to touch. These win wherever they overlap allowedPaths."New value: +"Globs the run promised not to touch, after expansion. These win wherever they overlap allowedPaths."
      • addedOutput schema / properties / contract / properties / promises
        Added value: +{
+  "description": "Non-path boundaries as the user saw them. Recorded, never enforced.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / enforcementNote
        Added value: +{
+  "description": "Present only when there is something true to say about the limits of this contract. Repeat it to the user rather than paraphrasing it.",
+  "type": "string"
+}
      • addedOutput schema / properties / enforces
        Added value: +{
+  "description": "What 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.",
+  "items": {
+    "enum": [
+      "paths"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / hookSeen
        Added value: +{
+  "description": "Whether 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.",
+  "type": "boolean"
+}
      • changedOutput schema / required
        Previous value: -[
-  "correlationId",
-  "ratified",
-  "answered",
-  "contract"
-]New value: +[
+  "correlationId",
+  "ratified",
+  "answered",
+  "enforces",
+  "contract"
+]
  16. 1 tool update
    • Changedask_user1 field changed
      • addedInput schema / properties / toolPath
        Added value: +{
+  "description": "MACHINE-POPULATED. Exact absolute Write file_path from the runtime, for diagnostic correlation only. Models must omit it.",
+  "maxLength": 4096,
+  "pattern": "^\\/.*",
+  "type": "string"
+}
  17. 2 tool updates
    • Changedask_user1 field changed
      • addedOutput schema / properties / answerSource
        Added value: +{
+  "description": "Recorded answering surface, when known. Missing provenance is not proof of a phone answer; sandbox is simulated.",
+  "enum": [
+    "dashboard",
+    "mobile_app",
+    "mobile_background",
+    "decide_page",
+    "live_page",
+    "answer_link",
+    "inbox",
+    "slack",
+    "mac_app",
+    "sandbox"
+  ],
+  "type": "string"
+}
    • Changedwait_for_answer1 field changed
      • addedOutput schema / properties / answerSource
        Added value: +{
+  "description": "Recorded answering surface, when known. Missing provenance is not proof of a phone answer; sandbox is simulated.",
+  "enum": [
+    "dashboard",
+    "mobile_app",
+    "mobile_background",
+    "decide_page",
+    "live_page",
+    "answer_link",
+    "inbox",
+    "slack",
+    "mac_app",
+    "sandbox"
+  ],
+  "type": "string"
+}
  18. 1 tool update
    • Changedask_user2 fields changed
      • addedOutput schema / properties / deliveryMode
        Added value: +{
+  "description": "Effective delivery policy for this decision.",
+  "enum": [
+    "push_first",
+    "push_only",
+    "notify_only",
+    "terminal_only"
+  ],
+  "type": "string"
+}
      • addedOutput schema / properties / policyTimeoutMs
        Added value: +{
+  "description": "Policy wait window in milliseconds. Callers must also honor their host deadline.",
+  "minimum": 0,
+  "type": "number"
+}

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
    63 npm
    Apache 2.0

  • Ask Agent

    coder-mil
    F
    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.
    -
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