What is an MCP server (and why notifications are a great first one)

The problem MCP solves

A language model on its own can only produce text. To be useful as an assistant, it needs to reach outside the conversation — read a file, query a database, hit an API, send a message. For a while, every AI product solved this with its own bespoke plugin format. If you wanted your integration to work in three different assistants, you built it three times.

The Model Context Protocol (MCP) is the standard that ends that duplication. It defines a common way for AI applications (the clients) to connect to external capabilities (the servers). Build one MCP server and any compliant client — a coding assistant, a chat app, an agent framework — can use it. The usual analogy is USB-C: one connector instead of a drawer full of proprietary cables.

What an MCP server actually exposes

An MCP server can offer three kinds of thing. The one that matters most in practice is tools — named actions the model can invoke, each with a description and a typed input schema. (The other two: resources, read-only data the model can pull in as context, and prompts, reusable templates. Tools are where the action is.)

Here's the loop, concretely:

1. The client connects to your server and asks, "what tools do you have?"
2. Your server answers with a list — each tool has a name, a human-readable description, and a JSON schema for its arguments.
3. During a conversation, the model decides a tool would help. It emits a structured call: the tool name plus arguments matching the schema.
4. The client routes that call to your server, which does the real work and returns a result.
5. The model reads the result and continues — telling the user what happened, or chaining into the next step.

The crucial thing to internalise: the model doesn't run your code. It only produces a request to run a tool. Your server, and the client's permission rules, decide what actually happens. That separation is what makes tools safe to hand to an AI in the first place.

{
  "name": "notify",
  "description": "Send a push notification to the user's phone.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "body":  { "type": "string" }
    },
    "required": ["title"]
  }
}

That description isn't decoration — it's how the model knows when to reach for the tool. "Send a push notification to the user's phone" tells it exactly the situation this fits. Writing good tool descriptions is most of the craft of building a useful MCP server.

Why notifications are the perfect first MCP

When people first wire up MCP, they often start with something ambitious and scary — a tool that can edit their filesystem, run shell commands, or hit a production database. Then they spend the evening worried about what the model might do. A notification tool sidesteps all of that, and it's the reason it makes such a good on-ramp.

It does exactly one thing

Send a message to your phone. There's no sprawling surface area, no fifteen parameters, no edge cases. You can hold the entire behaviour in your head, which means when the model calls it you know precisely what will and won't happen.

It's genuinely low-risk

Think about the worst case if the model misbehaves or a prompt injection tricks it. The absolute maximum damage is: you get a notification you didn't want. It can't exfiltrate data (there's nothing to read), can't spend money, can't delete anything. That safety is exactly why it's the right place to learn the mechanics without betting anything.

Give an agent a tool that can rm files and you're debugging trust. Give it a tool that can buzz your phone and you're just learning how tool-calling works. Start there.

It's immediately, obviously useful

This isn't a toy example you throw away. An agent that can notify you is genuinely valuable: kick off a long refactor or a data job, walk away, and let the AI ping your phone when it's done or when it hits something it needs you to decide. That's the single most requested agent behaviour — "tell me when you're finished" — and it's a notification tool. More on that in AI agent notifications.

How Lert implements MCP: it's just a URL

Most MCP servers are a package you install and a process you run. Lert takes the same philosophy as its notification endpoint and applies it here: the MCP server is a hosted URL. You get one that looks like https://lert.dev/mcp/your-id, add it to your AI client's MCP config, and the assistant gains a notify tool pointed at your phone. The URL is the authentication — no key, no token, no local server to keep alive.

{
  "mcpServers": {
    "lert": {
      "url": "https://lert.dev/mcp/your-id"
    }
  }
}

That's the entire integration. The assistant now knows it has a way to reach your phone, and it'll use it when the moment fits — a job finishing, a question it's blocked on, a milestone worth surfacing. Because it rides the same capability-URL model, the security story is the same too: the endpoint can only do one small, safe thing, so a leaked URL means unwanted notifications, nothing worse.

Where to take it next

Once you've felt the loop work — the model deciding, calling, and your phone buzzing a second later — the abstract parts of MCP click into place. You understand why tool descriptions matter, how the client mediates permission, and where the boundaries sit. From there, more powerful servers stop being intimidating; they're the same pattern with a bigger blast radius and correspondingly more care.

If you want the hands-on version, the MCP AI notifications guide walks through adding the Lert server to a client step by step. It's the fastest way to go from "what is MCP" to "my AI just texted me that the build passed."