Human-in-the-loop over MCP
Human-in-the-loop over MCP, with one config entry.
Point any MCP client at the hosted Pushary server and your agent can ask a human. Nothing to install.
The integration
Add it to your MCP agent
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.
{
"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.
What MCP already gives you
Elicitation, where the client supports it
The MCP spec has a way for a server to ask the user something mid-call. The server sends an elicitation request, the client renders it, and the answer comes back. When the client implements it and the person is sitting in front of that client, it is exactly the right primitive and you should use it.
// Server asks the host to collect an answer.
// Works only if THIS client implements elicitation,
// and only while the user is actually looking at it.Where it stops
- Client support is uneven. A server that depends on elicitation behaves differently in every host it runs in, and degrades badly where it is missing.
- It reaches whoever is at the client right now. If they walked away, nothing happens until they come back.
- There is no record afterwards. The answer went into the conversation and nowhere else.
Before you ship it
Things that bite on MCP
- Notify and gate are not the same thing
- A tool the model chooses to call is a suggestion, and a model that does not want to be interrupted can simply not call it. If the requirement is that an action cannot happen without approval, the gate has to sit in front of execution, which on CLI agents means a PreToolUse hook rather than a tool.
- The MCP timeout is not your approval window
- Hosts cancel long-running tool calls on their own schedule, often well under a minute. A blocking ask that outlives the host timeout gets cancelled client-side even though the decision is still open and answerable on the phone.
- Every host names and surfaces tools differently
- The same server shows up with different tool descriptions and different approval prompts depending on the client. Test the ask flow in each host you claim to support, because the wording the model sees changes whether it calls the tool at all.
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.
- 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.
- 02
Connect your phone
Connect your phone to your Pushary workspace once, so questions and notifications have somewhere to land.
- 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.
- 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.
The Partner plan
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 never see a Pushary login or bill.
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 that opens the Pushary app, and every approval lands with the right person. No account and 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: the app first, because it is the only channel that puts Approve and Deny on a lock screen, 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
What tools does the hosted MCP server expose?
Who receives the question?
Do I need to install anything?
Which clients does it work with?
What happens if nobody answers in time?
How is this different from MCP elicitation?
Can I make an MCP tool call require approval?
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. Every decision is saved to a durable ledger you can audit.
Partner plan, $99 a month. Your users never see a Pushary login or bill.