Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Pushary: human-in-the-loop for AI agents

REMOTE · PUSHARY.COM · 2 COMPONENTS

Human-in-the-loop for AI agents: ask a person and get approvals or answers by push notification.

0 this week 93 Trust /100

Last scanned (13 hours ago)

Scores higher than 99% of remote servers

Reachable. Last reached 5 Nov 2026.

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security94
Transport & Reachability100
Schema Quality & AI Usability74
  • 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 3811 tokens (~346/item across 11 items; 6 tools + 5 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
  • No destabilizing schema changes in the last 30 days.Pass
Tool Coverage98
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 93% of tool parameters carry a description.Partial
  • Structured output schemas are declared (83% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
  • An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
What we tested

Checks we ran (13)

  • TLS certificate
  • Authorization
  • HTTPS
  • HSTS header
  • DNSSEC
  • Transport
  • Schema quality
  • Stability
  • Tool coverage
  • Injection markers
  • Destructive annotations
  • Judged manipulation
  • MCP protocol

Does not apply to this hosted endpoint (2)

  • Supply Chain SecurityScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
  • Provenance & TransparencyScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.

The score does not measure everything. What the score does not measure →

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 24 Oct 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “wait_for_answer” rewrote its description, which is the text the model reads security
    • Tool “propose_scope” rewrote its description, which is the text the model reads security
    • Tool “ask_user” rewrote its description, which is the text the model reads security
    • Tool “send_notification” rewrote its description, which is the text the model reads security
    • Tool “schedule_reminder” rewrote its description, which is the text the model reads security
    • “ask_user” reworded the description of “timeoutMs” cosmetic
  • 19 Oct 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “send_notification” rewrote its description, which is the text the model reads security
    • Tool “ask_user” rewrote its description, which is the text the model reads security
  • 10 Oct 26 0
    • New tool “schedule_reminder”, which the server declares destructive security
    • Tool coverage: 100% → 83% ▼ functional
    • Tool coverage: 100% → 93% ▼ functional
    • Schema quality: 3151 → 3572 ▼ functional
  • 4 Oct 26 −1

    No change was recorded against any check on this day. Schema Quality & AI Usability went from 78 to 77.

  • 3 Oct 26 +1
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “ask_user” rewrote its description, which is the text the model reads security
    • Tool “cancel_question” rewrote its description, which is the text the model reads security
    • Tool “propose_scope” rewrote its description, which is the text the model reads security
    • Tool “send_notification” rewrote its description, which is the text the model reads security
    • Tool “wait_for_answer” rewrote its description, which is the text the model reads security
    • Tool “cancel_question” is now declared destructive security
    • Schema quality: 381 → 297 ▲ functional
  • 2 Oct 26 93
    • The server rewrote its instructions, which are the text every model session reads security
  • 29 Sept 26 0
    • “ask_user” reworded the description of “action” cosmetic
    • “ask_user” reworded the description of “agentName” cosmetic
    • “ask_user” reworded the description of “blocker” cosmetic
    • “ask_user” reworded the description of “intent” cosmetic
    • “ask_user” reworded the description of “question” cosmetic

    5 cosmetic changes on this day. Switch on “Show cosmetic changes” to see them.

  • 28 Sept 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 5 Nov 2026 · Probed https://pushary.com/api/mcp/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=*.pushary.com CN=YR2,O=Let's Encrypt,C=US 30 Oct 2026 28 Jan 2027 RSA 2048 SHA256-RSA 5ff0f0a36e09dfc8729c49f30e6222906d0
SANs: *.pushary.com, pushary.com
CN=YR2,O=Let's Encrypt,C=US (CA) CN=Root YR,O=ISRG,C=US 3 Sept 2025 2 Sept 2028 RSA 2048 SHA256-RSA 4ebd24947e24d394802d84a52fd5b319
CN=Root YR,O=ISRG,C=US (CA) CN=ISRG Root X1,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 RSA 4096 SHA256-RSA f24b6d17f9d9ad7cb1c9fea78782699f

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of pushary.com. — Not signed

Zone DS Keys Algorithms Outcome
. Trust anchor 20326, 38696 8, 8 Verified
com. DS published 19718 13 Verified
pushary.com. No DS Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication Enforced and verified

The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.

Result Enforced and verified
Enforced On tool calls
HTTP status 200

WWW-Authenticate challenge Bearer error="invalid_token", error_description="No authorization provided", resource_metadata="https://pushary.com/.well-known/oauth-protected-resource/api/mcp/mcp"

Bearer error="invalid_token", error_description="No authorization provided", resource_metadata="https://pushary.com/.well-known/oauth-protected-resource/api/mcp/mcp"
Header Value
strict-transport-security max-age=31536000; includeSubDomains; preload
x-content-type-options nosniff
x-frame-options SAMEORIGIN
referrer-policy strict-origin-when-cross-origin

Protected resource metadata

Document https://pushary.com/.well-known/oauth-protected-resource/api/mcp/mcp
Retrieved Yes
Resource https://pushary.com/api/mcp/mcp
Authorisation server https://clerk.pushary.com

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://pushary.com/api/mcp/mcp Verified 200
http (plaintext) http://pushary.com/api/mcp/mcp HTTPS enforced 308 https://pushary.com/api/mcp/mcp
MCP tools · 6 exposed · ~3,230 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
ask_user ~1,550

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.

NameTypeReqDescription
actionstring–The concrete operation about to happen, one line. Shown as the Action line. Cut to 500 chars.
actionBodystring–The 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.
agentNamestring–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…
blockerstring–The single gating reason the agent stopped, one line. Shown as the Blocker line. Cut to 500 chars.
callbackUrlstring–Webhook 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.
contextstring–One or two sentences about what the agent is working on, shown above the question so the user can decide without opening the terminal.
envstring–Set 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…
externalIdsarray–Deliver only to subscribers matching these external IDs.
intentstring–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.
localSurfaceAvailableboolean–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…
machineIdstring–Stable machine id of the asking agent, so two machines never collapse into one session.
optionsarray–The 2 to 6 choices for a select question. Required when type is "select", ignored otherwise. The answered value is the chosen option string.
pausedAwareboolean–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,…
permissionModestring–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 ca…
placeholderstring–Hint text shown inside the free-text field for input questions
questionstringyesThe complete question, up to 8000 characters. Preserve every point. Notifications show a short preview; the answer interface shows the full question.
questionOwnerobject–MACHINE-POPULATED. Ownership supplied by the supported personal Codex bridge. Models must omit this field.
questionsarray–ONE 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 m…
repoKeystring–Stable 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-…
requestIdstring–MACHINE-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 at…
scopePathstring–Set 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 ask…
sessionIdstring–Opaque per-session id of the asking agent, so parallel sessions are attributed separately.
sessionToolAwareboolean–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 c…
subscriberIdsarray–Deliver only to these subscriber IDs. Omit all targeting fields to reach every connected device.
tagsarray–Deliver only to subscribers that have any of these tags.
timeoutMsinteger–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…
toolNamestring–The tool this approval is for (e.g. "Bash"), so the user can choose to always-allow it.
toolPathstring–MACHINE-POPULATED. Exact absolute Write file_path from the runtime, for diagnostic correlation only. Models must omit it.
toolTargetstring–Compact 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.
toolUseIdstring–MACHINE-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 differe…
typestring–Question type: confirm renders yes/no buttons, select renders the options list, input renders a free-text field.
waitboolean–true (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.
waitEndsAtstring–MACHINE-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.
NameTypeReqDescription
answerSourcestring–Recorded answering surface, when known. Missing provenance is not proof of a phone answer; sandbox is simulated.
answerUrlstring–Optional signed-in dashboard page where the user can answer this question.
answeredboolean–True once the user responded. Absent on the wait:false path, where nothing was awaited.
correlationIdstringyesId of the question that was created. Pass it to wait_for_answer to keep waiting, or to cancel_question to retract it.
deliveryobject–Per-channel reach for the push carrying this question.
deliveryModestring–Effective delivery policy for this decision.
envstring–Echoed when the call was test traffic.
expiresInSecondsnumber–How long the question stays answerable.
handoffActionstring–Race-safe directive for updated clients. Takes precedence over nextAction: cancel before asking in the current client, or stop the handoff.
heldstring–Present when the question was stored but deliberately not delivered: test traffic, or a permission ask with no toolName and no sessionId.
hintstring–What to do next, when there is a next step.
modestring–The site delivery mode that stopped this call from waiting.
nextActionstring–Backward-compatible next step: keep waiting while pending or ask in the current client. Follow handoffAction first when present.
noDevicesboolean–True when no phone, browser, or Slack channel could receive the question. Do not wait; follow handoffAction immediately.
notestring–Free text the user added alongside their answer.
pausedboolean–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.
policyTimeoutMsnumber–Policy wait window in milliseconds. Callers must also honor their host deadline.
questionstringyesThe question exactly as the user saw it.
statusstring–The question state. Only pending is a live unanswered wait; cancelled, expired, missing, and unavailable must not be described as timeouts.
suppressedboolean–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 S…
timedOutboolean–True when the initial wait ended while the question was still live. Poll once with wait_for_answer, then follow handoffAction when present, otherwise nextAction.
typestringyesThe question type that was rendered.
valuestring–The user's answer: "yes" or "no" for confirm, the chosen option for select, the typed text for input.
waitEndsAtstring–When the agent hook stops waiting live. On an idempotent replay this is the original question's deadline, which the hook must reuse.
warningstring–Present only when no channel is connected, naming what the user has to connect.

No examples provided.

cancel_question ~164

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.

NameTypeReqDescription
correlationIdstringyesThe correlationId of the pending question to cancel, as returned by ask_user or send_notification
handoffboolean–True 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…
NameTypeReqDescription
askHandoffboolean–True 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.
cancelledbooleanyesTrue when a still-pending question was removed. False when it was already terminal, missing, or unavailable; inspect status and handoffAction when present.
correlationIdstringyesThe question this result refers to, echoed back.
handoffActionstring–Stop rather than opening another answer surface when the question state is unavailable.
hintstring–What to do when cancellation could not safely inspect the question.
statusstring–Present when Pushary could not safely read or fence the question state.

No examples provided.

propose_scope ~514

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.

NameTypeReqDescription
agentNamestring–Name of the agent asking, format "{Agent} - {project}".
allowedPathsarray–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 d…
doneWhenstringyesWhat "finished" means for this run, one or two lines. Carried for the human to judge against; never enforced automatically.
machineIdstring–Stable machine id, so two machines never collapse into one session.
offLimitsPathsarray–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…
promisesarray–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 bound…
sessionIdstringyesYour 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 enfo…
timeoutMsinteger–How long this call blocks, in milliseconds (max 55000).
NameTypeReqDescription
answeredbooleanyesTrue when the user responded at all. Answered but not ratified means they declined, so ask what scope they want rather than proceeding.
contractobjectyesThe 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 other…
correlationIdstringyesId of the scope question. Keep waiting with this id while the question is pending.
enforcementNotestring–Present only when there is something true to say about the limits of this contract. Repeat it to the user rather than paraphrasing it.
enforcesarrayyesWhat 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 prom…
handoffActionstring–Race-safe directive for updated clients. Takes precedence over nextAction.
hookSeenboolean–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:…
nextActionstring–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.
notestring–Present only when the scope is not in force, saying what to do instead of proceeding.
ratifiedbooleanyesTrue 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.
statusstring–The underlying scope-question state.
valuestring–The raw answer behind ratified, "yes" or "no".

No examples provided.

schedule_reminder ~369

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

NameTypeReqDescription
agentNamestring––
atstring–Future 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.
bodystring–What 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.
cancelReminderIdstring–Cancel this user's scheduled reminder instead of creating one. Already-dispatching reminders cannot be cancelled.
envstring––
inMinutesinteger–Minutes from the server clock; use for timers and relative reminders.
machineIdstring––
reminderIdstring–Look up your reminder, including its final outcome and delivery status, instead of scheduling or cancelling.
requestIdstring–Unique ID for this scheduling operation. Reuse it unchanged on retries to return the original reminder, including after it settles.
sessionIdstring––
titlestring––

No output schema declared.

No examples provided.

send_notification ~485

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

NameTypeReqDescription
agentNamestring–Name of the agent sending this notification, format "{Agent} - {project}" (e.g. "Claude Code - myproject"). Shown in the notification so the user knows which session is talking. Falls back to the MCP…
bodystringyesNotification body text (max 500 chars). One or two sentences the user can act on without opening anything.
contextobject–Structured context rendered as a rich detail page when the user taps the notification. Strongly recommended for task_complete and error notifications so the user can act from their phone.
envstring–Set to "test" from a test suite. The notification is recorded in the activity feed and nothing is delivered to a phone or browser. The X-Pushary-Env: test header does the same for every call on the c…
externalIdsarray–Deliver only to subscribers matching these external IDs.
iconUrlstring–URL of the notification icon image
imageUrlstring–URL of a large image shown in the notification
machineIdstring–Stable machine id of the sending agent, so two machines never collapse into one session.
sessionIdstring–Opaque per-session id of the sending agent, so parallel sessions are attributed separately in the activity feed.
subscriberIdsarray–Deliver only to these subscriber IDs. Omit all targeting fields to reach every connected device.
tagsarray–Deliver only to subscribers that have any of these tags.
titlestringyesNotification title shown on the lock screen (max 100 chars). Lead with the outcome, e.g. "Build finished" or "Migration failed".
urlstring–URL opened when the user taps the notification. Ignored if context is provided, because a context detail page URL is generated automatically.
NameTypeReqDescription
attributionstring–Whether real session and machine identifiers were supplied. Unattributed notifications are delivered without creating a live session.
completionId––Recorded completion identifier, or null when no completion was recorded.
deliveryobject–Per-channel outcome. The two channels are independent with no cross-fallback, so each reports its own result.
envstring–Echoed when the call was test traffic.
hintstring–What to do next, when there is a next step.
linkedCorrelationIdstring–Present only when context.askQuestion embedded a decision prompt. Pass it to wait_for_answer to collect the response.
notificationIdstring–Trace ID for this notification; provider acceptance does not confirm a person saw it.
sentnumber–Total devices reached, web plus mobile. Zero is a successful call that found nobody to deliver to, not an error.
statusstring–Outcome when a session completion is recorded for delivery once per turn.
suppressedstring–Reason the notification was recorded without a push.
updatesobject–Effective update delivery setting and the policy that selected it.
warningstring–Present only when the notification reached zero devices, naming what the user has to connect.

No examples provided.

wait_for_answer ~148

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.

NameTypeReqDescription
correlationIdstringyesThe correlationId from an earlier ask_user response, or the linkedCorrelationId from a send_notification with an embedded askQuestion
timeoutMsinteger–How long this one poll blocks, in milliseconds (default 30000, max 55000). Follow handoffAction when present, otherwise nextAction.
NameTypeReqDescription
answerSourcestring–Recorded answering surface, when known. Missing provenance is not proof of a phone answer; sandbox is simulated.
answeredbooleanyesTrue once the user responded. False means follow handoffAction when present, otherwise nextAction; do not guess that every unanswered state is a timeout.
handoffActionstring–Race-safe directive for updated clients. Takes precedence over nextAction.
hintstring–What to do next, when there is a next step.
nextActionstring–Backward-compatible next step for older clients. Follow handoffAction first when present.
notestring–Free text the user added alongside their answer.
statusstringyesThe actual question state. Only pending is a live unanswered wait.
valuestring–The user's answer: "yes" or "no" for confirm, the chosen option for select, the typed text for input. Present only when answered is true.

No examples provided.

Install

How do I install the Pushary: human-in-the-loop for AI agents MCP server?

Pushary: human-in-the-loop for AI agents is a hosted endpoint at https://pushary.com/api/mcp/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · pushary.com

# add to Claude Code
claude mcp add --transport http pushary-pushary 'https://pushary.com/api/mcp/mcp'
Common questions

What is the Pushary: human-in-the-loop for AI agents MCP server?

Pushary: human-in-the-loop for AI agents is an MCP server listed in the public MCP registry as io.github.Pushary/pushary. Human-in-the-loop for AI agents: ask a person and get approvals or answers by push notification. This page covers its hosted endpoint (https://pushary.com/api/mcp/mcp).

Is the Pushary: human-in-the-loop for AI agents MCP server safe to use?

Pushary: human-in-the-loop for AI agents scores 93 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Pushary: human-in-the-loop for AI agents MCP server expose?

Pushary: human-in-the-loop for AI agents exposes 6 tools: schedule_reminder, send_notification, ask_user, propose_scope, wait_for_answer, cancel_question. Their descriptions and schemas cost roughly 3,230 tokens of context every time the server is loaded.

Does the Pushary: human-in-the-loop for AI agents MCP server require authentication?

Yes. Pushary: human-in-the-loop for AI agents asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

Is the Pushary: human-in-the-loop for AI agents MCP server still maintained?

Pushary: human-in-the-loop for AI agents is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What did VerifyMCP test on the Pushary: human-in-the-loop for AI agents MCP server?

VerifyMCP ran 13 checks on Pushary: human-in-the-loop for AI agents, covering TLS certificate, Authorization, HTTPS, HSTS header and 9 more. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.