What Is an MCP Notification Server? (And How to Make Your Agent Reach You)

If you've searched for an "MCP notification server," you're almost certainly trying to solve one specific problem: your coding agent runs on its own for long stretches, and you want it to reach you the moment it needs a human — without babysitting a terminal. This is a definitional guide. It covers what MCP is, what "notification server" actually means in MCP terms, why long-running agents need one, and how a tool-based server lets the agent itself decide to call you.

MCP in thirty seconds

The Model Context Protocol (MCP) is an open standard for connecting AI agents to outside tools and services. Your agent is the client; a server exposes a set of tools — each with a name, a description, and arguments — and the agent decides, on its own, when to call them. Connect a server once and its tools become things the agent can reach for whenever they're useful.

One trait matters for notifications: some MCP clients allow long-running tool calls — a call that blocks and doesn't return right away. Hold that thought; it's the whole trick.

What "notification server" means in MCP terms

The phrase gets used two different ways, and the difference is the point.

The protocol itself has a low-level idea of "notifications" — JSON-RPC messages a server can push to a client (progress updates, "my tool list changed," and so on). Those are plumbing between the agent and the server. They never reach you. So when people say "MCP notification server," they almost never mean that.

What they actually want is one of two designs:

• Out-of-band push. A server (or a hook) fires a one-way alert — a push notification, a Slack message, an email — when something happens. Great for "it finished." But it's one-way: it tells you, and you still have to go back and type an answer.
• A tool the agent calls. The server exposes a tool that means "reach my human." The agent calls it when it decides it needs you, the call blocks while you respond, and your answer comes back as the tool's result. This is two-way by construction.

The second design is the interesting one for autonomous work, and it's where that long-running tool call earns its keep.

Why long-running agents need one

An agent running unattended is fine right up until it isn't. It hits an approval, an ambiguous requirement, or a destructive command it shouldn't run on its own — and then it waits. With no way to reach a human, it either stalls silently in a window you're no longer watching, or it guesses. Both are expensive: the first burns your time, the second burns your trust.

A notification server closes that gap. The good ones don't just alert you to the stall — they give the agent a way to ask, and give you a way to answer.

The tool-based approach, concretely

AgentCall is a pure-MCP notification server of the second kind. It's a voice bridge: when your agent hits a decision, an approval, or a milestone, it calls a tool named request_human, and your phone rings. You pick up, the agent explains what it's stuck on in its own words, you talk it through, and it resumes — all in one call. The words you speak become the tool result the agent was blocked on.

A few properties fall straight out of the "it's just a tool the agent calls" design:

• No hook, no glue. The agent doesn't need an external script watching for events. It decides it needs you and calls the tool, the same way it would call any other. The reply flows right back into the run.
• No AI in the middle. AgentCall never generates words your agent didn't say. Your speech is transcribed to text for the agent; the agent's text is spoken to you. It's a bridge, not a chatbot.
• Mishearing can't cause damage. Because transcription is treated as untrusted input, the agent is instructed to confirm destructive or irreversible instructions out loud before acting — a misheard "drop the table" doesn't become a dropped table.
• Miss it and nothing breaks. No answer within a few minutes and the agent is told the call went unanswered and proceeds on its best judgment; the missed call is in your History, with optional voicemail.

request_human is one of several tools the server exposes — there are also tools to speak an update, listen for a reply, and end the call. The full set, with arguments and turn semantics, is documented in the tools reference.

It's agent-agnostic

Because MCP is an open standard, none of this is tied to one agent. The one real requirement is that your MCP client allows long-running tool calls — the request_human call has to be able to wait while you get to your phone and talk.

• Claude Code is the tested client; it works today.
• Codex CLI works in beta.
• Any other MCP client that permits long-running tool calls should work, but is untested — so try it, and don't take our word for it until you've placed a test call.

Use the tool-specific name when it's the real search phrase, but the mental model is "any MCP agent that can hold a call open," not "Claude Code only."

Connect it in one command

claude mcp add --transport http --scope user agentcall https://agentcall.io/api/mcp

Sign in with Google in the browser, then add AgentCall to your phone's home screen so it can ring you — that's the install, a home-screen web app, not an app-store download. Place a test call from the Quickstart and you're set. It's free while in beta, speech minutes included — no card, no trial clock.

One naming note: this is AgentCall.io, voice escalation for coding agents. It is not agentcall.co, an unrelated programmable SMS/voice API SDK for building telephony into your own app. Different product, different job.

Next: Connect AgentCall in one command → · Every way to get notified when your agent needs you →