Human-in-the-loop over MCP

Human-in-the-loop over MCP, with one config entry.

Point your MCP client at the hosted Pushary server at https://pushary.com/api/mcp/mcp with your API key as a Bearer token. There is nothing to install. The agent gets ask_user, wait_for_answer, send_notification, and cancel_question as ordinary tools, so it can put a question on your phone and hold for the reply. On the Partner plan the same server adds enroll_end_user, create_decision, get_decision, and cancel_decision, so an MCP agent can ask your own end-users durably. Works from Claude Code, Cursor, the Claude Agent SDK, and any client that speaks remote MCP over HTTP.

No install. One MCP server entry.two calls
{
  "mcpServers": {
    "pushary": {
      "type": "http",
      "url": "https://pushary.com/api/mcp/mcp",
      "headers": { "Authorization": "Bearer YOUR_PUSHARY_API_KEY" }
    }
  }
}

Why you need it

MCP pauses the agent. Pushary reaches the human.

MCP gives an agent tools, and no MCP client ships a way to reach a person who has stepped away from the keyboard. The hosted Pushary server adds that as plain tools: the agent calls ask_user, the question lands on the phones connected to your workspace, and wait_for_answer returns the reply. On the Partner plan the same server also exposes enroll_end_user and create_decision, so asking your own product's end-users durably needs no SDK either. The decision is written to the ledger and delivered to the phone they connected with one keyless tap.

How it works

From ask to resume

Connect the phone once, then ask a human from the tool or step that guards the action. The waiting, the delivery, and the record are handled for you.

  1. 01

    Add the server entry

    Add the Pushary entry to your client's MCP config with your API key as a Bearer token. That is the entire setup.

  2. 02

    Connect your phone

    Connect your phone to your Pushary workspace once, so questions and notifications have somewhere to land.

  3. 03

    Let the agent ask

    The model calls ask_user when it needs a decision and wait_for_answer to hold for the reply. send_notification covers completion and error alerts.

  4. 04

    Treat no answer as no approval

    If wait_for_answer reports that nobody responded, have the agent stop rather than proceed. The question expires instead of silently approving.

A decision is a yes or no confirm, a multiple-choice select, or a free-text input. Every one is stored with its outcome and kept in the audit log.

For your users

Your agent asks your users, not just you

Ship the agent to real users and let each of them approve their own decisions from their phone, under your brand.

Your users answer on their own phones

The externalId is your own id for the end-user. Connect their phone once with a keyless one-tap link, and every approval lands with the right person. No account, no app, no key on their side.

Durable, fail-closed waits

The agent stays open on a durable wait backed by a decisions ledger. If nobody answers in the window you set, the decision comes back denied, so a timeout or a restart never turns into an unapproved action.

Phone-first delivery

Pushary reaches the person on the device they carry: native app push first, then PWA push notifications, then Slack if you route it there. You do not build a delivery pipeline.

Signed webhooks and an audit trail

Every decision is written to a durable ledger you can query and export, and resolved decisions post a signed webhook to your callback URL. You have the record of who approved what and when.

FAQ

Questions, answered

Human-in-the-loop for other frameworks

Let your MCP agent ask a human.

Connect a user with one tap, ask a human with one call, and act on a fail-closed decision. The durable store and the audit log come with it.

Partner plan, $99 a month. Your users never see a Pushary login or bill.